From my simple test I believe that once LabVIEW enters a Call Shared Library Node it cannot perform a context switch to a higher priority timed loop. This is in conflict with the PharLap/LVRT documentation I've seen that says the highest priority thread will always run.
I made a simple test case using two timed loops and a nearly empty DLL made using Visual Studio C++ 2005.
One timed Loop (Loop A) is placed using 1ms period and priority 200
Another timed loop (Loop B) is placed using 50ms period and priority 100
Loop A compares its current loop iteration and if it is greater than 2000 it sets its stop condition to true.
Loop B compares its current loop iteration and if it greater than 2000 it sets its stop condition to true (2000 * 50ms = 100seconds)
Loop B also has one "Call Shared Library" node which points to a DLL. The DLL function being called is called WhileLoop() and is simply:
void WhileLoop()
{
while(1)
{
//do nothing
}
}
When I execute this code I observe CPU load on my 8196 PXI to go to 100% which I would expect from a while(1) loop however the loops never exit and processor utilization remains at 100% (even after 100 seconds).
The comparison in LoopB is not really needed if the execution never returns from the while(1) loop then of course it will never exit but my biggest concern is the higher priority loop (Loop A) also does not appear to exit.
In my real application I have time critical code but I am using DLL calls in lower priority timed loops and these are causing excessive jitter in my time critical code.
Does anyone have any thoughts or input on how I could solve this? I need to make DLL calls and I can't predict how long the DLL calls will take (non-deterministic parts of the application).
Thanks
-Alex-
EDIT: My DLL calls are set to run in "any thread" and I'm using LabVIEW 8.5 and realtime 8.5
Message Edited by AlexDubya on
01-23-2008 05:51 PM
