LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I reach the Limits on a DBL Slider

Hello!

I think my problem concerns something that many people should be using and I can't imagine that I am the first who has this kind of problem.

 

I have a slider control with digital display configured with the following settings:
Scale Range Min: -60 (just for example)
Scale Range Max: 60 (just for example)
Data Entry Min: -45 with "Coerce"
Data Entry Max: 45 with "Coerce"
Increment: 0.1 with "Coerce to Nearest"

My problem is that when I start incrementing the values using the increment/decrement button (or up/down arrow keys) often I can only go up to 44.9 but not to the full maximum of 45. The same happens when I decrement towards the minimum, there I get to -44.9 but not to the full minimum of -45. If I set the value directly to 45 or -45 through the slider or by entering 45 or -45 into the digital display everything is fine and I reach the full limits.
The problem seems to be that double values cannot be represented exactly on computers and if a value is incremented/decremented it goes a bit over/under my limit (even if this becomes visible many digits behind the decimal point) and LabVIEW won't set the slider to the limit so it stays at the previous value (44.9 or -44.9).

Whether I can reach the full minimum or full maximum seems to depend on my starting point on the slider, i.e. from where I start to increment or decrement.

I tried many things like adding tolerances of 0.001 to the Data Entry Min/Max to make this work but it did not help or introduced other problems. I even set the Data Entry Min and Max to "Ignore" instead of "Coerce" but when I increment/decrement again I don't get the full range. This is very strange because I can enter values like 50, -50, 60, -60 and so on and they are accepted, I just don't get from 44.9 to 45 by incrementing.

My question is: Is there any solution other than setting Data Entry Min/Max and Increment to "Ignore" (i.e. no automatic handling by lLabVIEW), then rounding my values manually and setting the slider manually to the desired value after its Value Change Event? This will cause additional overhead and is not what I expected from LabVIEW in such a simple UI requirement.

Thanks for any help in advance!
Anguel

0 Kudos
Message 1 of 39
(5,658 Views)

This shouln't be a problem. Please try to create a new VI with a lonely slider with a numeric indicator. Without copying the last one! Don't make any modif, look if you can reach your limits, and then customize your slider step by step and verify it still works after each step.

 

Give us some news

0 Kudos
Message 2 of 39
(5,645 Views)
Sorry, I should have mentioned that I have already contacted NI by phone and the NI engineer could reproduce the problem but could not find a solution to it. The engineer even said that this is expected behavior. For me it looks more like a bug or incomplete behavior. I posted this question to the forum bacause I can't imagine that I am the first one who has had this kind of problem and there should be an elegant solution to it, other than manually handling the slider after the value change event.
0 Kudos
Message 3 of 39
(5,637 Views)
Could you post a simple VI with your problem? I hardly figure out what you've done.
0 Kudos
Message 4 of 39
(5,612 Views)
Here is a VI with short decription.
0 Kudos
Message 5 of 39
(5,606 Views)

AStankov wrote:
Sorry, I should have mentioned that I have already contacted NI by phone and the NI engineer could reproduce the problem but could not find a solution to it. The engineer even said that this is expected behavior. For me it looks more like a bug or incomplete behavior. I posted this question to the forum bacause I can't imagine that I am the first one who has had this kind of problem and there should be an elegant solution to it, other than manually handling the slider after the value change event.

 

"Expected behavior".  I would like to hear a good explanation as why this would be expected.  It sure sounds like a bug to me.

 

Here is another interesting observation.  I made the upper and lower limits 45.01 and -45.01.  With the increment being .1, I figured I might be able to get it to sneak in and allow 45 and -45.  It did allow 45, but not -45.  However, when I hooked up a numeric indicator to that slide control, the actual value was always .01 less than it should be, even for dead on zero, the indicator said -.01.

DBL_Slider_Limits_Problem[1].png

0 Kudos
Message 6 of 39
(5,586 Views)

Ravens Fan wrote:

"Expected behavior".  I would like to hear a good explanation as why this would be expected.  It sure sounds like a bug to me.

 

Here is another interesting observation.  I made the upper and lower limits 45.01 and -45.01.  With the increment being .1, I figured I might be able to get it to sneak in and allow 45 and -45.  It did allow 45, but not -45.  However, when I hooked up a numeric indicator to that slide control, the actual value was always .01 less than it should be, even for dead on zero, the indicator said -.01.

 


 

 

That's exactly what I also observed. That's why I said that trying to fix the problem leads to other problems in my initial post. I tried adding the tolerance to the limits but this did not work because of the problem Ravens Fan explains. The way the slide control works is very very strange. I will contact NI again and send a link to this thread. I am new to LabVIEW and did not expect such a bug in a software developed since 20 years, being in version 8.6 and sold for that price. This is even the second bug in the slide control. I had to patch 8.6.1 to 8.6.1f1 to be able to set the slide limits at all...

0 Kudos
Message 7 of 39
(5,571 Views)

Hello

 

I can also reproduce the problem in my LabVIEW 8.6.1, and I din´t find any solutions or informations to correct this.

So we will produce a corrective action request to our developers.

 

I will give you some more informations when this procedure has been started and I got an answer.

 

Kind regards

 

 

 

0 Kudos
Message 8 of 39
(5,542 Views)

Pixar wrote:

 

So we will produce a corrective action request to our developers.

I will give you some more informations when this procedure has been started and I got an answer.

 


Thank you Pixar. I also sent an e-mail bug report to NI Support here in Germany and pointed them to this thread. They have not answered yet.

 

Best regards,

Anguel

0 Kudos
Message 9 of 39
(5,528 Views)
Still no e-mail from NI. Our project is delayed...
0 Kudos
Message 10 of 39
(5,402 Views)