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

cancel
Showing results for 
Search instead for 
Did you mean: 

dynamic dispatch and building a command for different devices

Solved!
Go to solution

I have some code that is writing to a device. The device will be changed but the same basic commands will execute (set frequency, set power etc). So, I have written a dynamic dispatch VI that takes a prebuilt command string and writes to the device appropriately based on which communication mechanism is used (SNMP, VISA etc). My question is related to the prebuilt command string that is fed to this VI. I feel that the VI creating the command string should also be dynamic dispatch, and should build the appropriate command for that particular device. But, some devices could have many parameters required to build up this string (for example, snmp) and something like VISA may only have one parameter. Dynamic dispatch VIs must have the same connector panes, so what is the best way to handle this? I thought about having a "parameters" class on the connector pane which held all the particular parameters for a device. But, it seems overkill to make a class for something like this, when a variant would do just fine as the input. However, having a variant like that tends to make me think dynamic dispatch isn't necessarily the right choice in the first place because you are forcing a similar connector pane.

 

I am also considering if some of the inputs are actually representing the state of the object and could be held in the object itself. This would minimize connector pane inputs and may alleviate some of these problems all together.

 

Thoughts?

0 Kudos
Message 1 of 3
(2,149 Views)
Solution
Accepted by topic author GregFreeman

for(imstuck) wrote:

I am also considering if some of the inputs are actually representing the state of the object and could be held in the object itself. This would minimize connector pane inputs and may alleviate some of these problems all together.


That's what I would do. Make the parameters part of the object data, so when you later call the function to generate the command string the dynamic dispatch VI has all the right data available to it.

Message 2 of 3
(2,138 Views)

Yes, this is what i ended up realizing. These so-called "parameters" were actually representative of the object itself so I felt it was kosher to make them part of the objects private data.

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