An absurd execution by LabVIEW

[gkartik]

Hi,

In my project I need to monitor the input values of a control to check for a particular condition, but Labview is not working as expected, even if the condition is met, the boolean output is not changing. Please help.

[Blokk]

No, it is not absurd 😄 This is expected, this is how computers work.

Read this:

http://www.ni.com/white-paper/7612/en/

ps.: why do you use that property node? You have there the "Input" control, just connect it to the "Equal?" functions via wire. (Over)using property nodes might slow down your application:

http://digital.ni.com/public.nsf/allkb/74ECB57D3C6DF2CE86256BE30074EC47

Spoiler

Negatives

• Required to update the front panel item every single time they are called.  
• They are a pass by reference function as opposed to a pass by value function.  This means they are essentially pointers to specific memory locations.  The pointers must be de-referenced, and then the value in memory updated.  The process of de-referencing the variables causes them to be slower than Controls/Indicators, or Local Variables.
• Property Nodes cause the front panel of a SubVI to remain in memory, which increases memory use.  If the front panel of a SubVI is not displayed, remove property nodes to decrease memory use.

 EDIT:

And as you read, if you change the data type to integer, then your code will work just fine. Moreover, this is not a LabVIEW specific thing. You can expect this behavior in any computer language.

[majoris]

You are using DBL constant (a floating point number) and using the equality function to compare them. This can be risky because 0 isn't always 0 with floating point (it depends not just on the display formatting options but also the representation of the underlying value as floating points can represent similar numbers in different ways). If you only need integer numbers, right click 'input', 'output' and the constants and change their 'representation' to an integer type such as I32.

If you need floating point numbers, there are a few things you can do but it depends on why this function isn't working. For instance, you can make an approximately equals function with some kind of tolerance such as the one I have attached compiled to Labview 2014. The tolerance depends on your application.

For the record, when I run your VI, it works in 2016 just fine.

[arteitle]

I ran your VI and used the increment button to increment the input value until it read "1", and I saw the same behavior as you. Then I changed the display format of the input field to show more significant digits, and I saw that the actual value in the input wasn't exactly 1, it was 0.99999999999999988900... Due to rounding the input reads "1", but it's not exactly 1, so when you compare it to exactly 1 they're not equal. This is always a problem with comparing floating point numbers, please read this: http://digital.ni.com/public.nsf/allkb/B01682241DD825948625665100663F61

[Blokk]

You can also use some toolkits from VIPM for such comparisons, like this function from MGI (so you do not need to program it yourself):

[gkartik]

Thank you all for prompt response, I am happy that I learned something basic about floating point numbers.

[gkartik]

Thanks for response,

Yes, I'll keep in mind the things you've said about use of property node.

My actual VI contains the control inside a case structure for false condition, so I am unable to read the control to use it for case selection, so there I used a property node.

[Blokk]

---

@gkartik wrote:

Thanks for response,

Yes, I'll keep in mind the things you've said about use of property node.

My actual VI contains the control inside a case structure for false condition, so I am unable to read the control to use it for case selection, so there I used a property node.

---

That is not true. Delete that property node, and bring that control outside of that case structure. It does not need to be there! What can stop you to connect an extra wire which goes inside that case structure??

[crossrulz]

---

@gkartik wrote:

My actual VI contains the control inside a case structure for false condition, so I am unable to read the control to use it for case selection, so there I used a property node.

---

Not a good excuse.  You can fork your data wire to make it go to multiple places.  In fact, you should do a search around here for a thread "Clear As Mud".  In it was a discussion about how your terminals should avoid being inside of case structures for performance reasons.  So your code should loop more like this.