Timing Lag

[mse3000]

I am currently reciecing a timing lag error every couple of minutes. According to the user manual this is usually due to the CPU being maxed out for a short period of time. In this case the CPU is running at only 10% and the timing for each request is fairly slow. We have a device delay of 50ms and a polling time of 1 second. I have attached a note pad document with some of the transmitted and recieved data in the hope you may be able to shed some light on things. I have tried increasing polling time to 2 seconds with no avail.

We have a fairly simple network setup of four Advantech Adam units and three Invertek Inverter drives running on modbus RTU (RS485) and one E-dam unit running modbus TCP.

Several lines concern me in particular:

Tx (17:13:53.474): 1103000500032196

Rx (17:13:53.877): 11030611000000000094\174

Tx (17:13:54.293): 0403000600023695

Rx (17:13:54.293): 040304\218\225\220

Rx (17:13:54.294): \11428\248

Tx (17:13:56.390): 10030005000320\177

Rx (17:13:56.390): 10

Rx (17:13:56.390): 030607000000000083\242

Tx (17:13:56.639): 12030005000320\215

Rx (17:13:56.639): 120306070000000000\120

Rx (17:13:56.639): 82

Any thoughts??

Many Thanks,

Mark

Modbus_Error_2.txt

[AzeoTech]

When everything is working, the total time to read all your channels is about 0.7 seconds, so you are fine with a 1 second refresh. However, as you noticed, in the first block you provided there is a point where the Rx is 0.4 seconds after the Tx. This is a hardware issue where the device is busy and taking forever (relatively speaking) to reply. Its these glitches that are causing your Timing Lag because you total time jumps over 1 second.

Your other lines of concern, the ones where the Rx is split in two, are not a concern. DAQFactory tries its best to keep frames on the same line, but sometimes it misses, so the Rx gets split. This is a visual only thing and no indication of anything real.

Suggestion: move the ModbusTCP to a different Timing or Offset so it runs in a separate thread and concurrent to the other reads. For even more performance, consider splitting your RS485 chain into two and putting each chain on its on Timing or Offset. For RS485, you should put all devices that are on the same physical 485 chain on the same Timing and Offset.

[mse3000]

Thanks for the advice, I have now modified the TCP timing to a 0.5 second offset and modified the 485 to poll every two seconds and this runs fine. Looking back at the file i sent before another line has come to my attention where the transmit and recieve times are the same. Surely this is not possible. Do you think this would be caused by DAQ Factory or the device? Would this have any adverse affects on DAQ Factory?

Tx (17:13:54.587): 1103000500032196

Rx (17:13:54.587): 11030611000000000094\174

My second problem now arises where the data seems to become completely scrambled. I have again attached the relevent file displaying some of the transmit and recieve data. The requests seem to be correct but data coming back I am guessing is meaningless as the device numbers are not even on the system. I am struggling to find the cause of this as the whole system will run fine for 6, 11 or 15 hours for example, before seemingly crashing. The last two data crashes have been at approximately 21:30 and 02:30. Do you think this could be linked to the inverter devices taking 0.4 seconds to respond as we have previously discussed or something else? Once this begins to happen the command alert is also filled with modbus errors 5, 10 and 11; as well as timeouts expectedly.

I can appreciate it is difficult to diagnose remotely so I have also attached the .ctl file for your information. Perhaps I am asking too much too quickly? I'm sure my programme is far from perfect! Please do not make the ctl file available publicly to view or download.

If you are unable to shed any light on the possible cause for this, is there a way I can accumulate the number of errors in relation to time. Say 5 errors in 20 seconds and ask the computer to reboot in order to bring the system back to a stable position? As this currently seems to sort the problem for however many hours until it occurs again. In the mean time I shall speak with the Inverter manufacturers and investigate if they have experienced problems with modbus requests previously.

Best Regards,

Mark

Modbus_Error_3.txt

[AzeoTech]

Couldn't open the .ctl file without the password, but its probably unnecessary.

The same time stamp on Tx/Rx: most likely the Rx actually came slightly before the Tx, but DF was so fast in its turn around that it got out of order.

As for the garbage on the line, the first thing I'd try is to use SetDelay() with a value of like 100 and increase your timing even more. This will just slow things down. DAQFactory sometimes runs just a little too quick for 485 transceivers and so a small delay is required to keep things running properly. If 100 works, you can try smaller values. The format is:

device.myDevice.setDelay(x)

where x is in ms and myDevice is the name of the serial device you created. For RTU this introduces a delay after each query.

If that doesn't fix it at all, then it might be noise on the line, but it doesn't really look like noise, just things out of order. You can get out of order problems, especially on 485, if a device takes slightly longer than the Timeout to respond. DF has moved on, but the device responds late, overlaying its values on top of the current frame.

[mse3000]

Thanks. I do currently use the device delay on several of our systems running 485 and find 20ms usually works well.

Interestingly yesterday I set up a new computer and came across the advanced settings for power plans under Windows 7. As this was also our first system setup on windows 7 I decided to have a look back and found two settings that concerned me:

usb selective suspend setting was enabled

sleep - allow hybrid sleep

Since we are running a usb to serial converter I thought this may have something to do with the cause. Since modifying these the system has now run without error for nearly 24 hours. I am hoping this was perhaps the cause and not the comms setup. Failing that I will continue to increase my device delay.

Reagrds,

Mark

[AzeoTech]

Yet another reason I recommend Ethernet to serial converters over USB to serial converters. In fact, I prefer Ethernet anything to USB, including DAQ devices. USB is convenient, but not really the best choice for 24x7 industrial use for many reasons.