Slow update of shared variables on RT (cRIO) after building exe

[markza]

Hi,

I've been struggling with this for the past few days.  I am having a problem with slow updating of shared variables on my RT project....but only after building the application into exe's.

The application consists of an RT target (cRIO 9073) sampling inputs at a rate of 1sec.  I have a host PC running the front panel that updates with the new acquired values from the cRIO.  These values are communicated via shared variables.

Once the cRIO samples the inputs, it writes the values to the shared variables, and then flags the data as 'ready to be read' using a boolean shared variable flag.  The hostPC polls this boolean shared variable and updates the indicators on the front panel accordingly.  

Now, this worked fine during development, but as soon as I built the RT exe and host exe's, it stopped working properly and the shared variables ended up being updated very slowly, roughly 2-3sec update time.

To give you some more background:

• I am running the Labview 2010 v10.0.
• I am deploying the shared variable library on the RT device (as the system must work even without the hostPC).  I have checked that its deploying using Distributed System Manager, as well as deploying it into the support directory on the cRIO and not the exe itself. 
• I have also disabled all firewalls and my antivirus, plus made sure that the IP's and subnets are correct and its DNS Server address is set to 0.0.0.0.
• There are 25 shared variables all in all, but over half of those are config values only used once or twice at startup.  Some are arrays, plus I dont have any buffering and none of them are configured as RT FIFO's either.
• The available memory on the cRIO is about 15MB minimum.

What strikes me is that it works fine before building exe's and its not like the cRIO code is processor intensive, its idleing 95% of the time.

[viScience]

Are you saying the the NSV's hosted on the cRIO are updating at 2-3s instead of the programmed 1s interval as verified by the DSM?

If so then you may have some unexpected timeout occuring within the cRIO timed loop.  Do you wire the error terminals on your NSV nodes?  Perhaps

you are getting some sort of warning message from the SVE that would indicate a problem.  Also you might look into binding your PC HMI indicators directly

to your cRIO NSV's.  This would be much more efficient than polling. 

[markza]

Thats exactly what I'm saying, it takes 2-3seconds to update the values.

I have tried taking out the polling on the PC side, and registered an event on the changing of that shared variable and that doesn't do anything to change the slow update time.  Even if I stop the PC, and just monitor the shared variables in DSM it updates slowly.

I also tried utilising the "flush shared variables" vi to try to force the update....that does nothing.

I wire all the error nodes religously. Still no luck.

Its very strange, I'm not too sure whats happening here.  These things should be able to update in 10ms. 

[viScience]

On some cRIO's I have seen a problem when the gateway address is set to 0.0.0.0  which you would think would be ok.  But on some older BIOS's this create havok with the

DSM and NSV's.  You might want to try to set the gateway to the IP address of your PC host which is generally innocuous.  Other than that I would suggest creating a simple 1s timed loop that flashes the user led and toggles a simple NSV at the same time to verify that it is not another sort of timeout issue in what you think is a reliable timed process.