C1038 Timing Lag


OkiePC

Recommended Posts

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

Link to comment
Share on other sites

Got it.  I've seen these documents before as they come from a particular hardware manufacturer (who has recently sold his company). There are two things here you aren't going to like.

 

1) There's a fair bit of background sequence triggered acquisition going on.  This is probably causing the timing lags.  

2) These documents are really borderline as far as our EULA.  It could very easily be argued that it is an application that competes with DAQFactory itself as it makes quite a bit of low level configuration available to the user.  I'm not going to get on you for this, especially since I'm fairly sure you own a development license, but it means that the document is quite complex to achieve this, and the level of free support I can give you on it is somewhat minimal

 

Note a timing lag only affects one timing/offset loop, so I doubt its causing a 20 second hang.  Plus it resets fast, under a second.  Really I think you need to delve in and do some serious housecleaning, especially if you aren't using their hardware anymore

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Yeah, your version isn't so bad.  I've seen others where pretty much the whole control logic could be done with a (royalty free) runtime license.  As I said, I'm not too worried about it.  The application has been around for like 10 years.  Its more that in creating the application it is rather complex as it duplicates a lot of functionality that would normally be done in development mode using normal DAQFactory menus.

 

As I said, I don't think the reset itself is causing the hang.  In fact, I wouldn't be surprised if whatever is causing a 20 second hang isn't also causing the timing lag.

 

You can simulate what a timing lag does by simply going to the command/alert window and typing:

 

channel.restart()

 

Also, 5.9+ has a script dump feature that will show you pretty much all the script in your application in a .txt file.  Since I know you are using 5.87 and I already have your document loaded, I'm going to email you the dump.  Maybe that will help you find some hidden script that is messing things up.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.