03-05-2010 01:53 PM - edited 03-05-2010 02:02 PM
...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.
09-27-2010 04:09 PM
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,