LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LVOOP and Hardware

Solved!
Go to solution

I have a question about LVOOP and multiple hardware sensors of the same type.  I'm getting ready to dive into the world of LVOOP and was curious how to address something that seems like a fairly simple issue. I have a system that has multiple sensors, all of which are the same type and range.  After reading some about the HAL architecture I figured I'd start there as it seems to incorporate LVOOP as well as labview patterns that I'm more familiar with.  I'm using a crio and usually I would bundle all of these sensors into a cluster(s) and move them around and unbundle as needed.  That would give me a distinct identifier for each sensor.  I think I'm losing this simple concept when moving into LVOOP.  

 

Should I make children classes of pressure_sensor_type_1 for each identical pressure sensor or should I just simply branch the wire as in wire_branch.png?  I know that I could just branch the wire and that would give me a new object, but I'm not sure how to reference these in other parts of my program, ie how do I distinguish pressure_sensor_type_1_#1 from #2 and #3.  If I do it this way, then it seems like I have a distinct way to keep track of each child class and it has a distinct name.

 

In LVOOP I seem to have the urge to break components down much further than I would before.  I’m not sure if this is correct or not.  One more issue is that I typically use a scan interface for crio development and NSVs to send data back to a host, does anyone have any suggestion for how to handle these variables within LVOOP as it seems to me that they break the encapsulation of OOP due to their network publishing. 

 

I have attached really basic samploe code.  Thanks for any feedback.  

 

 

Sensors.png

 

 

Download All
0 Kudos
Message 1 of 3
(2,490 Views)
Solution
Accepted by topic author Jed394

You need to use a hybrid of your two proposed methods. If all of your sensors are of the same type they will be the same child class type. There is no need to define yet another child class just to differentiate instances of the class. If you have three sensors then create three instances of pressure sensor type 1. Your initialization can include a name or identifier. You could also put your sensors into an array or a cluster. The cluster element or array position would identify the specific sensor. If you do this though define the array element or the cluster element as the base (parent class), not the child class. This would allow you to add different types of sensors in the future and would not require any code changes to your array/cluster.

 

For something like a sensor your base class would not include the implementation for most of your sensor methods. These would need to be overridden by the children. The base class could implement generic items such as a Get-Name method or something similar.

 

When defining your parent class avoid putting methods there that will not apply to all children. The parent should only contain methods that will be shared by all it descendents.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 2 of 3
(2,474 Views)

Thanks for the info.  LVOOP seems like a much more flexible way to organize programs, it's just taking a little while to switch my thinking over.  

 

PS. Is there an LVOOP forum?  Seems to me there NI should make one.  

0 Kudos
Message 3 of 3
(2,433 Views)