LabVIEW
Creating a TCP connection / refnum in a subvi
Solved!
LabVIEW is a full blown programming environment which allows you to do pretty much any programming pattern that you would like. As such there are of course umpteen ways to solve a particular problem. I would not call that opiniated however, multifaceted maybe.
What you try to do could be solved with a LabVIEW Intelligent Global, a LabVIEW 2 style global on steroids. It works fairly well and was something that I did use a lot 25 years ago as a very powerful tool. However it has many limitations and maintenance gets very costly as you start to add new functionality to you "Intelligent Global".
What you show is the beginning of a queued message handler but really just that. It is not prepared to handle multiple actions, but instead multiple devices (HVPS) for now.
Instead you want to create one message consumer loop per device and provide an action to the message such as open, enable, disable, set SP, read CP, close. You send the open message somewhere after your application has initialized with the network device address as parameter, then send the according message with the correct parameters, and eventually the close message before quitting your application. Then you can store the network refnum created in the open handler into a local shift register in your message consumer loop.
Once you got that somehow working you put the entire message consumer loop into a subVI and just put that on your main diagram. If you want to go advanced you can also instantiate that subVI dynamically and in that way create multiple clones of your device. Once you head in this direction you will most likely want to look into according well designed queued messages handler frameworks such as DQMH, or if you want to really go nuclear all the way into the Actor Framework.
I meant that your "Target" element specifies the device to operate on, the Event specifies the "Command type" and the parameters is then IMPLICITLY implied by passing the actual control terminal to the subVI. This is very suboptimal.
Typically you do ABSOLUTELY NOT want to couple the UI (your control labels) that tightly to your execution logic. In programming the UI should be a separate from the logic as possible (which the JKI state machine for instance gives you some levers to do). With the JKI state machine you should never directly execute anything but basic UI operations such as enabling or disabling other controls etc, in the actual event structure cases but always add an explicit event to the internal event queue to execute the actual logic in. And if you happen to do any device interaction that can potentially take some time and needs to wait on something in the device, that even includes things like saving large amounts of data to disk, this should usually placed in its separate event consumer loop and controlled through messages send through an explicit message queue.
You might want to include your Target in the message if you absolutely insist, but in my opinion that is making things just more complicated. It's more clear to use separate message queues for each device with each their own message consumer loop. In your case you only have one device anyhow so far. If you eventually add another you can easily add another message queue for that too and accordingly an message consumer loop. Normally each message queue needs its own message consumer loop to keep things easy to manage. And if you ever start to have more than two or three devices you should likely look into a more dynamic message handler framework such as DQMH.
Basically your message could drop the Target, and instead contain a Command that specifies the actual control you operate on. And I would NOT pass the control label text as command but an explicit Enum. Then you can add a Parameter in form of a variant. Because even your Enable event has actually a parameter, namely the boolean state of the Enable button. Or do you not want to be able to disable the device when you click that button again?
Rolf, thank you for your response.
I can understand how coupling the control labels to the business logic is suboptimal and will need to investigate variants to figure out how to pass the relevant data directly through the message.
I have a total of ~5-7 unique devices that need to be controlled by this GUI, so it seems like investigating the DQMH framework is probably worthwhile at this point. Alternatively, I was playing around with creating unique queues and message handling loops for each device and ended up with messaging handling loops with their own event cases inside - is this a design pattern that you have used or see an issue with? My reasoning is that each subvi can be a standalone program that handles all of the events relating to the device's operation, and then the message queues can be used to pass information between devices and the main GUI.
Also, slightly off topic, but when I was attempting to bundle the queues by name, I had a hard time creating the input cluster with the references to Device1 and Device2. To create them I had to create a control for the queues, then move the references into the cluster, then delete the controls from the front panel. Is there a simpler way to create the input cluster for the bundle by name function?
Cheers,
Ian
