Good idea, I will give it a try. I did not see a wire going into the timed loop processor and assumed that it was default. Thanks! Problem is it will take a month or two to see if it helps since the issue is so spurious. I will in addition to updating our code base will set up a basic test case to see if I can get the delay to fail earlier. Run two parallel loops one with Processor 0 and another with -2. Maybe I will get lucky and the timed loop will stick. I will update the thread then.
I have seen the Timed Loop Lock-up.
In my case it only took a couple of hours. As a work-around I replaced Timed-Loop with a normal while loop combined with a normal "Wait MS" timer. The revised code has been running non-stop for more than a month now.
NI Support has my code and is trying to duplicate my hardware under SR# 3220821.
So you are not alone.
The timed loop function was used in a code base that I inherited. Not sure of the original motivation perhaps less jitter versus wait? I have not measured it.
There is more jitter with a wait (ms).
TL was spot on 0 ms, Wait (ms) as 0..1 ms, measured with a ms resolution...
When there is a lot of concurrency a TL might behave a bit better since it has a higher priority. If it didn't crash, and if the concurrent loops don't use a TL or have lower priority.
If you'd really want to, you could compensate for the occasional +1 ms, by waiting dT - 1 ms (or more generally "dTdesired - (dTprev - dTdesired)" ) the next cycle to avoid accumulating time errors.
Keep in mind that on a PC, you're referencing an inaccurate clock to begin with.
When you mention "a month and a half or so", a little alarm bell started going "ding ding ding" in my head.
I remember that as very roughly the time it would take for the u32 msec tick counter to "roll over". (Quick calculation has it at ~49.7 days) Another possibly interesting tidbit: the same incrementing u32 bits if *interpreted as* i32 would suddenly change from a positive to a negative value after half that time.
Reviewing the thread, this doesn't *seem* to be a likely failure mechanism and if it *is* relevant, credit to JensG69 for bringing it up back in msg #5. Still figured I'd toss it out there because suspicious numeric coincidences are sometimes good clues.
The timed loop itself is only executing once per timed loop so the counter for timed loop should not be rolling over. The timer value for the timed loop is under 5 minutes so it should not overflow in this time. But the timed loop itself is being called 1k's to 100k's of times per day depending on the desired delay time and it takes 1-2 months of continuous execution for the timed loop to not fire. If there is an internal free running counter implemented in the timed loop or in the PC timer resource that is not handling the I32/U32 rollover itself this will be more difficult to prove. Note that we have several setups running and they do not always lock up after 1-2 months...but none have locked up before 1 month. The PC vendor for reference are Dell PCs of various vintages.
My sympathies. An inconsistent symptom that takes more than a month to manifest itself is a nasty nasty problem. All hypotheses will be difficult to prove and require a lot of time investment just to investigate or experiment. So you want to screen out all but the very most plausible ideas before trying them.
I'm with you, I see no justifiable *action* to take about the "month and a half" almost-coincidence I brought up. Unfortunately I have no good ideas to replace it with. Good luck though.
- Kevin P
Without commenting on the ongoing discussion, i want to comment on this post:
I was always under the impression that the Timed Loop was designed for systems running a Real-Time OS, and wasn't recommended for "ordinary" LabVIEW on a Windows PC. I've always used Wait (ms) for timing loops in LabVIEW, and (successfully) used Timed Loops in the LabVIEW RT code running on the Real-Time OS on my Target machine. I'm not sure the hardware is there on a Windows PC to support the Timed Loop properly (but am prepared to be proven wrong ...).
Timed structures (Loop and Sequence) do have their use cases even on Windows targets, but you are right in that these are VERY specific and hence a rare incidence. Therefore, having the timed structures accessible on LV for Windows is mandatory, but most developers have an misunderstanding on what is going on with those structures.
I want to highlight the most important topics:
I think that covers most of the "mysterium" timed structure on Windows (and RT) and hope it helps all developers to correctly choose wether to use a timed structure or not.