Shared Variables should support LVOOP as a data type

[CMal]

Almost all LabVIEW data types can currently be sent through a shared variable without any hassle.  The notable exceptions are native LabVIEW classes, which cannot be selected as the data type for a shared variable.  This causes a problem for anyone who wishes to send objects across a network.  They are forced to rethink their use of LabVIEW classes, use a communication method other than shared variables, or flatten and unflatten the object on either side of the shared variable communication.  The use of classes is growing more common with every version of LabVIEW, so I think it is time for these two prominent LabVIEW features to work together seamlessly.

[PhillipBrooks]

I believe that CVI and Measurement Studio can also use the Shared Variable Engine. It might be convenient to wire LV directly to a shared variable, but CVI and Measurement Studio could not use this data.

If lvclass data is private, converting the class data to a type (with an accessor) that is compatible with these other languages seems to make more sense.

Question: (not rhetorical) What would happen if two different applications are configured to use a specific shared variable, but have different versions of the lvclass?

[CMal]

Philip,

You make a good point about CVI and Measurement Studio not being able to use LV objects.  It is already possible to use an accessor to convert an object to a type that can be read outside of LabVIEW, but that is an inelegant workaround for someone who wants to simply send an object between machines both running LabVIEW.  I believe adding this functionality for LV<->LV communication would not take anything away from those who are doing LV<->CVI/MStudio communication.  I would think that an error should be produced when CVI or Measurement Studio attempts to read a shared variable of an LVOOP type.  Keep in mind that I have no experience with shared variables outside of LabVIEW, so I may be missing something here.

The behavior with communication between two targets that have mismatched versions of a class should probably be the same as with file IO.  If you write a class instance to a datalog file on one machine, then try to read the same file on a machine that has an older (or non-existent) version of the class an error will be produced by the read function.  This is the general behavior I would expect with variables.

[AristosQueue (NI)]

There has been some debate (both within NI and with customers) about whether or not the flattening/unflattening solution is actually desirable. After all, if NI made the shared variable support classes, to do the writing to the variable, the object would be flattened to a string and then unflattened when the variable is read. In other words, having the shared variable support classes does not actually remove any work that the program has to do, so having the shared variable do this behind the scenes is just syntactic sugar. The negatives crop up with the issues that Phillip raised -- suddenly the shared varible is reporting a number of errors that it did not support previously, whereas by separating the (un)flattening into a separate node, it is easier to tell where an error is arising -- was it a failure to read a shared variable or was it a failure to unflatten the data therein? By keeping the shared variable ignorant of such complex data types, it is easier to swap out the communication mechanism used -- shared variables might get support for LV classes, but TCP/IP prims might not, or whatever other communication protocol comes along in the future (i.e., the network stream primitives that are brand new in LabVIEW 2010 -- effectively queues that are usable over the network).

Users may choose to create a custom string format for objects, one that can be unflattened by any system that uses the shared variable -- including CVI and MeasStudio. Having shared variables support classes directly does not get in the way of this, but consideration of exactly what private fields actually need to be exposed in that very global global variable might be encouraged if users are consciously aware of the serialization taking place.

I'm not pro or con this feature at this point... this post is merely to document debate I've heard about any intermachine communications protocol handling LV classes directly.

[Barionics]

I have, so far, avoided using OOP within LabVIEW for exactly this reason. I would love to be able to create global variables of type OOP.

[AristosQueue (NI)]

> to create global variables of type OOP.

You can create global variables. You want to create interplanetary and galactic variables. 🙂

[crossrulz]

Just be careful, because the interplanetaryShared Variables have been known to go past black holes and cause what we would observe as time delays.