Why does my distributed system manager prempt cRIO timed loops

[viScience]

Under certain conditions the DSM can interfere with the determinism of high priority timed loops in my rt code.

I have verifed this by detecting missing interations from within my loop and have noticed that when a cRIO

module tree is first opened it will max out the CPU and wreck havok with my timed loops.  My cpu is running around 80% so

it seems it should have enough bandwidth to allow the DSM to open PSP or Logos connections to the cRIO NSV.  Is there anyway

to lower the priority of this kind of access to the cRIO?  Will this be improved in LV2009?

Thanks

[George_P_Burdell]

sachsm-

I am assuming you are running two timed loops in parallel and you are doing all your data transfer to your host machine in the bottom (lower priority) loop.  If this is the case then you should not see a drop in performance due to what occurs on your host machine.  Is this the case?

[viScience]

I actually have 7 timed loops running.  The one in question that hiccups when I fiddle with the DSM is the NSV loop set to a priority of 5 which is the 2nd highest priority in my system.

I monitor the 'Finsihed Late' status within the loop and capture it with a RT Fault Error.  Again, my question is why does the DSM have the capability to disrupt a higher priority task.

I also find that FTP transfers can hose up my RT timing.  It seems to me that all of these 'remote' access methods should run at a low priority and should be innocuous.

[jkurtw]

Hey Mike,

Are you using normal network published variables (no RT FIFO enabled) in your NSV Update SubVI? 

Even though you have set the timed loop to run at priority 5, the shared variables use the lower priority Shared Variable Engine thread that will induce jitter on your timed loop if it is busy. In short, you have a shared resource in your timed loop.

To avoid inducing jitter on your timed loop, make sure you enable the RT FIFO option on the shared variables. By enabling this option, LabVIEW Real-Time will ensure that your subVI runs deterministically.

Kurt 

[viScience]

I appreciate your suggestion.  I went ahead and enabled the RT FIFO on all my NSV's.  So far this did not

solve the problem.  Question - Do all the subvi's within the NSV Update timed loop have to be set to a min. priority to prevent

DSM preemption?  Current set to the default Normal Priority.

Thanks

[George_P_Burdell]

sachsm-

What exactly do you mean by “DSM Preemption”?  Looking over your code, because all of your timed loops are in a State Machine, they will all have to execute before moving to the next state.  This may be what is causing the interference of your determinism.  Also, I’m sure you already know the higher the number the more priority the timed loop gets.  You may want to ensure there is sufficient timing associated with each loop to execute without interfering with each other. 

[viScience]

Although my timed loops were set to a high priority, the containing subvi's were set to Normal priority.  I found that

changing the priority to Time Critical prevents the DSM from preempting my timed loops.  I also found that enabling

the RT FIFO cost me around 5-8% cpu so I have turned it off for now since it does not seem to neccesary.

[jkurtw]

Hi Mike,

The RT FIFO cost some CPU because it kicks off a loop in the background which, in an RT-safe way, copies your data in to a communication loop, which communicates over the network. This way any jitter in the background communication loop does not affect the timing of your control code in your timed loop.

You can learn more about it here:

Using the LabVIEW Shared Variable: http://zone.ni.com/devzone/cda/tut/p/id/4679#toc2

As far as the DSM Preemption, I believe this is what is happening... the shared variables use the NI PSP or publish/subscribe protocol. Basically, if no one is reading the variable, then their is no CPU tax for serving that variable up. When someone "subscribes" to that variable, then the engine will send data to that client.

When you open the DSM, it subscribes to all the variables you are viewing in it, thereby adding load to the variable engine. Since you are using shared variables in your subVI (without RT FIFO) they are tied to that process and slow down your loop.

That being said, your subVI priority should get inhereted from the timed loop. You should not have to set it manually to time critical.

So, if you have RT FIFO enabled, you should not see a hit to your timing... even though you are 🙂

Leaving those subVIs set as time critical is probably not a great option, because it could have an adverse affect on other parts of your code that need processor time. 

Another good option is to write to RT FIFO single-process variables in your NSV Update subVI, which is RT-safe, and then in another lower priority timed loop, read the RT FIFO single-process variables and write them to network published variables. This seperates your RT code from your network comm. code.

Message Edited by jkurtw on 07-29-2009 12:06 PM