Conditional increase / conditional terminal

[xdaf]

I often need to count how many times a condition is verified inside a loop. The simplest way to do so is:

    

What about this?

The "conditional terminal" should be enabled by right clicking on the operator, and may apply to every VI with 1-1 I/O pattern.

Of course it performs the operation in case of "TRUE", and leaves its input value unchanged in case of "FALSE"

[lvABC]

Have you look into Increment PtByPt VI?

http://zone.ni.com/reference/en-XX/help/371361F-01/ptbypt/increment_ptbypt/

-lvABC

[JackDunaway]

Increment Pt by Pt is not quite a drop-in replacement because it cannot be arbitrarily initialized (the count always resets to zero). Also, the suggested primitive would presumably work for different datatypes, including the "circular incrementing" action of enums.

[Manzolli]

I'm not sure about this one. Instead of using the Case Structure, the Select function does a great job in this case, with minimal extra effort and space.

In the way presented by xdaf, the new function may be confused with a Boolean wire passing nearby the Increment function. I guess a little rework in the shape, that can be differentiate when the conditional terminal is active.

I also think that "Conditional Increment" would be a better name for it, in order to be coherent with the original function.

[JackDunaway]

The following low profile method would pair nicely with Change Output Representation on "Boolean to (0, 1)":

[JackDunaway]

And the sister function, conditional decrement:

[Manzolli]

Good one Jack, but it will have an implicit conversion (extra memory allocation) in numbers that are not I16. By the way, why not I32?

[JackDunaway]

---

Manzolli wrote:

Good one Jack, but it will have an implicit conversion (extra memory allocation) in numbers that are not I16. By the way, why not I32?

---

See Change Output Representation on "Boolean to (0, 1)" to fix this problem

[Manzolli]

Sure, I kudoed it. But since it is not implemented yet...

For me it's better have the idea Change Output Representation on "Boolean to (0, 1)" implemented because it will solve both problems with one "stone".

[AristosQueue (NI)]

The arguments for sticking a (completely arbitrary) boolean input on this node hold for every node in existence. If you want an input terminal to conditionally skip the execution of this node, make the terminal an Error Code Cluster -- at least that is consistent across LV as the "sometimes execute me and sometimes not" node. In general, though, I don't like sticking error code cluster terminals on nodes that cannot themselves generate errors because it encourages bad dataflow design among users who feel that every error terminal must be wired up. It's the reason I do not like the "arbitrary dataflow wire" that has been proposed elsewhere on the Idea Exchange. No kudos from me on this one...

[xdaf]

Good point Jack, I think I'll use this solution from now on.

Thanks to all for your comments.