LabviewNXG class property null

[andrewDJ]

Hi,

Is it possible to identify a class property as having been set or not, i.e. NULL or some equivalent?  So can I do something like (pseudocode):

if class.partName isNull

   partName = newName

else

   raise error

If not, can I do something like this (pseudocode):

if class isTypeOf NullManufacturedPart

Then ....

I could then use some form of pseudo-null representation - I haven't been able to find an 'isTypeOf' equivalent comparator or selector.

I'm trying to work out how best to work with classes in LabviewNXG and the manual or other information I've come across isn't clear - does it work the same way in NXG as CG as there seems to be more information for that?  

Thanks,

Andrew

[oscarfonseca · Accepted solution]

Hey Andrew,

I definitely recommend you check out the LabVIEW NXG topic: Classes and Object-Oriented Programming for more information about using classes in LabVIEW NXG.

LabVIEW NXG classes are built up on almost the same principles as LabVIEW CG, indeed. You can read more about them here: Object-Oriented Programming in LabVIEW NXG and LabVIEW Object-Oriented Programming: The Decisions Behind the Design.

While "null" values do not exist. I usually think of them as the default value, and compare them to the class default. Please note that I am not implying that the default state of a class' private data is the same as what "null" is in other languages.

Another option is to use the LabVIEW G object as "null", and try to cast it into the class you are hoping to receive.

Regards,

[andrewDJ]

Thanks Oscar - sorry it's taken some time to respond, but I've been reading some of your links and trying stuff out.  

I had read the linked NXG topics quite a few times so I have a reasonable idea of how to work with classes in NXG - I will also follow up with other CG documentation and resources on the internet for CG.  It may be worth stating I started OOP with Smalltalk back in the day so I have a good understanding of OO concepts.  The design paper you pointed me at was an interesting read, thanks.

I'm struggling to understand your examples, unfortunately, but let's see if I've got it.  Your use of "Default" is not a reference to LabView CG's "Default Instance" property from the LVClassLibrary reference or Get LV Class Default Value.vi is it?  I believe it's just the class dropped on the diagram, named 'Default' and with the 'value out' terminal linked to the = function?  So a new object is created with all its properties set to the default values defined in the Class Data View.

On that basis then...

If I define a property on MyClass to hold a MyOtherClass object there is no way I can see of setting a default value for that property on MyClass so I presume it just creates a MyOtherClass object with its own default values.  What I need it to do is create a 'NULL' so that I know it hasn't been set or can be reset (this is important) as my problem is to create a SCPI command that can take 0 to 14 additional parameters where the instrument response value contains data for those parameters in the same order so I need to know what to parse (i.e. know what was sent.)  I don't expect you to understand from such a short description but go with it for now and I can explain in more detail if what follows is missing the point...

What I could do, then, is define a Class hierarchy like:

AbstractBufferElement<----NullBufferElement<----ChannelBufferElement

                                           <----FormatBufferElement

(<--- is an inheritance link; buffer element is one of the parameters that can be sent by a command; Abstract... is the 'genuine' parent with common functionality and Null...is a rather construed way of determining fullness) Then:

MeasureVoltageCommand.channelBuffer ----> NullBufferElement

(---> is a reference, so the property channelBuffer holds an object of NullBufferElement). As NullBufferElement is the 'type', the default value for that property will be an object of NullBufferElement but it can be updated at runtime to be a ChannelBufferElement. It can also be reset to a NullBufferElement (although given the data flow nature of LabView, I don't think this will be necessary for my application.) I can then test for nullness against the class - I could even add a boolean property "isNull" to NullBufferElement set to True and False in all child classes.

If I understand your second image, you are trying to do something similar with G Object - so MeasureVoltageCommand.channelBuffer --->G Object.  The advantage of doing it this way is not having the rather construed Null class in the hierarchy the way I did it but a disadvantage would be that any object could be stored in that property (although my application would ensure it wasn't!)

Where you use the = function for comparing classes, is this comparing each property on the class for equality to determine that one class is equal to another and not that it is comparing to a memory location?  I ask this on the basis of a by-value approach to OO in LabView rather than by-reference.  From the context of your image, it doesn't appear to be a LabView equivalent of "isTypeOf".  Further, would this equality check on properties then deal with referenced classes, i.e. if a property on MyClass was actually holding a MyOtherClass object, would the = function then compare the properties of these embedded MyOtherClassObjects?

Thanks for your help,

Andrew

[oscarfonseca]

Hey Andrew,

Where you use the = function for comparing classes, is this comparing each property on the class for equality to determine that one class is equal to another and not that it is comparing to a memory location?

Yes, you are correct. I compare all the internal data to a default internal data for that object to know if it has changed or not. My assumption in this case would be that an initialized object would have information loaded into it, which would make it different to a default instance.

I ask this on the basis of a by-value approach to OO in LabView rather than by-reference.

Indeed, LV OOP is value-based. Another option you can consider is using a DVR (data value reference) to hold your object. This would behave in a similar was as a pointer does, and will carry the memory reference to the object in the wire, instead of the value itself. I recommend you explore other options before diving into this approach. Interesting article about it: By Value vs By Reference In LabVIEW 

From the context of your image, it doesn't appear to be a LabView equivalent of "isTypeOf".

Indeed. As I showed, you could use the To More Specific function and monitor the boolean of the error to know if it failed to cast it. However, this would just help when casting downwards in the inheritance tree. Another approach, as you mention, is using something as Get LV Class by Name and comparing the string with the one coming out from the class you expect.

Further, would this equality check on properties then deal with referenced classes, i.e. if a property on MyClass was actually holding a MyOtherClass object, would the = function then compare the properties of these embedded MyOtherClassObjects?

I recommend you try it. I would expect so, but I don't remember for sure. You could also consider holding the classes in an array or a set, and checking if the array/set is empty.

I think it's worth exploring the problem you're trying to resolve, instead of getting in the details of how to compare classes in LabVIEW. From your descriptions, it seems to me you're implementing something similar to a hardware abstraction layer:

• Introduction to OOP and Hardware Abstraction Layers 
• HAL/MAL: NI Test Engineering: How We Built Our HAL/MAL and What We Learned 

Regards,

[andrewDJ]

Thanks for those links, very interesting.  I suppose I am looking at an abstraction layer and I'd already started investigating separating functions and hardware although my need is way, way simpler than a large organisation like NI might require.  

More specifically, I'm really at a stage of investigating what NXG actually is capable of so I'm trying different approaches to the 'problem' at hand.  I could take the really simple approach of just writing the VIs to do very specific things that I need in my test - reuse isn't likely to be a big issue for me.  But if I just settle for that approach, I'm likely to miss some of the power of this tool.

It's all mainly driven by the fact that NXG doesn't have Instrument Drivers for my equipment, and I haven't yet decided whether to continue on re-inventing the wheel (for the fun of it) or switching over to LabView 2020 which does have the Instrument Drivers.

[oscarfonseca]

Totally understandable. Fortunately, both tools have their pros and cons, as you have seen, so the choice is open.

I look forward to the success of your application. Feel free to open a new thread if new questions arise about the platform.

All the best for your endeavor!