LabVIEW Realtime - Calls to Shared Library Node are not being Prempted by Higher Priority (time-critical) Loops

[AlexDubya]

Fair test and that makes sense. Though maybe one more test could demonstrate if my DAQmx code has a problem.

If i create a simple task on my 6289 M series daq that sets an digital output high when it enters the time critical loop and low when it exits the time critical loop and I run the same test using the infinite loop DLL call I never see the digital output line toggle. I use the DAQmx Express VI to create the task outside the timed loop and then I start it before I enter the loop (and I've tried starting it inside the loop with little change). Inside the loop I suggest doing at a least a 100 microseconds of "work" (add up 1000 random numbers) so if a scope is connected on the digital output and edge triggered it will be easy to see A) Loop jitter and B) if the DAQmx task is starved. When I do this test with the DLL call disabled I see a periodic wave on the scope representing my loop entering and exiting. If I enable the DLL call I see no waveform.

I agree that LabVIEW correctly handles the DLL priority which was the primary concern but is it possible the DAQmx task is "coupling" with the DLL call in some way?

Since I never saw the bit toggle I assumed the loop was being starved

Thanks Brian,

-Alex-

[iRish]

Hi Alex,

I understand that you worked with my colleague Kevin regarding your issue with your data acquistion test mentioned in your last post.  I'm going to assume that your issue is now resolved?

To summarize for those following the issue on the forums:
The front panel graph updates on the host computer, displaying the DAQ data is not executed in a high-priority thread, which is why he was not seeing any information.  Kevin helped him to connect a display to his RT controller directly which allowed us to see dynamic RT data as it was being captured.

Regards,

[AlexDubya]

Just to have a complete thread on this:

The final answer is LabVIEW correctly preempts even when using a DLL. The issue came about because when one loop spools up to infinite usage the UI thread WILL be starved which is why my example code (see higher in thread) appears to demonstrate stalling of execution.

However, LabVIEW is correctly executing the higher priority loop just the UI thread isn't updating the indicator because the remaining 100% of the CPU is being used.

Thanks NI for the great support on this issue though.

I will point out that in a preemptive multithreaded environment like LVRT having threads which you CANNOT affect the priority of but are still important breaks part of the preemptive multithreaded nature of the system. The two examples I have found of this are: 1) the UI thread   2) A little keepalive() thread that pops up the "PXI stopped responding" dialog on the PC host.

The end effect of this is that IF you use 100% of the CPU on a LVRT system you will 1) lose UI functionality (if you had an abort button this could be bad) 2) Lose UI functionality on your host because the "PXI Stopped responding" dialog box does not allow you to adjust any other properties in LabVIEW.

To avoid using 100% of a CPU you must "yield" some time when you're doing something very busy - this behavior is like a cooperative multithreaded operating system yet we know LVRT (and PharLap) are preemptive at least by design.

I propose NI give user access to the "quiet" threads on a LVRT system so that we can at least adjust their priorities and avoid this preemptive, partially cooperative, multithreaded OS issue.

-Alex