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!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

General Comparison Operator (as an Express VI?)

I rarely use boolean operators to solve logical problems. Instead, as I would suppose the majority of users, I use them to respond to a set of conditions and perform actions in response to different cases.

The current set of operators:




is, to say the least, quite difficult to use. For instance, for the third operator, the help window provides the following explanation:



Now if you invert one of the inputs, good luck to figure out at first glance, when you revisit your diagram, what the outcome of the comparison will be.

In fact, what we need is some kind of matrix operator for which we type in the output of the comparison of A (input 1) and B (input 2) for the different cases:




Here I have supposed the inputs are "modified-booleans" with an "undefined" case, and the output of the comparison is an integer value, just to illustrate that operators for non-booleans could be treated the same way.

In the strict boolean operator case, there would be no "U: case and the output would be T or F. It would be a simple matter (I guess) to let the boolean operator icon show the outcome of the comparison in a way similar to something like that:



In general I find useful to have non-boolean outputs (as in the matrix above where integers were used) to be able to handle complex situations. Of course the icon would have to reflect the values selected by the user...

Which brings the issue of the configuration of this operator. Considering that the interface for this operator would be quite sophisticated, it would make sense to provide it as one of the Express VIs (such as the "Formula" or "Comparison" functions).


Active Participant

I do not know about others, but I don't understand what you are proposing.

Trusted Enthusiast
Trusted Enthusiast

A reconfigurable boolean operator.

One with which one can think in the following way:


if x = TRUE and y = TRUE, I want answer 1;

if x = TRUE and y = FALSE, I want answer 2;

if x = FALSE and y = TRUE, I want answer 3;

if x = FALSE and y = FALSE, I want answer 4;


where answer n (n = 1, 2, 3, 4) can be TRUE or FALSE (that would be a classic boolean operator), but more interestingly could be an integer value such than when connected to case structure, I can deal with the different cases without having to nest case structures within case structure.


Right now, one has to check out the logic table for each boolean operator to figure out which one to use. I usually don't bother (because I know I won't remember the logic table of the other exotic operators next time I take a look at the code) and try to use the standard AND or OR instead. Oftentimes that means I need to invert my inputs and compute two or more different boolean operations to feed their results into one of the nested case structures.


I envision this has having a reconfigurable "matrix-like" interface as depicted above.

Active Participant

You could try something like this


With two booleans you have 4 cases, 0-3

Tim Elsey
LabVIEW 2010, 2012
Certified LabVIEW Architect
Active Participant

Kind of like a Karnaugh Map or truth table.  Not a bad idea for people who are used to the concept from college, but I'm not sure how many would use it.  Are K-maps used in industry much?

Trusted Enthusiast
Trusted Enthusiast

elset191, that is a possible implementation but it is not easily legible (at least for me). Without your comments within each case (X = False, Y = False), which you would have to paste each time you use this implementation, there is no simple way to remember what case 1, etc corresponds to. A self-explanatory icon would let you jump to the case of interest easily (not mentioning that you would save a lot of wiring and typing).

Guys, what I am just saying is that except for logicians out there, the set of boolean operators seems useless FOR PRACTICAL PURPOSES and might be replaced by this new function... Again, we've lived decades without it, we probably can survive another one without it.

But since it is an idea exchange forum, and supposedly looked at by NI for ideas to improve the usability of LV in the future...

Active Participant

I'm with elset191 on this one. What he's created is a bit register, which is used a hell of a lot in hardware (though those are generally 8 bits). I've seen them used mostly for communication: things such as Service Requests and Status Registers. Back in my FPGA programming days, I used them for the core logic, too. Anyway...


It's true, if you're not used to dealing with bit registers, then looking at them takes a bit of work. I think a temporary solution for what you want is similar to this:

Bit Register.png


It's the bit register that elset191 suggested, but modified so that the case structure has text instead of numerics - easier to read with a quick glance.


Personally, I use the boolean operators to solve logic problems. They do take up a bit of space on the BD, but then I just turn that into a subVI and am happy again. :-)

Trusted Enthusiast

dthor: A strategically placed Coerce to Type will remove the need for introducing a Front Panel Control and a FSS. Smiley Wink



Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Trusted Enthusiast
Trusted Enthusiast

All right, now that we've agreed on the functionality (I'd like it a bit more general so that it applies to more than just booleans though) so let's make it a native function! :-)

Proven Zealot

I REALLY like this idea!!!!!


This is the sort of truly innovative idea that I wish we saw more of on the LV Idea Exchange. This is the sort of ease of use leap -- harnessing the "graphical" part of the LV language -- that keeps LV ahead of the text programming paradigm. Thanks for this idea.


Of course, it isn't getting many kudos. Don't worry -- high kudos can push a feature forward in the pack, but low kudos doesn't necessarily kill it. And this definitely caught my attention.


Minor point: The node has to be growable. A two-input solution is actually pretty tractable with the existing prims. It's the 3-input and higher solution where this beauty would really shine.

Trusted Enthusiast
Trusted Enthusiast

Unfortunately, I can't give kudo to this idea...:-)

I thought only very briefly about a more-than-2-input version of this function and since the matrix-like interface extension to more than 2 dimensions is cumbersome, I gave up on it.

However, my initial motivation when thinking about this function was, as I mentioned before, to handle multiple input parameters and move on to different cases depending of the different sets of inputs. I suppose that in this case, an interface in which the user would define the finite number of interesting cases (intervals or discrete values?) and the corresponding result might be sufficient.

In other words, if the input parameters (whichever types they are) are P1, P2, ... Pn, the user would have to list the cases he/she is interested in as:


case 1: P1_min < P1 <= P1_max, length(P2) = 3, ..., Pn >  0 Result 1: "Case 1"

case 2: P1: no constraint, P2 ="Hello World", ..., Pn: no constraint Result 2: "Case 2"


case m: P1< 0, P2: no constraint, ...,  Pn: no constraint Result m: "Case m"

All Other Cases: Default Result


I am not sure that would be general enough (or too general?) but that would probably be useful enough. Again, that would be more of a reconfigurable Express VI type of interface than a function at this stage, but maybe both could be provided (a simple binary operator and an extended version of it)? Whether we would be better off writing our own VI for that is definitely an open question!

My 2 cts.