Programmable Conditional Case Selector Terminal

[PatrickLye]

We need to have a conditional case selector terminal that will handle comparison operations allowing the Block Diagram to be cleaner.

This would be similar to the For Loop structure conditional terminal in that you would turn it on via a right click.

Then to configure the logic simply click the conditional terminal to pop up a private block diagram owned by the case structure. Create and then wire in your inputs whether single items, arrays, or clusters. Edit it as you would any block diagram. This would allow complex data types or simple booleans.

By using the block diagram configuration inputs could be configured exactly as they are in a SubVI allowing easy labeling and multiple types of input in order to do complex logic that fires the case structure.

When this is selected the Conditional Terminal icon should change from a question mark to an icon indicating a conditional terminal.

When rolling the mouse over the conditional terminal the help window should show the logic currently used to fire the case structure.

This would be a large asset for all users to aid in cleaning up block diagrams. Granted a good coder can do all of this in a SubVI just prior to the case structure, but people would tend to tie code into the hidden block diagram immediately instead of building external code and then building up SubVIs along the way, or even worse building open boolean spagetti code all over the place.

[Intaris]

I know, and that's the issue I have with the idea (if it's a sub.VI it should look like a VI and be placed like a VI, not hidden or otherwise encapsulated in a selector terminal).

Obfuscation is not a good goal.

[AbandoningCausality]

IMO, it's because it's not just "a single subVI". It's a pattern you might use over and over. It quickly becomes code duplication that is currently handled by the merge VI option but editing the shell/merge VIs can't go back and fix prior instances.

[AbandoningCausality]

I wouldn't call it obfuscation, I'd call it abstraction.

[Intaris]

@AbandonindCausality

If it's a VI, it can be re-used at will (no merge VI options required on the selector logic VI).  If you don't want the overhead of a VI call, make it Inlined.

So I think what you are asking for really IS "a single sub-VI".  It just gets placed immediately before the Case structure (with its output wired to the selector case) and you have what you want.  You can incorporate the case plus VI in a Merge VI if you want (to be able to drop instances whenever you want) with the added bonus of being able to edit the VI controlling the selector logic and automatically update ALL instances of the logic.

In fact, simply creating a VI to do the job for you in conjunction with a standard case structure gives you BETTER results than what you are asking for IMO.

[AbandoningCausality]

I agree the logic to the left of the case selector can and probably should be made to the subVI. The part I'm nitpicking is the need for a merge VI that can retroactively update the instances of them. For example, if you wanted to do something like swap the true and false logic and go back and make all your true diagrams with your false diagrams. Or for another example, maybe you want to fire a fixed event after the case structure is done. You could update your merge VI, but your previous instances wouldn't be updated.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.