How to tell when the PSP server is ready

[viScience]

I have a HMI that talks to a cRIO via NSV's.  I am finding that when the HMI starts up, NSV data is not ready

for some time (500-800ms)  There does not seem to be a way to test the viablility of the PSP connection.

I have tried waiting for the error code out of the SV node to be zero but you must still wait an additional period of

time after that (100-200ms) before the data becomes valid.  In other words the SV tag is happy to give you invalid

data with no warning or error message.  That is a serious bug in my opinion.  Is there something I am missing here about

how NSV's are supposed to work?

[Smootastic]

Hi sachsm,

How many Shared Variables are you using?  Where are they hosted?  Does running the HMI prior to running the system hosting the variables eliminate this delay? 

[viScience]

The shared variables (~75) are hosted on the cRIO.  I can see them in the DSM prior to running the HMI.  The problem is that the HMI app

does not have immediate access to these NSV's.  You must first sit in a loop reading a dummy variable until there are no warnings then wait an additional 200-300 ms before

transactions propertly occur.  I know for a fact that others have seen this and I think someone in R&D should do the following:

1. Admit that yes indeed it works that way

2. Admit that it should not work that way

3. Apologize for not publishing documentation warning and advising people about this.

4. Tell us which version of LabVIEW is going to correct this.

[Darin_G]

Hi Mike -

This is Darin Gillis (we spoke on the phone about I/O Variables and Programmatic APIs once upon a time), current group manager of the software team who is responsible for the Shared Variable.

Without getting into the rationale behind all of the decisions NI has made with network shared variables to this point, here's my best attempt at answering your quesitons/demands:

1) On a cRIO with limited CPU bandwidth, yes it works that way.   What is really happening behind the shared variable node is that on the first few iterations it is trying to instantiate a PSP (Publish-Subscribe Protocol) connection in a background thread.   Why background thread?  Because the node doesn't have any timeout inputs, the node doesn't block.   It would be great if a warning/error was returned on that first read (I believe that in some cases, you will get a warning or error) but it appears that due to the current implementation there are race conditions that lead the node to thinking that it is connected even if it is not - and will return 'default data for datatype' with no error/warning in some cases.

Workaround(s):   A) If you're in LV 8.6 or later, use the 'show timeout/timeouts' right-click option on the node.  Wire up some reasonable timeout values, and the node will then be able to block until data is actually ready.     B) If you're in an earlier version, you can use the Datasocket Open primitive, which has a timeout, to verify that the variable you want to talk to is actually out there and 'connectable'.  After a successful Datasocket open, you should be able to run your nodes with confidence.

2) We added the blocking read option (show timeout/timeouts) in LV 8.6 because we didn't want the Variable to work this way.  But we did not want to break backwards compatibility by changing the behavior of the node without timeouts.  For better or worse, external customers write code coutning on behavior like this and we did not want to break their applications.   Another note, we have done some fairly elaborate work in the yet-to-be-released programmatic Variable API for the next version of LabVIEW to further clarify this -- and prevent people from having to use DataSocket as mentioned in Workaround B above

3) I'm sorry that this isn't better advertized.  I looked back through our variable bible (aka the Variable Whitepaper: http://zone.ni.com/devzone/cda/tut/p/id/4679) and we allude to this behavior but do not explicitly call it out.  The paper recommends 'warm-up' iterations in some cases and also says that our benchmarks all include a 1 second warm-up period before taking benchmarks.

4) Hopefully we have addressed this with the Blocking Read in LV 8.6 and the new programmatic Variable API in LV 2009.   It is likely that we will not change the behavior, ever, for the plain ole shared variable node.

Hope that addresses your concerns Mike, keep that feedback coming -- keeps R&D on our toes 🙂