Issues with Shared Variables in Systems Running for Extended Periods of Time

[JimMacD]

I am designing a large SCADA system using LabVIEW DSC and cRIOs. My plan is to use shared variables to communicate the majority of the information across my network (much like "tags" in a normal SCADA system).

I'm wondering if anyone has experienced issues (connection failures, etc...) with shared variables running on systems for months (both real-time and windows based PCs) without the cRIO or PC being restarted/redeploying the variables. What is the stability of the Shared Variable Engine over extended periods of time?

Thank you for the input.

[viScience]

I have a system with 2 cRIO's each with Ethercat extension chassis.  Each cRIO hosts ~100 NSV's and is running the scan engine at 40 Hz.

Each cRIO is coupled to a HMI that has front panel control bindings to NSV's hosted on the cRIO as well as a windows hosted mirror library (used for citadel db logging) that is also bound to the cRIO NSV library.  The cRIO's have monay months of contiguous run time without reboot and I closely monitor cpu and memory usage and also rt performance metrics and will log faults if there are any such events.  I also use NSV's for messaging from the HMI to the cRIO for such things as setting zero offset values and deploying configuration parameters.  My overall findings are that the SV engine and the PSP are stable and efficient (especially NSV<->NSV and NSV<->HMI binding)

[shoemakesmusic]

I've found that you MUST use the data binding feature vs. dragging your shared variables to the block diagram.  At least that is true for version 8.6 and lower.  Having said that, it makes it very time consuming if you have a lot of tags.

[viScience]

Well most of us are using LV2009 and above where you can use NSV by binding, static nodes on the diagram or the programatic API which is similar to the way Datasocket used to work were you can open a reference to a NSV and then Read/Write efficiently.  I use all three methods in my cRIO app.  Binding for the HMI controls and indicators, API NSV access for across the board features such as Zero Offset management, Filtering, etc and then static tags for various process control loops, safety interlocks, alarming and such.  I have over 100 tags and the cRIO keep up with all this very well (<50% cpu)

[KyleTTU]

Hi JimMacD, 

The only time where you might run into an issue is if there are not enough resources on a real-time target to host the shared variables. This is due to the fact that you can starve lower level threads like the one needed to operate the shared variable engine.

As long as you have enough CPU time to give the shared variable engine time to run, you shouldn't run into any issues with this application.