From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Hardware Abstraction Layer using Object Oriented Programming: Adapting to different output type interface
Solved!
@champion2019 wrote:
When I am going to use hardware abstraction layer to construct a device driver I have to consider different output type data of interface.
I'm not exactly sure what you are trying to reference here. Maybe an example would help get your point across.
Generally, I have an abstract class for a specific instrument type (ex: Power Supply). I then have a method for each thing I was the supply to do (ex: Set Voltage, Set Current, Read Voltage Measurement, Read Current Measurement, Set Output State). That interface should be the same no matter what model of power supply I use. You then make child classes to handle the exact instrument you are trying to control.
@champion2019 wrote:
Mostly is about an different input type data. Are they the same? Build a class to have different type as the input? I am confused. If there is any example that will be so grateful. Or any other figures to show that.
Different input type data is not the same 😋.
I guess what you mean is how to make one interface that allows different types as input.
There are a few solutions...
1) Don't try to put different input types in one interface.
Pick your battles. What is really the point of putting all devices in one hierarchy? There is a point, but is that what you're after? At this point in time? Why not start with putting the same devices (with the same inputs) in a hierarchy?
2) Make the interface so it is the same data type.
Guess you mentioned this yourself. Make the input a class, and make a class hierarchy for the different data types. Note you'll eventually get yourself into the exact same problem. At some point you need to put different data in those input objects... This could of course come from a config class of some sort (home made, or even a file reference). But then again, you can feed that class to the HW VIs directly...
3) Wait for LV2020.
So you'll have G interfaces to work with. This means you can add functionality to classes that are not in the same hierarchy. The lack of interfaces has been holding back HAL development a bit... See this site.
Search LabVIEW like a graph!
@champion2019 wrote:
Mostly is about an different input type data. Are they the same? Build a class to have different type as the input? I am confused. If there is any example that will be so grateful. Or any other figures to show that.
Different input type data is not the same 😋.
I guess what you mean is how to make one interface that allows different types as input.
There are a few solutions...
1) Don't try to put different input types in one interface.
Pick your battles. What is really the point of putting all devices in one hierarchy? There is a point, but is that what you're after? At this point in time? Why not start with putting the same devices (with the same inputs) in a hierarchy?
2) Make the interface so it is the same data type.
Guess you mentioned this yourself. Make the input a class, and make a class hierarchy for the different data types. Note you'll eventually get yourself into the exact same problem. At some point you need to put different data in those input objects... This could of course come from a config class of some sort (home made, or even a file reference). But then again, you can feed that class to the HW VIs directly...
3) Wait for LV2020.
So you'll have G interfaces to work with. This means you can add functionality to classes that are not in the same hierarchy. The lack of interfaces has been holding back HAL development a bit... See this site for (AQ's) presentation about interfaces.
The forum is having some problems (there's an update going on)... I didn't post twice, but an edit made it appear twice.
What is the "Temp" class measuring? Why is the measurement trying to output a Boolean. That seems more like you are doing the comparison inside of your HAL when it belongs outside.
Measure can have a Boolean output for one child, and a double output for another. That's perfectly OK, as long as there's no parent method. The childs must have the same connector pane as the parent, but if the parent method isn't implemented, the childs can do what they want. You wouldn't be able to use the method polymorphically though... Not sure if that's what you're after.
The name Measure is a bit weird. Is it actually measuring?
Let's call it Visualize ("Get Results"?). Than it would need something to visualize to. A class, a child of Visualizer. In the case of Boolean data, it needs a Boolean Visualizer. For the Double, it needs a Double Visualizer. The Visualize method doesn't have a specific type input anymore, but a general one.
This would work. But do note that you are making sacrifices here. You won't get edit time compilation errors anymore, only run time errors. For instance, if you try to visualize a Boolean with a Double Visualizer.
In the Visualize method, you'd need to either :
1) cast the Visualizer to the specific Visualizer (for instance Boolean Visualizer). Than use Set Data, or whatever method of Boolean Visualizer that has a Boolean input. The cast would fail for the wrong Visualizer. Not that nice, as the type checking seems to be more of a task for the Visualizer. Or
2) Use a Variant as input. Visualize (Set Data) could check the variant's type. It will come at a cost, variants do have a bit of overhead. Or
3) Make a Set Boolean, Set Double, etc. method in the Visualizer. Implement the method for the appropriate child, and make the parent method return an error. Optionally, convert the input type to the child's type. For instance Double Visualizer could convert a Boolean to 0-1 so it fits. A Boolean Visualizer could convert a double to true if !=0...
4) Make Visualize return a Data class. Data could be any child of Data, for instance Boolean Data, Double Data, etc. At some point you'll want to actually use the data, and you can't avoid casting classes, or variants, or perhaps even strings (if you want to write all to file).
I'm sure there are other options.
