timed loop drift

[lincolnven]

hi all

I have a problem with the timed loop structure. I am running my code on a cFP, and it has 6 timed loops in parallel. One loop, with period of 900000ms (or 15min) reads all cFP channels and writes them to a datalog file, along with a timestamp. The timestamp is the first thing measured in each iteration of the loop, governed by a sequence structure. I have noticed in the datalog files that the timestamp is not at precisely 900000ms intervals. In fact, it is about 3000 ms short ! This error is undesired and cumulative.

The loop priority has been set to 250, as compared to the other loops all at 100. The other loop periods are 1000, 5000, 5000, 5000, 180000 ms

I doubt if this is a computation starvation problem, as the time is SHORT 3 seconds

Please offer some suggestions how to fix this!  

regards

dave williamson

[chrisger]

hi there

- timed loops are not deterministic! are you using the TCL/NPL structure in your code?
- are there any error codes returned by the timed loops? whats the wakeup reason properties value?
- what about different offsets for each loop for decoupling?
- consider to minimize the number of loops

best regards
chris

[lincolnven]

I was of the understanding that timed loops ARE deterministic

the loops are all normal priority, and without putting them into sub-vi's, it would be hard to make some of the loops TCL and not others. The reason all the loops are in the same vi is because I am using the 'stop timed loop' vi to control stopping of all the loops.

None of the loops are returning error codes, nor are they intentionally offset to decouple timing. The only loop that needs to be deterministic is the 900000ms loop.

Something that I should mention is that I am currently not building a standalone vi, but just running the VI from the laptop over an Xover cable targeting the c-FP. THis is so I benefit from the automatic inclusion of communication VI's. I close Labview with the 'Exit without closing RT engine VI's' option, so the VI's are still runningn on the Fieldpoint without the laptop connected. I suspect this may be slowing the loops, does this process use RT FIFOs to pass communication values?

All suggestions appreciated!

Regards, David Williamson

[xseadog]

Hi
have you done a search in the discussion forum ?
Did a quick hit with 'are timed loops deterministic'

http://search.ni.com/nisearch/nisearchservlet?nistype=default&ddown=3&filter=%2Btaxonomy:%22Discussion+Forums%22&q=ARE+timed+loops++deterministic

hope it helps

chow
xseadog

[DavidT]

If its running on a cFP controller, the loops are deterministic since it will be running on an RT system. This means there is something happening in your code which is causing a 3sec delay. Is there any chance of taking a look at your code? This is always the easier option in debugging problems.

Message Edited by DavidT on 09-05-2005 11:34 AM

[DavidT]

Further to the message above, take a look at this link for developing RT applications on Fieldpoint.

http://zone.ni.com/devzone/conceptd.nsf/webmain/60644843D0C0395286256D17007FF5FD 

[lincolnven]

DavidT, please note that the loop is not finishing 3s late, but 3s EARLY...This is the confusing issue. According to the link you posted, there are many factors in my code that may affect it to finish late, for example the use of property nodes and file writing in datalogging. BUT I am not running time critical VI's. I only need accuracy (ideally) in the tens of milliseconds. But it is finishing EARLY...???

In addition to the above 'bad' programming, there are many graphs (~22) on the front panel, each with 100 element history.... How can I avoid this if I MUST see the data? or should I have a seperate version of the program with no indicators running when I'm not troubleshooting?

Thanks

David Williamson

[DavidT]

Things like graphs and charts should be avoided on RT applications. If you need to see data, you can send your info to your host pc through DS or TCP/IP. I would recommend taking a look at the RT Communication Wizard to accomplish data transfer. Its very straightforward and easy to follow.

Again, without seeing your code, we can only guess as to why your system is running early. If you could post your vi's (or a cut down version of it in a zip or llb), it would help.

[lincolnven]

heres the program library, its about 2Mb

Thanks so much for your help so far, I look forward to recommendations on code improvements 😛

[DavidT]

Hi,

First thing I would suggest is to not use the 'Get Date/Time in Seconds.vi'. Im not going to speak for everyone, but I have had a lot of trouble getting correct timestamps from (c)FP units.  Why dont you use the Tick Count instead?

You can then convert the elapsed time to an hh:mm:ss.ms string and bundle it to a date string. (I think that the Tick Count and Get Date/Time vis get their time from diff clocks and the Get Date/Time vi is more processor intensive).

Also, how are you verifying if the loop is 3sec early. From the timestamp? If so, use the tick count function to time each loop iteration (subtract the current time from previous time using a shift register).

Let me know if this helps at all.