From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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.
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"?
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.
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.