Mixergy Posted March 7, 2017 Share Posted March 7, 2017 Dear all, I have been running a two sequences and three logging set, with 10ish channels on a daqfactory lite version platform. I noticed that during the operation, the following warnings/errors would appear quite frequently(especially in a while loop which loops approximately every 1 second: "C1038 Timing lag, data acquisition stalled. Resetting Timing: 1.000, Offset: 0.000" Just wonder what causes such warning? I have attached my program for reference. Many thanks. Regards, Ren test.ctl Link to comment Share on other sites More sharing options...
AzeoTech Posted March 7, 2017 Share Posted March 7, 2017 That occurs when DAQFactory can't keep up with the desired Timing on channels. So, if you have a group of channels with Timing 0.1 and offset 0, and for some reason it takes 0.2 seconds to actually read those channels, there is no way DAQFactory can keep the desired 0.1 query rate. It will try, hoping that maybe the 0.2 seconds is just a fluke due to delay in communications, but eventually it will get so far behind that it will through a Timing Lag error and start over. Link to comment Share on other sites More sharing options...
Mixergy Posted March 10, 2017 Author Share Posted March 10, 2017 I have only 6 read input channels, each at 1 second sampling interval and 0 off-set, alone with another 10 output channels with 0 timing. Apart from timing lag, I also got pork locked warning as shown in the attachment, which completely stoped the event I programed to do. 6 input channels to read doesn't seem to be a complex task for daqfactory, is it still the timing keep up problem? Or could it be a hardware issue? Cheers, Ren Link to comment Share on other sites More sharing options...
AzeoTech Posted March 10, 2017 Share Posted March 10, 2017 There is something else going on. I'd need to see the whole document. 6 channels isn't a problem for DAQFactory, for sure, but if your device isn't responding and you have a large timeout that could be the issue. In fact, my guess is that you increased the Timeout on the port to something a lot bigger than 1000. Link to comment Share on other sites More sharing options...
Mixergy Posted March 11, 2017 Author Share Posted March 11, 2017 I have attached the original file. By "increased the Timeout on the port to something a lot bigger than 1000", is that I need to setup in the PLC or daqfactory? Cheers, Ren test.ctl Link to comment Share on other sites More sharing options...
AzeoTech Posted March 14, 2017 Share Posted March 14, 2017 If you watch the comm monitor for the Modbus device with "display time of tx/rx", how long does it take from the time of Tx, until the corresponding Rx? Link to comment Share on other sites More sharing options...
Mixergy Posted March 15, 2017 Author Share Posted March 15, 2017 Hi, Tried to do as you said. It seems that comms takes about 40-50 ms to respond. Doesn't seems to be an issue for logging 6 channels... Regards, Ren Link to comment Share on other sites More sharing options...
AzeoTech Posted March 15, 2017 Share Posted March 15, 2017 Yup, plenty of space there. Now try it with the whole system and see what the comm monitor looks like. You might have a Tx with no Rx that is holding things up. Link to comment Share on other sites More sharing options...
Mixergy Posted March 27, 2017 Author Share Posted March 27, 2017 Hi, this port lock usually happens when I try to write/read to multiple IOs (channels) simultaneously without delay () in between in the sequence. Could that be the problem of port locking? Should I place a delay() in between. I have attached an example of my code. Cheers, Ren Link to comment Share on other sites More sharing options...
Mixergy Posted October 23, 2017 Author Share Posted October 23, 2017 On 14/03/2017 at 3:36 PM, AzeoTech said: Yup, plenty of space there. Now try it with the whole system and see what the comm monitor looks like. You might have a Tx with no Rx that is holding things up. Hi AzeoTech, After many months, I am still having this issue. Now it will get into the point of receiving 'C1038 Timing lag, data acquisition stalled. Resetting. Timing: 1.000, Offset: 0.000' and DF losing comms with the device completely (see attached screenshot). Like you side, I might have a Tx with no Rx that is holding things up. Is there a way to resolve this? Like ignoring Rx and carry on sending Tx? Many thanks! Regards, Ren Link to comment Share on other sites More sharing options...
AzeoTech Posted October 24, 2017 Share Posted October 24, 2017 What is the timeout value of your port? You don't want to not wait for a response, as Modbus devices should always respond to a query. Link to comment Share on other sites More sharing options...
Mixergy Posted October 25, 2017 Author Share Posted October 25, 2017 20 hours ago, AzeoTech said: What is the timeout value of your port? You don't want to not wait for a response, as Modbus devices should always respond to a query. HI Azeo Tech The timeout on the PLC and DF have been both set up as 1000ms.Shall I set up timeout on the PLC port to be longer? Thanks, Ren Link to comment Share on other sites More sharing options...
AzeoTech Posted October 25, 2017 Share Posted October 25, 2017 No, set it shorter. Say 250. If your device doesn't respond with 250ms, its probably not going to respond at all. But if you've lost comms completely, the timeout value isn't going to matter. If you are using a USB to serial adapter, most likely you plugged it into a different USB port and Windows assigned it a different Comm port. This is one of many reasons I dislike USB->Serial adapters. Or another piece of software has the comm port open. Or even DAQFactory has the port open if you created two ports with the same comm port #. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.