LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
FabiolaDelaCueva

Add "in range" condition to Conditional Signed32 Probe

Status: New

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

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
10 Comments
RavensFan
Knight of NI

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.

FabiolaDelaCueva
Active Participant

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

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
AristosQueue (NI)
NI Employee (retired)

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.

justin.goeres
Member

> 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.

SnowMule
Active Participant

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?

*****0....(5)....10*****

 

Send in a 5...

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

....0****(5)****10....

 

:dunno

elset191
Active Participant

@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.

--
Tim Elsey
Certified LabVIEW Architect
FabiolaDelaCueva
Active Participant
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.
For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
fabric
Active Participant
...so all that's needed is an option to either AND or OR the existing conditions. Sounds pretty simple (and useful)!
JeffreyH
Member

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

X.
Trusted Enthusiast
Trusted Enthusiast

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.