Timed Loop Priorities not working in LV-RT

[Jaegen]

Hello,

I'm running a Real-Time application with several timed while loops. I've attempted to set the priorities of the loops so that they will execute in the desired order. For the most part this works, however one loop is apparently being pre-empted by lower priority loops.

I've attached a screen shot of an execution trace I ran displaying this. The custom flags indicate Preemption Start (Green), Preemption End (Red), In Queue (Yellow), and Loop Done (Black). Everything seems to run fine at first: The loops execute to completion through priorities 1000, 90, 80, and 70, but the 60 loop ("Slow") runs for about 5 ms then gets pre-empted by the loops with priority 50, 40, and 30. As far as I can tell, there are no "waits" inside the "Slow" loop which would make it go idle and allow the other loops to execute. Does anyone know what will allow a lower priority VI to pre-empt a higher one in LV-RT?

I'm running LV 7.1.

TIA,

Jaegen

[Jaegen]

Somehow the attachment got lost - here it is:

[cous]

Hi Jaegen,
I understand that you have a lower priority timed loop that preempts a higher priority loop. As you mentioned, having a wait or a subVI within a timed loop could cause it to give up the processor to another, lower priority loop. Do you have any subVI's within the timed loops involved? If so, have you modified their priorities? When LabVIEW processes timed loops, it sets their priority below the VI time-critical priority and above the VI high priority in LabVIEW. Changing subVI priorities could thus change the way the code is executed. A good thing to try would be to run your code targeted to LabVIEW for Windows to see if the same odd preemption behavior occurs. This will tell us if it's a problem with the way the RTOS processes the timed loops, or if it's a problem with the code itself.
Thanks for contacting NI,
Marcus G.
Applications Engineer
National Instruments

[Jaegen]

Marcus,

Yes, I do have sub-VIs in all of my timed loops. The only priorities I've modified though have been to set functional globals to subroutine priority.

I did some more digging, and found that the "Slow" loop is being pre-empted just after a call to the "Write File" function. This is inside a sub-VI that is writing data to an ASCII file, and it's a fair amount of data every execution. My guess is that this function sends the data to a lower level disk I/O driver, and is essentially "idle" while it waits for the low-level driver to return, allowing other loops to operate. Does this make sense to you? If this is the case, it's not really a problem. I may want to restructure my loops and priorities somewhat, and possibly put the logging in it's own loop, but otherwise it's pretty straightforward.

Again, it would be nice to have a list of all these operations which can cause a timed loop to go idle and be preempted 🙂

Thanks,

Jaegen

[cous]

Hi Jaegen,
The behavior you found makes sense. The write to file could put the thread in an idle state and allow a thread of lower priority to execute. Unfortunately, we don't have a list of VI's that cause idle states and allow preemption. Restructuring your code as you suggested is probably the best idea. Since file I/O isn't a deterministic operation, I would recommend using an RT FIFO to move the data from the "Slow" timed loop to another loop of lower priority. This will ensure that the "Slow" loop will deterministically complete its execution without being preempted by a lower priority loop. If you haven't used an RT FIFO before, then you can learn more about how to use them in this tutorial:
Real-Time FIFO for Deterministic Data Transfer Between VIs:
http://zone.ni.com/devzone/conceptd.nsf/webmain/3a9b9598f6c4d06186256ab8004f6340?OpenDocument

I hope this helps you better architect your system.
Best regards,
Marcus G.
Applications Engineer
National Instruments