DLL call within Timed Loop caused Hangup

[TurboPhil]

I have a Labview application (v8.6) that calls a .NET DLL using constructor, property, and invoke nodes to perform some thermodynamic calculations. A similar program was able to run indefinitely with no problems, however, when I modified the calling VI to run the DLL within a Timed Loop structure (as opposed to a regular While loop with an ms Wait function), the loop would eventually hang up. When the DLL was called within a Timed Loop in a compiled executable, it would run for 12-24 hours without a problem, and then eventually it would get stuck on one of the DLL invoke node method calls. Because of the long time scale, I have not been able to successfully repeat the problem in the development environment. I finally tried replacing the Timed Loop with a standard While loop, and I have yet to see the hangup happen (after about 36 hours of running).

So my question is: could the Timed Loop-DLL call really be the source of the problem? Is there a chance that the timing/prioritizing going on under the hood with the Timed Loop could be conflicting with timing/prioritizing/multithreading within the DLL?

My first thought would, of course, be to blame the DLL developer (obviously, it couldn't be my Labview code causing the problem!). However, the DLL runs without crashing for such long periods of time that it seems unlikely that it could be a fatal error in its execution. Furthermore, the code contains multiple Try...Catch blocks and passes any system exception messages out to my calling VI--when there are errors (DivideByZero, etc.), it still doesn't hang up.

Has anyone else run into similar problems calling external code within a Timed Loop?

[jaraalmonte]

Timed loops are generally reserved for deterministic code only (at least that's how I code), if the DLL code is not very deterministic then at best you may just loose cycles. What OS are you running th code on? If it's not real-time, then you may have additional background processes fighting for CPU time. I would recommend either increasing the period of your timed loop, or moving back to the while loop. To see whether it's a problem with the DLL not finishing in time, you may want to log the previous "was late?" indicator. Also, why are you trying to switch to a timed-loop (just curious)?

[TurboPhil]

I'm running the application in Windows XP. It is a pretty critical loop--it is performing calculations whose results are used as feedback for closed loop controls on a PXI RT target--so I want to ensure that it is updating regularly. That is why I tried running it in a Timed Loop.

While running the calling VI in the development environment, I was monitoring the "was late?" indicator as well as the iteration time, and I never saw it run rate or skip cycles. The DLL has a few For loops that run an unspecified number of cycles (the calculations are reiterated until the results converge, which may take a varying number of iterations), so it is not entirely deterministic. But, as I said, the Timed Loop that calls it (running at 10Hz) never runs late. And even if the DLL took an excessive amount of time for a couple calls, the worst I would expect would be some missed cycles, not a complete hangup of the calling VI.

As of this writing, my code (running the standard While loop and Wait until Next ms Multiple) has been running for 3 days straight; the Timed Loop version would hang up typically within 12-24 hours. So I am pretty sure the problem is with the Timed Loop-DLL interaction.

[Norbert_B]

First of all, running time critical code on a non-deterministic target for a closed loop control is dangerous. Even if experience shows that it works in this case, it is nothing which is recommandable and i would never do this.

That being said, we have to take a look into the DLL-issue:

Is the CLFN (Call Library Function Node) configured for "Run in any thread" or "UI thread"? 

Depending on the settings, i can image different "mess my system up" scenarios:

a) UI Thread: The content of a timed loop is included in a single thread. Calls into the UI thread enforce a threadswap leading to messy behavior of the timed loop

b) Any Thread: The DLL is not thread safe and is creating any of the following issues:

    - Dead Lock

    - Priority Inversion

    - Starvation

 hope this helps,

Norbert