When to group and when not to from a groupaholic?

[jyang72211]

Hi all,

I am a "groupaholic".  What I meant is that I like to group a lot of functions in a single subvi.  Sometimes, I think it is a great idea, and sometimes, it isn't so bright.  I have a question.

I am thinking about creating a subvi that would allow me to choose what command I want to issue to MOBUS.  I have about 40 commands.  I have the approaches below.  Please give me some suggestions.

1. a subvi with a enum input for command, and a generic array input for cmd parameters.

    - pro: I can group all commands under this subvi.

    - con: the cmd parameters array will not be descriptive at all.  The user needs to know exactly what to input for each cmd.

2. grouping cmd with the same type of paramters under a sub, so one subvi will exist for each type of cmd.  The subvi will have a enum input for command, and a enum input for parameter

    - pro: descriptive command parameters.

    - con: hard to describe each subvi

3. create one subvi for each cmd and group them under one polymorphic vi with enum cmd parameter input.

    - pro: very descriptive.

    - con: a lot of files to manage

Please give me some suggestion.

Yik

[Mark_Yedinak]

From a code readability perspective think about what would make your code most readable. With this in mind I prefer to have separate VIs for each command. By doing so your VI documentation can be specific for the given command and its parameters. The VI name and icon (if using good names and icons) will help to make the code easy to read and the person working on it will have a very clear idea of what is happening. At a lower level you can create what are effectively private methods (think object oriented) that can generalize pieces of functionality and provide reuse within your code. Looking at your code as a reusable library or API you want your methods/functions to have good descriptive names and not require the user to understand and decode the parameter list to fully understand what is happening.

[smercurio_fc]

The question you ask isn't that much different than writing a regular instrument driver. You could (taking a power supply as an example):

• write one monolithic VI where you select what command to execute along with your generic parameter for that command
• write a VI to set related groups of parameters (like voltage, overvoltage setting, current, and current limit)
• write a separate VI for each command (one VI for setting the voltage, one for setting the OV point, one for the current, etc).

I think the monolithic VI in this case is a bad idea. If you want to add functionality you have to add to your enum and make an already large VI big. Also, what happens if the VI gets corrupted?

The instrument drivers that you get in NI's IDNET tend to be the second option.

I always take the third approach unless you HAVE to set another parameter when you want to set some parameter. Why? Well, because I don't want to have to remember what I set the OV point to if I just want to change the voltage. I believe that instrument drivers should work similarly to the way you use instruments. Last time I checked when someone is twiddling the voltage knob they're not simultaneously setting the OV point, the current, the current limit, etc., etc.

That said, there are cases where the monolithic approach is the best. For example, in the test executive I have I call a top-level "test" VI. I pass in the name of the test to run (as a string), and the parameters for the test (as a string). This test VI calls the appropriate test and passes in the parameters (still as the same string). The test itself parses the parameters as it needs to. In this case the monolithic approach is best since the exec shell always sees the same signature for test modules. 

[shew82]

I would say that in almost all circumstances many single purpose VIs are much *EASIER* to manage than a single monolithic VI (whether is be drivers, APIs, whatever). Not only can you have proper inputs (ie descriptive and appropriately flagged as "Required" / "Recommended" / "Optional") but as it was already said, the individual VIs can have descriptive VI descriptions and icons.

In addition, in 6 months when you need to make a change to one of the commands to extend the functionality of one of the commands, you change one single VI - the rest of the driver hasn't been touched and should therefore carry on working exactly as before (something that cannot be said for a monolithic VI). In addition if Source Code Control is used, you will be able to see through the change logs which functions are changed with time, etc.

My final point is really aimed at people with more than one LabVIEW developer working on a project - when you have separate VIs per function, etc the chances of somebody mistakenly making a change where the shouldn't is dramatically reduced. 

[rolfk]

For the problem of related but not necessarily depending operation of parameters in one single VI I like to use a default option for the parameters that says "don't change" so unless you wire that input, it simply does nothing for that parameter.

[smercurio_fc]

---

rolfk wrote:
For the problem of related but not necessarily depending operation of parameters in one single VI I like to use a default option for the parameters that says "don't change" so unless you wire that input, it simply does nothing for that parameter.

---

Good point. I also do that, and should have mentioned it. Now, how come the NI instrument driver guidelines don't say that?

NOTE: It was not my intention to turn this thread into an instrument driver bashing thread. I'm just using them as an example of an instance of when to create one large monolithic VI, several subVIs with grouped controls, or separate subVIs for each action.