Inheritance and Override Functions in Nested Classes

[ARC5200]

So this will seem fairly long winded but I believe some people here will find this to be an interesting question and hopefully people can point me in the right direction. To give you guys some background I am a process control integrator working with PLC's and CRIO's to create automated solutions for out clients. I have a background in Software engineering and have worked a great amount in the past in Object Oriented languages such as Java or C#. I have only been using LabVIEW for the past 2 years and this is the first time I have utilized the OO features of LabVIEW. 

One of the first things I looked into was if interfaces and abstract classes existed in the OO concepts for LabVIEW. I learned quickly they do not and after looking through the white paper I had a grasp as to why. Which is fine but it lead to the rest of what I am going to explain.

 

The end goal is to create some Equipment control modules based on the S88 standard that is used in process control. Typically an EM would have a Start(),Stop(), and Abort() function. We would like to create a library of these EM’s and keep with an overall good structure using inheritance in a OO style.

 

I can inherit information from a parent class, and I can override the functions from a parent class as well. What is giving me problems however is that I am encapsulating  a parent class object in the child object data area and I am attempting to utilize an override function on this encapsulated object. Our reasoning for an encapsulated object is to allow for dynamic creation of new EM’s that can be utilized by a previously created EM. I would like to be able to abort a parent EM and have that abort any cascaded EM’s that are children of it.

 

With my current setup that I would use in C# I am running into a recursion error. Picture should be attached. I believe I understand the reason for this error, which is that technically we are recursively creating these EM’s and therefore can have essentially an infinite amount in memory to interact with. This wraps into why I was wondering in the first place about interfaces and abstract classes. If my top Object was actually a interface instead of an actual class you would be able to declare it but it would not be instantiated until a constructor created the more lower down classes. This would get rid of this recursive error as I could check if the child EM is instantiated before I decided whether a function could be utilized on it.

 

So my question to everyone is, is there a work around that would give me the same result or is there a more LabVIEW acceptable way to do this?

 

Attached is my UML diagram, the error I am receiving, and the LabVIEW Project that I created to attempt to demonstrate the architecture I wanted. Thanks for any help!

 

 

 

 

ClassOOTest.zip

[Tim_S]

Hrm... This resembles a linked list to me.

[JKSH]

3 hours ago, ARC5200 said:

So my question to everyone is, is there a work around that would give me the same result or is there a more LabVIEW acceptable way to do this?

I don't have LabVIEW 2015 on my home PC so I can't open your code, but I'll hazard a guess:

• Is your "recursive" VI configured as Shared Clone Reentrant?
• This article might lead you to more clues: http://digital.ni.com/public.nsf/allkb/3FBC5856A4BAACB886256D270001A91F

 

3 hours ago, ARC5200 said:

I believe I understand the reason for this error, which is that technically we are recursively creating these EM’s and therefore can have essentially an infinite amount in memory to interact with.

I'm not convinced that the error message is talking about recursive object creation, because it clearly flags Abort_EM.vi is the problematic VI. It sounds more like LabVIEW doesn't want to let you call a VI that eventually calls itself again. Do my 2 points above help?

However, if it is indeed problematic to include an Abstract Equipment Module instance as a member of the child class, try storing the member as a Variant instead of an Abstract Equipment Module. (You will need to convert the Variant back to an Abstract Equipment Module before running its member VIs).

[Ryan Podsim]

I don't quite understand, Why do you need to store Equipment Module in a class that inherits from Equipment Module? Child classes can have access to the Parent's data through accessor functions and don't need to maintain a separate copy of the parent.

Also what is the difference between the Interface Equipment Module and the Abstract Equipment Module? As I understand it, neither an Interface nor Abstract class should provide code for the defined functions. I looks to me like that should be one class.

[ARC5200]

Ryan,

 

 

2 hours ago, Ryan Podsim said:

Also what is the difference between the Interface Equipment Module and the Abstract Equipment Module? As I understand it, neither an Interface nor Abstract class should provide code for the defined functions. I looks to me like that should be one class.

Interface and Abstract Equipment are different because of the nature of the class types in "most" object oriented languages. Interface is a class that basically contains empty methods and no data. Abstract classes can have data and can either leave empty methods or declare them. I say most because in Labview this is not the case because Interfaces does not exist. So you are correct in saying that it should be one class. The UML I provided was based on what I wanted to do based on what I would have done in other languages.

2 hours ago, Ryan Podsim said:

 

I don't quite understand, Why do you need to store Equipment Module in a class that inherits from Equipment Module? Child classes can have access to the Parent's data through accessor functions and don't need to maintain a separate copy of the parent.

 

The idea was not so much about data from the parent to the child but to have the ability to cast that Parent EM into it's own child EM that I can use later. Lets say I have a Valve EM and I have a request to have that Valve EM control a TC EM. Instead of having to drag another EM class VI onto my top Level VI's I would have the ability to dynamically create the object utilizing the internal EM. I hope that makes a little more sense.

 

JKSH,

 

I think I understand what you are getting at. Let me try a few of these things and then get back to this topic.

 

Thank you guys for your help thus far.

 

[Aristos Queue]

ARC5200: Here's another example similar to the linked list example written in LV 8.5.

What I did in that old example still works today, though there's some cleanup I could do on the code in a more modern editor... still, it should give you code you can load and look at for inspiration.