Showing results for 
Search instead for 
Did you mean: 

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

I have observed on 3 machines in 3 months the timed loop getting stuck and never exiting.  The VI is running on several versions of LabVIEW... LV2015,16,17.  Running Windows 10 not RT or CompactRio.  Nothing complicated is going on in the timed loop.  The counter shows that the timed loop has been entered but the timer never fires so it gets stuck.  I have waited for about 2 hrs and the timed loop never exits.
The issue once it occurs seems to be static.  You can exit LabVIEW and/or restart the machine and the timed loop will not function correctly.  If you force recompile or change something in the VI to force a recompilation the timed loop functionality returns to normal.
Just curious if anyone happen to seen this before or know how windows timer resource gets stale?

0 Kudos
Message 1 of 18

We probably need more information. Are you using the time loop mostly in the default configuration or are things more "special"?

LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 2 of 18


source name is default. (1kHz Timer)

dt is an I64 input with usual values of 1 to 10,000 (1 to 10,000 ms)

Priority is default

CPU is default.


During the "locked" state I see dt input values of 1 to 10,000 so it is not an erred large input...

Inside the timed loop...Just a singular logical comparison.


So this is a pretty basic use case of the timed loop.

0 Kudos
Message 3 of 18

@az_ltr wrote:

So this is a pretty basic use case of the timed loop.

Agreed. But not as basic as a simple Wait (ms) function...


It would be interesting to see a minimal functional example though.

0 Kudos
Message 4 of 18

Just a random idea: Do you use the loop iteration counter of the (timed) loop? This counter will stop to count up when it reaches its maximum I32 value.

Kudos are welcome...
Message 5 of 18

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

0 Kudos
Message 6 of 18

AFAIK, the timed loop API (the dll that manages it), is just a limited one, to give a RT 'look and feel', while being something different. 


It works, but expectations usually needs to be adjusted to a level where you might as well use a Wait (ms). 1 ms accurate timing is just not going to happen on Windows.


Of course missed cycles, etc. can have some benefits.


Using a TL to simply make things happen at intervals is not something I'd recommend. Occam's razor: a wait is simpler...

0 Kudos
Message 7 of 18

Ok.  Added picture.

0 Kudos
Message 8 of 18

Counter is used but only expect a couple of iterations.


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.   Perhaps so it could be ported to RT or CompactRio as is...


True that I should and probably will switch to something more reliable like wait but the feature should at least halt.

0 Kudos
Message 9 of 18

Instead of manually assigning Processor 0, set the Processor to -2 to let LabVIEW handle the assignment, and see if that changes the behavior.

NI Alliance Partner
Message 10 of 18