Change Equal Function to Configurable

[kosist90]

The idea is to change Equal? function in a way, that it will be configurable, and will have one input as function "Equal To 0?". Sometimes you need to evaluate number of loops execution in While Loop (or not just it), and when you put standard Equal? function, some of wires will be not aligned in a straight line (either which is connected to Index output, or which is connected to Loop Condition), and you need to move up/down one of terminals.

So, you can see it from the attached picture.

[LukeASomers]

ToeCutter, that's a nice idea, but it's very different.

[iZACHdx]

Everyone is writing negative criticisms of this idea rather than trying to take the spirit of the idea and offer something positive and that is something that really bothers me. If we think about the baseline requirement and take into consideration some of the potential issues that were brought up, I think that we could arrive at something useful. How about turning this into a "Comparison Node" that would allow complex comparisons similar to the Expression Node?

[X.]

Like this: Expression nodes that allow comparisons?

[AristosQueue (NI)]

Before anything else: I happen to know several members of LV R&D who love this idea -- in different variations, with all sorts of proposals for how to make it work. Anything negative I say about it below should not be taken as a rejection by R&D.

> With all my respect, but you didn't get point fully. Comparison VI is even bigger than standard Equal? function. Block diagram will be more uglier.

Ok... you want an Express VI with a different, smaller icon. That doesn't change the fundamental request in my opinion.

> Everyone is writing negative criticisms of this idea rather than trying to take the spirit of the idea

> and offer something positive and that is something that really bothers me.

If we were discussing the particular embodiment of a good spirit, I would agree with you. But I think it is the spirit of the idea that is fundamentally flawed, and I think several other users would agree with me. No moving around the details of the implementation is going to fix this idea for me.

This idea -- no matter how you repackage it -- means that some label somewhere becomes the relevant part of the diagram to study. I don't know about you, but I generally ignore labels until after I've "read" the graphics. Labels that become "things I have to pay attention to" are negatives.

Even if you get passed that, it that there is another syntax on the block diagram for a very common operation. Why do we need a second way to state the same thing? The graphics are recognizable patterns. What do I mean by that? I mean that an Add primitive has two wires going into it. You remove one of those wires by packaging the constant inside, I guarantee that someone is going to misread it as an Increment node, no matter what you put in the label, and they're going to cuss at whoever hid the constant once they finally realize their mistake. Note-- something like this already happens with collapsed cluster constants when the cluster has a non-default value.

Then there's the sharing of constants. Frequently the same constant is needed in multiple places. If it is wired, it is easy to fork the wire. If it is configured, it is not available for sharing. By encouraging values to not be shared, I think this would take a step backwards.

Diagram space is not the end-all be-all of feature design. I don't think that this more compact notation is a desirable thing. The savings is minimal, the noise reduction is minimal, and the amount of work I'm going to have to do to go *unhide* all of those constants (and then clean up the wiring on the diagram to make enough space to read them) means I'm not going to like reading the code of whoever took the time to hide them.

I hope you see why I'm being negative here... this proposal is solving a problem that I do not think is a problem. Rather, it is creating a problem by breaking the readability of the diagram. Unless you convince me that the constant on the diagram is a problem to be solved, no amount of change in the UI for this is going to get me on board with the brainstorming. Does that make sense?

[AristosQueue (NI)]

PS: I also would never have put the expression node into LabVIEW in the first place, so comparisons to that node don't win points in my book. 🙂

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.