LabVIEW OOP Class Composition

[Robert-Michael-Ward]

Dear NI Community,

I am working on a project that will make use of Object Oriented Programming (OOP) techniques.  There seems to be a wealth of resources on topics like inheritance and dynamic dispatch but am really struggling on how to implement a composition.

Here is the issue...  I have an instrument that may have several (relay) cards present to be determined at run time.  I thought that OOP composition would be the most desirable technique as it is a `has a` relationship rather than `is a`.  My parent class is "Instrument" and it has a property which is the visa resource and the children class is "relay card" which has properties; module slot/analogue bus/ relay state.

Instrument:

Properties: Visa Resource

Methods: Init, Self Test, Close etc

Relay Card:

Properties: Module Slot, Analogue Bus, Relay State (2D boolean array - XControl)

Methods: Init, Toggle Relay, Close etc

When I execute the Toggle Relay method I need to get the Visa Resource property from the parent class.  I have done class compositions in text based languages which made use of pointers such that the children have a property "parent" which is a pointer to the parent and the parent has a property "children" which is an array of pointers to the respective children.  Therefore to get the visa resource we might do get(@Parent,'Visa Resource') simples.

However, in LabVIEW... urm not sure!  I looked into using a DVR to do the aforementioned method (see attached code LV2013) but came unstuck when considering that branching the class wire makes a copy.  Furthermore by calling the Delete DVR method then I am able to generate multiple instances of the same object is disconcerting.

Anyway.  If anyone could provide any help or advice on how to implement class compositions in LabVIEW I would be eternally grateful.  Please let me know if any more clarification on the issue is required.

Thanks in advance,

Robert Ward

[Norbert_B]

Robert,

from the setup, it is clear that your OO-experience is based on textual OO-languages. However, even if LV can OO since version 8.2, LVOOP does follow the very basic concept of LV: dataflow programming.

There is a famous sentence regarding OO in LV: The wire is the object.

DVR is a method in LV to get handles on specific data sets. A DVR of a class is indeed the handle to a single object. However, branching the DVR wire copies the handle and access must be protected which is what the Inplace Element Structure does. Circular usage of handles (A => B => A) is prohibited in LV and creates invalid VIs.

Regarding your question in the Instrument Init VI: Yes, you copy the object, create a handle and add the handle to the original (not the copy).

My recommendation is to not use DVRs but put the relay objects directly into the instrument object (as array of class "relay"). The pass around the instrument where it is needed and each user retrieves the relay object necessary, modifies it and puts it back in the instrument.

Do you need parallel access to relays?

Norbert

[Robert-Michael-Ward]

Dear Norbert,

Thank you for your response. I think you have hit the nail on the head - my experience with oop is in text based languages which is why I am struggling to bridge the concepts with dataflow in LV.

My intention was to have an Instrument main display window and to load in subpanels of a relay display window based on a user selection in a listbox which would populate at run-time.

I do need parallel access to the relays which is why I thought this method would be best as that way each subpanel could execute a toggle relay sequence independently of one another.

Thanks,

Rob

[Robert-Michael-Ward]

Still haven't found a solution to this yet. It seems as though class composition doesn't lend itself to LabVIEW OOP favourably 😞

Thanks,

Rob

[ChrisK88]

If Robert needs parallel access to relays, in reality, the only parallel way to pass VISA reference without it puking would be a DVR with an in-place element structure, correct? That way both "parallel" accessors to the relays would execute serially, while one blocks access to the other during execution until it's finished.. 

http://www.ni.com/white-paper/9386/en/

[Robert-Michael-Ward]

I guess my frustration with all this is that in a text based language it is not even an issue. Most of the online help about OOP in LabVIEW is all about inheritance & dynamic dispatch which makes me wonder if a neat way of implementing class composition is even possible.

[Intaris]

It's an area which needs a bit of care and attention, that's for sure.

I have already implemented a medium-sized object composition and the need to define wrapper methods for each and every little function of the composed objects is plain tiresome.