LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
PatrickLye

Programmable Conditional Case Selector Terminal

Status: Declined

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

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.

 

Glad to answer questions. Thanks for any KUDOS or marked solutions 😉
26 Comments
AristosQueue (NI)
NI Employee (retired)

Picture, please. I think I understand your request, and based on that understanding I think it is an obviously bad idea, but very rarely are ideas posted to the Exchange obviously bad, which makes me think I've more probably misunderstood your request. A picture would help immensely.

altenbach
Knight of NI

 

It seems you want more than one selector terminal, this has already been suggested. (...and a few other duplicates, e.g. here, etc.)

 

So what would we gain except for more complicated configuration and an (evil) temporary express VI style panel?

 

 

Yes, please clarify the idea with more details! Thanks!

 

PatrickLye
Member

Logic attached Case Structure.PNG

Sorry for the delay, but I only work 4 days a week so I just got back today. I should have done this initially. A picture is worth a thousand words.

Glad to answer questions. Thanks for any KUDOS or marked solutions 😉
Intaris
Proven Zealot

So make a subvi. Smiley Frustrated

PatrickLye
Member

@intaris

 

Yep, as I mentioned in the initial description that is what we do now, but this helps to get another SubVI off of the diagram to help clean things up.

Glad to answer questions. Thanks for any KUDOS or marked solutions 😉
AristosQueue (NI)
NI Employee (retired)

As I said, very rarely are ideas obviously bad, so I was pretty sure I was getting the wrong idea from your post. 🙂 And indeed I was wrong.

 

So, now my questions:

 

 

a) Why would you avoid Express VIs? There are specific Express VIs that I wouldn't touch, but the concept in general is very sound and there are some that are exactly the right solution.

b) Is how is this any different from selecting that code and selecting "Edit >> Create SubVI"? Why would adding additional visual syntax (generally a downside) be superior to the existing syntax?

 

I actually dislike the Comparision Express VI, but if it were actually well done with real data types, and a growable syntax, why wouldn't something like this be the far better option than playing with the visual appearance of the Case Structure?

Untitled.png

 

 

AristosQueue (NI)
NI Employee (retired)

> but this helps to get another SubVI off of the diagram to help clean things up.

 

I contend this is an anti-goal. In my observation, hiding more code in arcane ways just makes diagrams harder to debug without meaningfully cleaning anything.

GregSands
Active Participant

>> > but this helps to get another SubVI off of the diagram to help clean things up.

>>

>> I contend this is an anti-goal. In my observation, hiding more code in arcane ways just

>> makes diagrams harder to debug without meaningfully cleaning anything.

 

I wonder if it is actually more meaningful. It explicitly binds the code to the case structure that it applies to, and doesn't require an additional SubVI on disk. It's probably closer to the Pseudo-VI idea but with the explicit connection to the case structure - it certainly shares many of the same reasons.

PatrickLye
Member

@AristosQueue

 

I avoid express Vis because I have seen too many bad comments on them like above from Altenbach, and I also like to have tighter control over my code when possible.

 

"I contend this is an anti-goal. In my observation, "

 

I find that cleaning up the Block Diagram and organizing code is what helps me to be more productive while initially coding, and even more so when I revisit a program to add in that new feature that management wants months later.

 

"hiding more code in arcane ways just makes diagrams harder to debug without meaningfully cleaning anything."

 

I don't think this would be arcane if done properly. Instead you would have an icon on the Case Structure telling you the function is enabled. Clicking the input icon would open the attached SubVI. Rolling over the icon would show the diagram description in the help window over your Block Diagram. Instead this is intune with R.A.D. (Rapid Application Development) with a clean interface in which I can't see anything arcane at all, and even better it leaves a way open to organize the SubVI into your given folder structure with a meaninfgul name.

 

Then, for those who simply don't like this they can continue coding in the old way without any problem.

 

It is true this method only cleans one VI off of the Block Diagram in some cases, but there are times when I leave some logic on the Block Diagram instead of taking additonal time creating and configuring yet another SubVI, which becomes a bit of a pain when done correctly. Obviously I never skip this when there is a lot of logic. With this method both one SubVI as well as additonal logic is easily tied into this new SubVI linked to the Case Structure leaving a cleaner Block Diagram.

 

@ GregS

 

Yes, this would actually require a SubVI on disk. See the image about when selecting the function it asks you to name and save the SubVI. The main difference is that this tightly binds it to the Case Structure without cluttering up the Block Diagram.

Glad to answer questions. Thanks for any KUDOS or marked solutions 😉
crossrulz
Knight of NI

When it comes to case structures, the logic is way too important to hide.  I do not want to dig into another diagram to see what the case structure really means.  At least with a subVI, I can make a decent icon that shows what the logic is meant to do.  This idea would just cause me to have to open up that subdiagram constantly.

 

No kudos from me.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5