Invert Option on all Boolean Inputs/Outputs

[DailyDose]

Why hasn't this happened yet!  I know this forum/idea already exists, which is why I'm confused it hasn't been implemented yet.  It would appear the LabVIEW world wants this.  Maybe it just needs to be brought up again and Kudo a ton.  KUDOS!

Invert Boolean Inputs/Outputs

Just click the link, I don't feel like reinventing the wheel when it comes to pictures and diagrams.  However, I believe everyone agrees...definitely ignore the part about Inverting Controls/Indicators and Numeric Values.

[crossrulz]

To bring attention to an idea, just post a comment in that idea.  No need to create another idea and flat out say that it is a duplicate.  You are just making more work for the Idea Exchange moderators.

[Darren]

 Duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Invert-Option-in-all-Boolean-Terminals/idi-p/1281058

[DailyDose]

Also, the ability to invert the conditional terminal for For Loops.  That'd be pretty cool as well!

[AristosQueue (NI)]

DailyDose wrote:

> Also, the ability to invert the conditional terminal for For Loops.  That'd be pretty cool as well!

Assuming you mean the conditional stop terminal, that already exists. Left click on the conditional. Works the same as the While Loop.

[DailyDose]

AristosQueue wrote:

>Assuming you mean the conditional stop terminal, that already exists. Left click on the conditional. Works the same as the While Loop.

My apologies.  That is not at all what I meant.  I was referring to the conditional indexing in the for loop.  Not the conditional stop terminal.  Sorry.

[AristosQueue (NI)]

Ah. In that case...

We explicitly rejected adding an option for inversion to the conditional indexing. That option created significantly more clutter in an already dense popup menu, so we would need a strong reason to push for it. Since we do not have universal inversion dots on Booleans terminals -- and there are strong hesitations against ever doing that idea -- it didn't seem good to add it just for those terminals.

Because you'll probably ask: the strong hesitation against a universal inversion option for Boolean terminals is when we ask users to read diagrams that include those inversion dots, there are many people who just don't see those dots, and many who don't know the meaning of them when they do see them. There are probably ways to address these issues, but it is well beyond just making the existing dots universal.

For me personally -- not speaking for the rest of R&D -- the dots are a bad idea. We have the Not primitive. It is an independent element of the diagram where the Context Help tells you what the node does. You can insert it and remove it easily enough. It doesn't get overlooked. If you need two nodes to stay in sync with each other, it is better to use a single Not primitive and fork the output wire than to invert both of the destination terminals. For a whole host of reasons, I really don't like those dots and would oppose them becomming universal. But that's just me -- the line between a feature that "helps me write code faster and makes a more compact diagram" and a feature that "makes it harder for me to read someone else's work" is hazy and gray, but for me, this steps over that line. Others would rather see the dots improved so they can be used ubiquitously. But if there is any answer to "why isn't this already done?" that answer would be "because there is way more involved than just a simple config option for the existing dots."

[DailyDose]

I hope you didn't confuse my haste.  I know there's more to it than simply putting an option that says, "Invert?"  What goes on behind the scenes in the boolean operators would become more (lack of a better word) bloated.  And I understand the issue with that.  However, the compound arithmetic has the ability to invert options and I and my colleagues find ourselves using that tool for the single purpose of the inverter.  The gray line to which you speak of of people being able to read your code easily is not a gray line in my mind in this scenario.  LabVIEW follows the Dataflow Paradigm, this we all know.  Those of us who went through our boolean/digital EE classes, I think we can all agree that boolean basically follows the exact same "paradigm" of left to right and "does not happen" till all variables are "present."  This being the case, we(meaning the majority of all LabVIEW programmers...I'd like to think) who were educated were taught how to read boolean in the format of inverters at inputs/outputs.  That is what I, and I assume others, am looking for.  So this is a case situation, to me, that because schools are teaching the inverters at inputs and outputs that LabVIEW would be best served to follow step.  Much like Macs becoming more popular in the work place.  Students use it in school and don't know how to use windows in the workplace.  Know what I mean?  Future LabVIEW programmers (many EEs) are coming into the workplace with practice of reading boolean with inverters at inputs/outputs.

[AristosQueue (NI)]

> Those of us who went through our boolean/digital EE classes, I

> think we can all agree that boolean basically follows the exact

> same "paradigm" of left to right and "does not happen" till all

>variables are "present."

The mechanical engineers, computer scientists, physicists and art majors who also use LabVIEW don't have a clue what that small dot means. The hesitations have nothing to do with it following dataflow or not. It is entirely a usability issue -- the complexity of the visual noise of the popup menus, the ambiguity of that dot, the small size that makes it easy to miss.

EEs are but a portion of the LV user base. Students have been learning that dot for 50+ years, but knowledge of what it means is still thin on the ground among LV users generally. I don't expect any sudden surge of awareness in the near future. 😉