LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

read buffered network published shared variable

Solved!
Go to solution

 


BLAQmx wrote:

...we have concluded this is not a bug...

   1. Changing this would require a major changes in the underlying code governing DataSocket behavior.
   2. Changing this could adversely effect applications that have already been designed with this behavior in mind.




NI places value on matching behavior between "like" technologies and also on "past" behavior within the technology.  This seems logical in theory, but its implementation has been somewhat arbitrary.  With emerging technologies, I'd like to see NI place less value on "like" and "past" and place more value on "intuitive".

For example, at least with OPC, bound NSVs (Network Published Shared Variables) -- that is, where a local NSV is bound to a remote NSV -- block/timeout when reading a value that was re-written.  This was done to match the "like" behavior of Lookout, which left the developer (me) to discover this through a long process of troubleshooting "what on earth was going on".

[In case you want to demonstrate this for yourself, I've inlcuded an example:
Unzip the Shared Variable OPC Demo folder to your C:\ drive.  In LV 8.6, open the project, and run the Shared Variable OPC Demo VI.  Press buttons in order from top to bottom to get everything setup.  The Chicago Maroon and Burnt Orange {Go Hokies!} indicator will toggle when each operation is complete.  Then try writing and reading.  When you write the same value twice to any of the "bound" variables, you get a timeout upon reading.  This filtering is not "intuitive".  But, it does honor the value of "like" behavior with Lookout.]

NI has not always honored "past" behavior either, which is evidenced by this thread.  Much of my confusion (which I agree was necessary to digest the functionality here) was related to a behavior change when LabVIEW makes connections to NSV nodes.  In LV 8.6, LV made connections when each NSV node first executed.  In LV 2009, LV makes connections when the VI runs.  While not the same as the "past", the new behavior is "intuitive" when you understand the intended behavior of client buffer views.  "Intuitive" placed ahead of "past"... *Thank you*

To keep the current DataSocket blocking/timeout behavior when accessing NSVs honors "past" DataSocket behavior over "like" and "intuitive" NSV node behavior.

When users upgrade LabVIEW, they should know by now to watch out for changes to shared variables.  Shared Variables are NOT a mature technology.  There is still time to make connections to them via DataSocket, NSV nodes, and the Variable API "like" and "intuitve" for LV releases to come.

 

 


sachsm wrote:

BTW - I want to offer a big thank you to LabBEAN and BLAQmx for spending the time trying to sort through these thorny issues.
I am hoping that all this discussion will result in new white paper from NI on the subject.



I know I speak for Mark, too, when I say that it is an honor to be a small part of such a vibrant community.  Thanks Michael.

Message Edited by LabBEAN on 03-05-2010 03:02 PM

Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
0 Kudos
Message 41 of 42
(1,432 Views)

After a lot of investigation, documentation, testing, and editing I have finally posted a white paper that details the behaviors discussed in this thread.

 

Buffered Network-Published Shared Variables: Components and Architecture

 

A big thanks to all our forum members, espeically LabBEAN, for pushing myself and our LabVIEW developers to take a hard look at these questions and putting in the effort to create documentation to address them.

 

Cheers, 

Mark
NI App Software R&D
Message 42 of 42
(1,249 Views)