Aborting a timed loop causes LabVIEW to hang

[Manudelavega]

Hello,

I have a timed loop which is sometimes instructed to run slowly (for example 10s rate). So when I want it to stop, I don't want to wait until the next "normal" wake-up which might happen up to 10s later. This is where the Stop Timed Structure.vi is handy, since it forces the loop to wake up right away. Most of the time this works just fine, but once in a while the Stop Timed Structure.vi hangs forever and I can't do anything except killing my application in the Windows task manager. Not great when we have a customer-facing product!

Has anybody experienced this issue and would know how to fix it or work around it? It feels like a big LabVIEW bug to me...

Thanks

[Blokk]

It could help if you attach your VI so people can have a look what can be wrong. Another thing, is there a special reason why you need a timed loop? I do not remember when I ever needed a Timed Loop under Windows, of course a Real Time OS is a different story.

[RavensFan]

The work around would be to use a timed loop, or a normal while loop that runs at a faster rate.  Use an elapsed time timer to see how much time has passed.  Inside the loop would be case structure that does nothing if the 10 seconds haven't passed, or does what you want it to do if the 10 seconds have passed.  You can have your other code send a stop command to the loop (by notifier?) to stop the loop early if you need to.

[Manudelavega]

@RavensFan wrote:

The work around would be to use a timed loop, or a normal while loop that runs at a faster rate.  Use an elapsed time timer to see how much time has passed.  Inside the loop would be case structure that does nothing if the 10 seconds haven't passed, or does what you want it to do if the 10 seconds have passed.  You can have your other code send a stop command to the loop (by notifier?) to stop the loop early if you need to.

---

I know I have that option but I'm trying to stay away from it if possible, since I can have up to 8 clones of that VI, so up to 8 loops running faster than they need to, which is a "waste" of CPU. Performance is key since it's part of a big SCADA software that also has plenty of other loops for monitoring, calculating variables, PIDs, graphing...

[altenbach]

What is happening inside the timed loop?

[Manudelavega]

It basically calls a subvi to read some variables stored in a DVR, and then replace some elements in a 2D array of strings, and finally put this array in a queue. That's pretty much it.

Since I don't need to use the abort function if the loop is already awake, I put in place a locking mechanism based on a semaphore. The very first thing the timed loop does after waking up is acquire the semaphore, and it only releases it before going back to sleep.

My stop function acquires this semaphore (it has a 100ms timeout just in case the timed loop is using it). Once it acquires the semaphore, it waits 10ms and check the #waiting status. If #waiting > 0, then the loop is awake and trying to acquire it, so all the stop function needs to do is set a "stop" Boolean to true, which is checked by the timed loop for its exit condition. So in that case I don't even call the Stop Timed Structure.vi.

If #waiting = 0, then the timed loop is sleeping and the stop function will try to abort it using Stop Timed Structure.vi. That's when the hang happens. So the hang only happens when the timed loop is sleeping. That's why I think (but might be wrong obviously) that the code inside the timed loop is irrelevant...

[RavensFan]

---

@Manudelavega wrote:

I know I have that option but I'm trying to stay away from it if possible, since I can have up to 8 clones of that VI, so up to 8 loops running faster than they need to, which is a "waste" of CPU. Performance is key since it's part of a big SCADA software that also has plenty of other loops for monitoring, calculating variables, PIDs, graphing...

---

I'm not talking about running this loop infinitely fast.  Right now you are talking about a 10 second loop cycle which is glacially slow in computer terms.  How fast do you need the loop to react to an abort command?  Within a second?  A loop running once per second is still pretty darn slow and isn't wasting any CPU  (even with 8 clones)?  Within a 1/10th second?  Now a 100 times faster than you were, but still nothing that fast that would waste a CPU.

In the false "do nothing" case, you just put a minor wait function so you don't have a CPU burner.

[Manudelavega]

I guess that's not unreasonable. I will probably end up implementing that workaround. But it's frustrating to leave a major LabVIEW issue unsolved...

[SoarOnSon]

If you would like to further explore the LabVIEW issue, try to simplify the VI into a reproducible case where LabVIEW freezes each time the VI is run. Then you can create a service request and contact support at NI (http://www.ni.com/en-us/support.html) for further assistance.

Josh S.

Applications Engineer

[Manudelavega · Accepted solution]

I found the culprit!!

Back in the days a coworker of mine had the noble intention of increasing the performance of our application by adding some code that would assign a HIGH priority to its thread in Windows (you can do it manually through the task manager).

It took me a while to figure that out, I’ve been stripping code from our application bit by bit, until that little subvi was the only thing remaining!

The online documentation does recommend not to modify the priority and warns that unexpected behaviors might occur. So I’m not sure if NI will try to fix anything. But at least you guys should add this to your troubleshooting database so that next time you hear about this symptom you can tell the developer to check this setting.

I’m attaching a project that will reproduce the issue very quickly if you set “HIGH PRIORITY”. It will run smoothly all night long if you set “NORMAL PRIORITY”.