LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Numeric control increment/decrement problem

Solved!
Go to solution

I did a quick search in the forums, but I didn't find posts concerning my problem, so please forgive if the issue has already been resolved. I'm using LW 7.1, would be nice to know if this behaves the same way in new versions. 

 

In numeric control when increment step is set to 0,2 the increment/decrement using up/down arrow keys behaves erratically. For example if the value is 0,0 and I try to increment the first decimal, I can only go from 0,0 to 0,2 to 0,4 and then it’s stuck – behaves this way when using the up/down arrow keys, but if I use mouse to left-click the up/down buttons the value is incremented/decremented correctly i.e. in steps of 0,2. The range is set from 0,0 to 10,0.

 

If then the value is 1,0 I can only decrement to 0,8 and it’s stuck. But if I enter value 1,2 first, I can increment and decrement in the range of 1,2 - 2,0 in steps of 0,2 – using arrow keys. If I enter value 2,0 I can only decrement from 2,0 and then increment/decrement in the range of 1,2-2,0. But if I enter 2,2 I can increment to 3,0 but then I’m only able to decrement to 2,8, then it’s stuck.

 

I won’t go through all possible combinations, but the way the value is changed depends on the first digit and first decimal. First I thought this is related to knob’s digital display, where I discovered this behavior, but when I experimented with numeric control I noticed they behave the same. I also tested with integer numeric control with range of 0-100 and increment 2. With that I can increment in steps of 2 but decrement only in steps of 10.When increment is set to 0,1 (double) or 1 (integer) the value is changed correctly, except: in knob’s digital display I can’t decrement from 0,1 to 0,0.

 

So the problem is I can’t increment/decrement correctly using arrow keys, but with mouse and entering value in number field I can adjust value correctly in steps of 0,2 – or 2 in the case of integer. Now all I need is a workaround so that a user is able to use keys for adjusting the value. I'm not using events in my code, and adding event structure(s) would take too much time at this state of development. Any suggestions?

 

I attach a simple vi to test the controls.

0 Kudos
Message 1 of 12
(8,981 Views)

I think that this is due to where you are positionin the cursor in the control. LabVIEW increments the digit to the left of the cursor (with in the range) so if your value is 0.8 and you click down LabVIEW will try to reduce the value to -0.2 which is outside the range so it leaves it as 0.8.

 

Move the cursor to the right most digit and you will see it works fine.

 

It is quite a usefull behaviour of the control but I guess anoying if you dont expect it

David
www.controlsoftwaresolutions.com
0 Kudos
Message 2 of 12
(8,972 Views)

Changing the cursor position doesn't solve the problem, at least in my version. Whether the cursor is right or left of the first decimal the result is the same as I described, when 2 digits of precision is used, i.e. value is displayed for example as 0,80. 

0 Kudos
Message 3 of 12
(8,960 Views)

OK,

 

It seems to work for me (labVIEW 7.1 and 2009) so sorry I cant help further. I will be interested to see what the problem was!

 

Good luck

David
www.controlsoftwaresolutions.com
0 Kudos
Message 4 of 12
(8,955 Views)

Thanks for your reply, but now I'm more confused than ever. I'm using LW 7.1 and if it's working fine for you, I just don't understand why ?(  Am I just so blind I can't see the answer, is there some setting I'm overlooking or what? I've played with the controls but I just can't get around the problem 😞

0 Kudos
Message 5 of 12
(8,941 Views)

There was a bug in LV8.6.1 for the Data Entry tab of Numeric Controls. It was fixed by the LV8.6.1f1 patch. The behaviour was not exact the same but it was at least related to your problem. Unfortunately this will not be of any help since you are still using LV7.1...

 

Everything work's as expected with LV9.0f2.

 

 

0 Kudos
Message 6 of 12
(8,934 Views)

Can anybody give explanation why it’s behaving like this for me? In somebody else’s LW 7.1 it’s working fine… Is it system or OS (Windows) specific? I don’t know about these things… I did some testing; please look at the results in the attached picture, can you make any sense out of it. I tested with knob’s digital display because I’m using knob in my UI.

How I tested: I entered value by typing directly into numeric field. I positioned cursor with mouse next to the decimal I want to change (doesn’t really matter left or right). Then I used up/down arrow keys to increment/decrement value. In some cases the value wouldn’t change, and in some cases the value was incremented when up arrow key was pressed twice.

I tested with single and double precision numbers, and as you can see they behave differently, I highlighted the cases.

I attach the vi I used for testing.
Download All
0 Kudos
Message 7 of 12
(8,905 Views)
You have a "hungry loop" that is going to run as fast as it can eating up 100% of the processor.  Maybe that is interfering with the operation of your VI and the way LabVIEW handles the user interface.  Try putting a small wait statement in there and see if it behaves any differently.
0 Kudos
Message 8 of 12
(8,870 Views)

This is normal due to the limits of representing decimal fractions in binary. If you add multiple steps of 0.1 (which cannot be represented exactly in binary), you end up with a number of e.g. 10.00000000000x, which is above the upper limit. If you enter 10 directly, there are no decimals.

 

Quite a while ago there was a discussion how to improve this to make the behavior more as expected. I'll try to find it.

Message Edited by altenbach on 01-08-2010 09:04 AM
0 Kudos
Message 9 of 12
(8,860 Views)
Solution
Accepted by topic author devia

altenbach wrote:

 I'll try to find it.


Here it is! So....

 

Here is a related discussion, in particular see my suggestion towards the end if it.

 

(Did this ever got written upas a idea? If not, maybe I should :))

Message 10 of 12
(8,855 Views)