How to robustly program around SVs ?

[AlexS]

Folks -

I've got a few VIs in a project that has been running on one host for 2+ yrs. One vi reads a few shared variables from another network host once per second, and makes a local copy of each. The local copies are then read in the other vis in the project. Today , one vi stopped getting an updated copy of one SV (other vis got the updates) , and things crashed. This is the second time this has happened in the 2+ year life of this project. The last time, I got NI folks to look at the project and say yep, this is simple and really should work, always. They then suggested that I open the sub vis and replace the SVs with new copies from the project tree - delete all the old references by hand drag-and-drop new ones in- and try again. This worked but was hardly a satisfactory answer. I tried digging at them a bit to find out about the SVE and any diagnostics or even a general picture of the SVE, just to try to think through some routines that might improve the reliability of the local SVs, without success either. More recent projects with networked cRIO modules had similar reliability issues. This is on LV2009 SP1.

Will LV10 improve SV reliability much ? Do I hear any suggestions for coding around these things ? I figured local copies would be more robust than networked, I guess silly me. And this delete-and-copy to "Freshen up" your suddenly nonworking VI ? It scares me more that it DID work.

TIA

Alex

[viSci]

First off, are you wiring the error out of your NSV nodes? Do you trap or log any such errors?

The Distributed System Manager can be used to monitor RT SVE faults and CPU% which is good to monitor.

Has anything changed in your system over the past 2+ years? Do you regularly restart your targets?

Do you run on a private network? etc.

[AlexS]

>First off, are you wiring the error out of your NSV nodes?

Ah,no. Since the NSV value does update at the point where it is copied for local use, I assumed that the read of the NSV went fine. Is it possible then that the value updates, but other errors take place later on in that read transaction ?

> Do you trap or log any such errors?

Well, I sure will now that you've mentioned it.

>The Distributed System Manager can be used to monitor RT SVE faults and CPU% which is good to monitor.

OK, I'll take a look at that too. I've only used it while writing and laying things out, so far.

I'll start there, looking for NSV errors, thanks for the pointer.

Alex