LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LOOP Casting Child Object as Parent - To More Generic Class

So imagine I have a parent class called "Sensor" with several children that each represents a different sensor manufacture. I want to create various children and configure specific properties on my Server PC, and stream sensor data over UDP to a Client PC.

 

The Client PC will request sensor objects over TCP from the server, but it does not need the child objects. Instead, it is better to cast the children as the parent Sensor object so that they can all be handled in the same manner. I have tried to do this using the "To More Generic Class" vi. It kind of works because it removes properties belonging to the child. However, the class name does not actually change. So all methods behave as though it is still cast as a child. Is there a way to change the class name?

Download All
0 Kudos
Message 1 of 5
(2,052 Views)

@TaraCCF wrote:

So imagine I have a parent class called "Sensor" with several children that each represents a different sensor manufacture. I want to create various children and configure specific properties on my Server PC, and stream sensor data over UDP to a Client PC.

 

The Client PC will request sensor objects over TCP from the server, but it does not need the child objects. Instead, it is better to cast the children as the parent Sensor object so that they can all be handled in the same manner. I have tried to do this using the "To More Generic Class" vi. It kind of works because it removes properties belonging to the child. However, the class name does not actually change. So all methods behave as though it is still cast as a child. Is there a way to change the class name?


So what's the point of having the child classes then?  How is client supposed to know what the sensor is and how to interact with it?  If you are just trying to tell the server what to do with the sensor, then make a separate interface where the client tells the server what it wants from the sensor.  Since you are already trying to remove the dynamic dispatch, then OOP is not required for this communication interface.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 5
(2,046 Views)

To More Specific Class and To More Generic Class only operate on the wire, not on the data. It just tells LabVIEW how to interpret what the wire is. If you want to extract only the parent data from a child class, you'll have to do create a new parent class and copy data manually. I'm a bit confused as to why you need to do this though... I also don't see why you have child classes if you're throwing it away later.

0 Kudos
Message 3 of 5
(2,036 Views)

Thank you. This is sort of what I expected I'd have to do. 

 

I'm not actually throwing away the child classes. We configure the child classes on the LabVIEW server and are able to use the specific child properties and methods to calibrate raw data and stream in over UDP to clients. Since the data coming from the LabVIEW server is already calibrated and configured properly, the client can just read the data and go using parent methods and properties. I should also mention that there are more than one clients, so this allows me to only have to configure the sensor once on the server. 

0 Kudos
Message 4 of 5
(2,021 Views)

So you still just call the methods from the parent class.  Why should you care if a child was passed? In fact, you likely still need the child's data in order to do want you need.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 5
(2,003 Views)