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?
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.
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.
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 ...).
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...
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.
Instead of manually assigning Processor 0, set the Processor to -2 to let LabVIEW handle the assignment, and see if that changes the behavior.