LabVIEW
Oop with LabVIEW
Solved!
It's an option. But since the devices have specialized methods, you get very little from polymorphism. Also, each message you send is probably going to relate to exactly one low level method. So, you're basically doing the work twice, in a (very) complicated way. Maintenance will become tedious.
The only thing you gain is the parallel execution of the devices. Something that is often overrated, but of course not always. I've seen this pattern, with feedback from the consumer to actually make the producer wait for the consumer. That is a lot easier to make with just one loop... Do you really need a parallel loop?
If so, I'd make a DAQ loop with the two devices in two shift registers. If you put them in a container (array, map), you immediately have to start casting to specific, which sounds like no fun at all.
I'd send (much) higher level commands from the GUI loop. Not: method 1 for device 1, message 4 for device 2, but "start measurement", "stop measurement". That way, both loops stays generic, focusing on their stuff, the DAQ loop on devices, the GUI on the GUI.
This looks a lot like the HAL trap. HAL's are hard, you should only start doing HALs when you're experienced enough to know better 😋.
Of course, I know very little about your project.
Search LabVIEW like a graph!
@labviewette wrote:What I have not figured out yet is what the best way is to tell my lower loop which class it should be using..The snippet i attached earlier was my initial idea on how this could be done. If anyone has a better idea please feel free to inform me.
Either let the GUI loop send it with a "set device" event\queue, and then keep the class there (the GUI loop doesn't need it) or send an enum (or index or ID string) and let the DAQ loop do anything.
Nothing wrong with sending a class as a variant parameter, but I thought you planned on sending the device class with every command. That will become problematic, because the object can't change it's private data, unless it's send back to the GUI loop. As the GUI loop keeps running, you'll get a big mess (race condition on steroids).
@labviewette wrote:It is possible that using classes here might be overkill. The reason i am using classes is that I want to start encapsulating my code better than in the past.
The most basic class is just a library that keeps it's private stuff private.
As you have 2 devices sharing methods (private and public) and probably settings as well, a parent with 2 childs won't be overkill. It will be a very decent solution.
@labviewette wrote:
Besides that I think that in this case it is helpful to use dynamic dispatching when carrying out commands both devices understand (open, close, set value, measure).
DD (Polymorphism) might not shine here. The two devices extend the parent with methods. To call these extensions, you need to either cast to the specific child or give the parent all methods that don't get implemented in one of the children. That's just the situation you're in, not a great use case for polymorphism.
But this is all talk about how to prevent a mess. Without oo, you'll get a mess for sure 😉 (cases here, there and everywhere).
A way out could be to make a generic device driver class with low level methods. Then make a higher level parent with all the higher level commands (like start measurement). Two children then implement these high level methods, using the generic driver. Of course you can make a generic driver hierarchy and a high level command hierarchy. That might be overkill, or it could make perfect sense, depending on a lot of details. I'm not completely sold on this idea, but fact is you have 2 devices that only share a part of the functionality.
I'd simplify it by having the class in a shift register in the consumer loop instead of sending it as a parameter (together with other needed data as a cluster). That way the consumer can easily change values as needed and the UI loop only sends commands.
All architectures have their ups and downs. 🙂
If you mean you have 2 child classes you don't have to think about it as classes handle that themselves (which implementation to use).
If you mean you have 2 instances of some or several classes active at once, then you need to address them anyway, so why not with a simple integer (or enum if you want easier to read code) to say which one? The natural continuation is of course to have all instances as an array of the base class.
