OkiePC

Members
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

0 Neutral

About OkiePC

  • Rank
    Member
  1. I figured it out. Actually I figured out how to fix it, not exactly why it behaved the way it did. I made another copy of a panel and then used Edit "Change component page" and set the target page to the main page. I think the pasted copy was landing on the MenuBar page which is also being displayed and only has page control buttons along the bottom. Anyway but resetting the copied component to the main page, and then by selecting all the covered up objects and bring them to front, I was able to get the panels back and behind everything else. It probably had to do with the fact that two pages (Main and MenuBar) were being displayed at the same time. As for version numbers...I read the release notes for versions newer that what we are running (5.87c). At tone time, correct me if I am wrong, 5.87c was listed as the latest tested or stable version, so we have not tried to go beyond that. Can we update them to newer versions painlessly? I do have a couple that are running some pretty elaborate systems with logging, OPC servers, virtual RFScada controls and tons of scripting, but many of them are quite simple ones too.
  2. OkiePC

    C1038 Timing Lag

    Yes, we have a development license. We have a few different customers who we support that are using similar versions of that application. I don't think there was any intent on the part of the original designer to infringe on the sales of DAQFactory. Each of the customers has a runtime license. I think he did what he did to save himself time more than anything else. The customers who use these apps can change the graphs and edit the alarm texts and that is about as far as they usually go. We are still using three pieces of their hardware, but have switched them over to Modbus mode of communication so that we can poll (tower levels) with our PLC. I did get rid of the channels in the channel table, but there may still be things in scripts that I have not removed or commented out that I can do away with. I had two options: 1) start over and build all new application from scratch. This would have been easier on me, but then the customer would have had to get used to a whole new look and feel. 2) strip out the unnecessary stuff and keep the charts and things that the customer realy likes. This is the route I took, and I did have to back up and punt after breaking a couple of things more than once. The timing lag and reset does cause a sever hang when it happens. The application becomes unresponsive for right at 20 seconds. This is probably because of what you said about all the complex scripting going on? In any case, if there is no quick and simple way to disable the reset, I will just have to do the housekeeping you suggest. I appreciate the feedback. Paul
  3. OkiePC

    C1038 Timing Lag

    I just zipped up the ctl file and the cfg files used by the original designer to configure parts of it and sent it to you.
  4. The version is 5.87c I got the workspace back. The upper right corner was hiding under the taskbar. Through remote access, the taskbar won't auto-hide, but when on site yesterday, with the takbar out of the way, I saw a little flicker in the lower right when I toggled the workspace and then saw it, dragged it back into view, so I am good to go there. I was there for other reasons and did not have time to dig into the z-order thing again yet.
  5. OkiePC

    C1038 Timing Lag

    I have a project I have modified and started using Modbus TCP polling from a PLC. The goal was to move machinery control away from DAQFactory and into the PLC. All of this was successful with a caveat: I started off with my new tags polling at 1 second with zero offset and was seeing this a lot: "C1038 Timing lag, data acquisition stalled. Resetting...." I ended up playing with the timing and the offsets to get these errors to go away. Now I have poling rates of 3 seconds and 6 seconds with various offsets. When I monitor the Ethernet channel, I see responses from the PLC within 2 milliseconds of the transmits. I think one time there was a 3 millisecond response time. So, the PLC is not holding things back. I have just under 80 tags, and they are all grouped by type and in contiguous blocks of Modbus addresses. The channel monitor bears out the fact that the transmit and receive blocks are in moderately large groups. So, although I can't claim I can read and interpret the codes and they go by, I do believe that my tag database is optimized. It would sure be nice if I could "turn off" this timing lag feature. I don't care if the timing lags. Maybe I can and I just don't know how. But, right now, with a polling rate of 3 seconds, when the operator operates some of the controls, it can take up to nearly six seconds to see the results. This makes the application seem to have a poor response, but it was better than hanging every few minutes to "reset timing". What can I do to make DAQFactory less sensitive to timing lag and then set my poling back to about 1 second? Thanks, Paul
  6. I have an (inherited) application with a very busy main screen. There are four groups of objects placed on rectangular "panel" objects. I inadvertently selected and moved one of the panels, and now it appears "on top" of some of the controls. I tried using the "send to back" menu and keyboard shortcuts but cannot get it back behind the controls it was hiding. So, I thought, no big deal, I will just copy the one next to it and move it over, then lock its movement so I don't screw it up again. I made a copy of the panel that is at the back of the z-order, and moved it over, and it has the same behavior. Not only that, but the one that I copied from also seems to have moved in front of a couple of objects. I thought perhaps that there were too many things on the screen so if I put this stuff on a scratch page and get the z-order right, then I could copy it back to the main page. This is where my 2nd problem arose. I can't "see" the workspace. I can turn it on and see that it should be visible, but where? There is only one monitor, and this app was edited on a different PC also with a single monitor, but somehow my Workspace is gone missing and I have been unable to find a way to reset its location so I can change pages to try to fix the z-order deal. In the end, I just ended up deleting the rogue panels and stopped. This is just an aesthetics thing, but I would like ot fix it back to normal at some point. I did a search for the terms "send to back" and "z-order" and read some notes about how panels and graphs are draw in a background task and should appear behind most other objects, but I think my issue is different. Thanks, Paul
  7. Okay. I figured out I can double click the expressions and delete them one by one from the watch list. You may be right about the RTU driver. I have had so many things going on the past few days... But when I opened up that other file it worked before I changed anything.
  8. I started with a fresh (file New) ctl file and a boolean and a float. Right off the bat the CRC errors stopped, but I was not getting good values back for the float, only zero until I added the bit reference. I was able to use the Boolean tag to prove that, yes, I do need to account for the "off by 1" Modbus thing which I have had to do before. I made my bit Modbus address 1, and had to use 0 in DAQ to get the right number. While I was doing that, I had switched my float tag to a "test" device so I could look at only the comm trace for the bit. So I switched my float tag back to my device "P2000" and theI/O type to "Read Holding Register" and voila, it is working now. I have 32 bit word swap turned off in the Productivity Suite Project Properties. So now I opened up my other test file and it works too. Even though I have restarted DAQFacotry multiple times, and restarted the PC twice during my previous test, whatever I have done since then with your help has made things right with the world of Modbus TCP. I may have at one point had the device type as Modbus RTU, but it is not now. I am pretty sure I did not alter the device type after I copied that trace. I would go ahead and call it success, and provide screenshots of how to make DAQFactory talk to P2000, but I want to go further first and make sure I can write back successfully to those channels and test all the different types I will need for this project. I will add some conclusions later on with some details and examples when I am more confident in what I just saw a few minutes ago. One thing still bugs me. Even with my new file, I am seeing stuff in the Watch window that is old from the first original project. How to I clear the watch list or delete variables from it?
  9. I had tried device number 1. I started out with a float, thinking that I could get comms established and byte swap issues handled right off the bat. I am going to start over with a boolean and a float and a new ctl file, and a new P2000 file and I will stay with device number 1 this time. In the P2000 software (Productivity Suite) all floats get the 6 digit Modbus address prefixed with a "4". It might be possible to add an analog input card and get a "3", but I am not sure that matters. I had tried all of your options with a (3) or a (4) and did see some differences among some of them in the comms trace. My screenshot was just the last one I ended up with. After I run a trial from scratch, starting iwth a bit address, I will post back with more info. Hopefully this thread will help future users once we get this nailed down. I appreciate your assistance and expertise on this.
  10. Well, I tried your suggestion of 14 and had no luck. Here is a copy of the Comm Monitor I am seeing: Tx: \000\004\000\014\000\002\017\217 Rx: \000\004\000\014\000\003\017\217\001 Tx: \000\004\000\014\000\002\017\217 Rx: \000\004\000\014\000\003\017\217\001 Tx: \000\004\000\014\000\002\017\217 Rx: \000\004\000\014\000\003\017\217\001 Tx: \000\004\000\014\000\002\017\217 Rx: \000\004\000\014\000\003\017\217\001 I am getting CRC errors no matter which version of the read float instruction i use.I tried changing the PLC project settings back and forth between word swap or not. Maybe the screen shot and trace pasted above will help.
  11. I am trying to communicate via Modbus TCP with a device (Automation Direct P2000 PLC) which uses 6 digit Modbus addresses. The PLC is tag based and quite flexible in the fact that I can assign Modbus address numbers to the tags. But when I choose a data type as 32 bit floating point, for example, their software prefixes the address with 4, and there is nothing I can do to prevent it. For example I have a tank level that I have set up in the PLC software as Modbus address 15, which ends up being 400015 rather than 40015 which I think would make DAQFactory "happy" with it. So, I get CRC errors in the comms watch window. I am pretty sure that the problem is a result of the number of digits used by one device versus what DAQfactory uses. I tried putting 400015 in the Channel number instead of just 15 and I then get an error "Invalid Address" in the alert window. I also tried using 40015 as the address, and I get the CRC error. It seems that every combination of the choices that list (4) in the dropdown for Modbus I/O type and 15 versus 40015 result in a CRC error or a timeout error. I think there are quite a few devices out there that use the 6 digit addressing form so this may have been asked already. I did search the forum briefly and did not find anything on the subject, but I would be grateful if someone can point me in the right direction to solve it. If necessary I can connect that PC to the internet and get some screen shots or some captures of the watch windows to help. Thanks, Paul