(How) Can I change vi execution priority at runtime

Question

Hi all,
I am using Daemons (free running VI's) and I communicate to them through Queues.
They are part of my device driver architecture and use a producer architecture (For Acquisition) or a consumer Architecture (For Control)
I have a single Daemon VI to which I deploy a "Device Object" using a Polymorphic class implimentation.
This implimentation has one subtle shortfall,
I am not able to change the execution priority at launch
There is a property node that taunts that it is possible but the help (And run time Error message) says it not available at runtime.
Does anyone know of an alternative method?
Here are what I have thought of to-date:
1. Have 5 different daemons each with a different priority [Distasteful for Code maintainance]
2. Make Priority Low, and ensure that at least 1 VI in the driver has a high priority [Not sure if it works, obscure implimentation]
Kind Regards,
Tim L.
iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT
Solved!
Go to Solution.

Answer 1

Ben,
I debated wheter or not to put more information in my post, I didn't want to bore my potential support Sensei's.
Here Goes:
As I hinted in my initial post, I am devoloping a set of drivers for my large application.
I am using a compact Field Point and am under some fairly aggressive rescource pressures.
Heavy RS422/485 Serial Comms @115200, Digital Acquisition and some heavy data processing.
My understanding of this type of system (Jump in if you have any improvement suggestions):
Priority #1 [High Priority](Producer) is to get data out of the Acquisition Buffers and in my case, perform Writes/Outputs/control activities as demanded.
So any "Hardware" Device Driver Daemons that I lanuch need to be run at high priority.  The drivers should do as little as is necessary so as not to hog this thread. Event based architecure is preferred over polled.
These drivers tend to be launched as Daemons so that they can run in a different priority and are not affected by other activities, they are inherently asynchronus.
Priority #2 [Above Normal Priority](Consumer->Producer) Protocol/state interpretation/Data Filtering.
Now that the data is out of the buffers, what does it mean? is it a valid communicationss message, was there a button pushed, is there an object in the transducer field.
These functions may take a bit longer (but not too much) to execute, but as they are on a lower priority, buffers can continue to be emptied.
These "filters" tend to be launched as Daemons also so that they can run in a different priority and are not affected by other activities they are inherently asynchronus.
Priority #3 [Normal Priority](Consumer) Number Crunching, Heavy Lifting , Control determination..
An event has occurred and some caculation interpretation and potentialy control needs to be performed, Do it.
Tend to be event based and as there are multiple stimulii tend to be best managed by an event structure.  This allows for interaction with the front panel as well (should the need arise).
Priority #4 [Low Priority](Slip-Scheduled) User interface/User Data/Report Generation.
Who Cares if it is a bit late, Work away in background.  In the case of user updates, they can slip later and later, no need to catch up.
For others reading this thread, I found This Module Help invaluable in understanding how Labview manages execution priority.
Theory Done, I am essentialy a lazy programmer, and don't like to write and maintain too many different .vi's if I can help it, <Rant> ESPECIALY IF THEY ARE THE SAME VI WITH A DIFFERENT PRIORITY! </rant>.
So I have written one Daemon and one Daemon manager (to rule them all). For each driver I require, I launch a Daemon, passing the "Base" Class object to the Daemon prior to Run, I rely on the override capability of polymorphism to choose the correct methods.
My "Base" Driver class contains all of the functions required for operation.  I use it as an enforcable template for future driver development (It also auto fills in my Icon's wich is great for a Lazy Programmer like me).
I have established that my protocol driver (Priority #2) is compatable with the same daemon Architecture from above, Instead of looking at hardware, it monitors a Queue/Notifier/User Events from the lower level hardware driver.
I was very smug when I figured that one out, until.... I realised that they would need to be launched at different priorities to respect the RTOS, and thus my question.
I am not trying to change priority per-se, but to choose one prior to launch and then to leave it.
Cat Killed? (Curiosity Cured?)
iTm - Senior Systems Engineer
uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT