LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

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
Active Participant

@PatrickLye:

 

 

What is the advantage of creating a SubVI over not creating one?  Needing a meaningful name/icon/folder seems a disadvantage - for example in your picture above, what would you name it?  "ClusterComparison.vi"? "DoubleClusterEqualityCheck.vi"?  It's hard to think of a meaningful name that is any more descriptive than seeing the code itself.  Therefore I agree with your original suggestion that the code is shown on a mouse rollover, not your later suggestion of documentation. 

 

For me, it's a code fragment which belongs to this case structure.  If I copy and paste the case structure, I'd want that code to be copied along with it (not linked to a particular subVI) so that I could simply modify the code slightly for the new situation if needed.  And if I did want a commonly used case+logic combination, then it could be saved as a MergeVI (or some draggable equivalent) in my reuse folder.

 

So I can see more advantages to not creating a SubVI. (Yes I know LabVIEW currently has issues with block diagrams that do not have associated front panels, but I live in hope of a more fruitful separation of the two!).

Member

@GregS

 

I moved away from showing the diagram on rollover as it seemed it might be quite a challenge to do this, and Altenbach mentioned that this could lead to an Express VI situation, but it would be very nice to see the code.

 

Perhaps what is needed here is the ability to have the code as a part of the case structure or a separate SubVI attached to the Case Structure. This way people could chose what they would like for a given case.

 

Now, as far as having a SubVI with a name, this fits in line with my programming/organizational style. It's possible that my OCD is a bit more than some in this case. I use distinct folder structure to help me to find what I need without spending a bunch of time looking around for things.It's also possible that LabVIEW offers a better organizing methodology, but I haven't run into it yet. Until something better comes along I make certain that I make a place for everything and put everything in the right place.

 

 

 

organizational structure.PNG

 

As you can see from the structure I use folders heavily and names that mean something to me. The RS485 Current address loop.vi is only for testing, the Mbus Addr1 Loop.vi handles all communications to that Modbus address. The LAN test loop does automated ping tests on the network from address arrays that I pass in.

 

Using this type of structure I find it easy to find anything in the project with a few mouse clicks.

 

At my company I work on projects for a bit of time, abandon them for the new hot priority, and I go back to them when they again bubble up to the hot priority. I've found that moving around like I do it is critical to have things organized, documented, and incredibly clean on my Block Diagrams. The Loops folder contains only the Loops that are resident on the Main VI. Depending on the initialization settings the program uses only the Loops that it needs for any given configuration.

 

The attached SubVI that I mentioned would fit into my current work methodology, but as always if there is something better out there I'm open to it, if I can convince the Bean Counters it is something that I need.

 

Then the embedded code version would also be nice to have for some smaller items that aren't an organizational headache.

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

Why, if you already need to create a VI would you then hide it?  The code is important and if you want something smaller, make the Icon smaller..... I really do not see an advantage of binding a VI artificially to a case structure......

 

I don't think this idea actually solves any problems.  In fact, I think it might create a few.

Proven Zealot

> Clicking the input icon would open the attached SubVI

 

Conveniently, clicking on a VI wired to the case structure would also open the subVI.

 

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

 

Not true. This belief has been the bane of many programming languages because it isn't true. One person writes the code but many people have to read it. C++ is very guilty of this... so many euphamisms in the code that it can quickly become impenetrable to anyone not familiar with every little nuance of syntax. I don't accept this as an answer for LabVIEW. If we augment syntax, especially for the second-most-common-node in all of LabVIEW (first being the While Loop), it has to be in a way that is both intuitive and actually improves comprehension.

 

> leaving a cleaner Block Diagram.

 

Or leaving a more ambiguous block diagram, depending upon point of view.

 

The idea stays open... if it gets enough kudos R&D will look into it, but it won't get my personal kudos as a LV user.

Knight of NI

GregS wrote:  And if I did want a commonly used case+logic combination, then it could be saved as a MergeVI (or some draggable equivalent) in my reuse folder.

 

Actually, that is an argument for the subVI.  "Hey I found a bug in this logic.  Now I have to go fix it EVERYWHERE."  Where with a subVI, you just fix it once.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Knight of NI

While getting ready for work, I realized that this idea would make debugging a major pain in the #!$#$!.  At least with a subVI, I can just run that subVI and test it on its own.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Proven Zealot

Crossrulz: and where are you most likely to need to rerun a VI multiple times with various values? Complex if logic. I think you've hit a pretty good point there.

 

Of course, the idea is to still have the subVI, just not have it as a subVI, so maybe it would be independently runnable?

Member

You might like this idea of being able to fold code into a reusable user defined structure. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Custom-Structures/idi-p/1506526

Proven Zealot

So if it opens like a sub-vi, runs like a sub-vi can be debugged like a sub-vi then why shouldn't it look like a sub-VI and be placed like a sub-VI?  I guess I'm missing something really philosophical here......

Knight of NI

Intaris, the idea from the OP is to hide the subVI in the selector terminal.  I still come back to why would we want to hide that important logic?  If a single subVI is hurting the looks of your diagram, I think you have more important issues to deal with.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines