ARC5200

Ryan, 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. 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.

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