Timed Loop rarely gets stuck and does not seem to halt.

[az_ltr]

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. 

[Ben]

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.

Ben

[wiebe@CARYA]

---

@az_ltr wrote:

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.

[az_ltr]

Thought I would fulfill my commitment to reply the result of the -2 CPU.  I did observe a stuck condition after a month and a half or so.  So the new condition does not seem to effect the non-halting condition.

[Kevin_Price]

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.

-Kevin P

[az_ltr]

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.

[Kevin_Price]

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

[Norbert_B]

Without commenting on the ongoing discussion, i want to comment on this post:

---

@Bob_Schor wrote:

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 ...).

Bob Schor

---

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:

1. Timed structures suppress clumping for the content. As a result, the content of a timed structure will always be an individual clump (regardless of size)
2. The clump will be scheduled to a separate, unique thread. In turn: Each timed structure will create a new thread on top of the threads already available in LV created by the execution systems
3. The threads are scheduled internally of LV using the LV scheduler/dispatcher. On RT systems, this is deeply involved in the OS which in turn means that LV priorities can be taken as OS priorities. This is different to Windows targets where the OS scheduler/dispatcher is independent and can mess up the whole prioritization the developer expects (e.g. by having high priority back ground tasks like screen saver....). This is the misconception many developers have: a timed structure does NOT turn a non-deterministic OS like Windows into something deterministic!
4. Having multiple threads with same priority uses "Round Robin" scheduling in schedulers. As a result, using the same priority for multiple timed structures is nonsense in many cases (unless having CPU assignment and only differently assigned threads use same priority)
5. You can configure multiple timed structures to have a relationship to each other by using shared clocks (e.g. a DAQ device clock). However, this will still not defeat non-determinism by Windows, but enables you to define (hopefully) stable speed relations like phas shift between multiple tasks
6. Timed structures imply additional timing information like "finished late". This could be useful on Windows as well (regarding all previously mentioned points)

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.