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: 

Add "in range" condition to Conditional Signed32 Probe

Currently the Conditional Signed32 Probe only offers the following conditions:

current conditions.PNG


I would like for the "In range" condition to be added (excuse the poor image):


proposed conditions.png


If you add that, you might want to add "out of range" also.  Actually, I think I'd be more likely to want to pause on something being out or range rather than in range.


I thought about it after posting it, you are right, we should probably have both options.  In range and Out of range.

Proven Zealot
Proven Zealot

What about inclusive or exclusive of the endpoints as on the In Range and Coerce node?


It never ends. The list of things we could add to that comparision list is totally open. This is why we created custom probes -- so you could write whatever comparison you need.


> What about inclusive or exclusive of the endpoints as on the In Range and Coerce node?


> It never ends.


I don't buy the slippery slope argument here. What Fabiola is suggesting (and I think it's a good suggestion) is the addition of one comparison mode to the Numeric Conditional Probe, a mode that duplicates something LabVIEW already has a primitive for.


By the logic you've offered, why does the current Numeric Conditional Probe have any functionality? Users should just make Custom Probes!

Not only that, why does vi.lib contain any VIs (rather than just primitives)? Users can just make their own VIs!


So you're right – it never ends. But I don't think it's reasonable to shoot down a suggestion based on the idea that improving one built-in Conditional Probe would open Pandora's Box.


Doesn't "Greater than" and "less than" kinda cover both "in range" and "out of range"?


Send in a 5...

if "greater than" is 10 and "less than" is 0... it's out of range?



Send in a 5...

if "greater than" is 0 and "less than" is 10"... in range?





SnowMule wrote:


Doesn't "Greater than" and "less than" kinda cover both "in range" and "out of range"?

Kinda, but you can't use AND in the probe as far as I know.  So every time the code breaks, you still have to manually compare to the other end of the range.

The conditional probe says: "Pause if any of the following conditions" If I get thousands of 29s and thousands of 0s and I want to pause when the value is in between 4 and 13, which is rare in this case. If I set it to pause if value is greater than 4 or if value is less than 13, I will end up pausing thousands of times for the 29s and thousands of times for the 0s, only because I wanted to catch the few cases where the value is between 4 and 13. And yes, I created my custom probe, and there are other ways around it, like using "in range" directly on the code and adding a conditional probe to the boolean output... Is just I thought this would be a nice out of the box feature for that conditional probe.
N/A all that's needed is an option to either AND or OR the existing conditions. Sounds pretty simple (and useful)!

Kudos.. For the AND en OR variant as mentioned by fabric. And this could be applied to conditional string probe too.


I am not going to create a new idea for this, because from a development point of view, the nature of the suggestion and solution is similar, so here it is:


1. Add "Is Different From" (*)

2. Extend this to other numeric types



Combine 1 and 2 and you have "is a valid number" (Type: DBL and "Is Different from" NaN)?

I don't buy that this belongs to custom probes. This is the bread and butter of debugging nasty corner cases in numeric code.


(*) Or, in the spirit of Fabric's suggestion, add an option to "negate" a condition.