09-09-2009 03:29 PM
altenbach wrote:Have you tried making the upper limit e.g. 45.0001. You can coerce it in the code if needed.
This worked when I tried it. I thought he said in his original post that he tried this and it didn't work, though.
09-09-2009 04:33 PM - edited 09-09-2009 04:40 PM
My advice is to bag the increment/decrement buttons altogether. If that is all you fiddle with, why bother with a slide? You can still use the digital display, and the arrow keys work nicely. No fudging the ranges and no funny offsets to deal with. If you want to get fancy you can even use Key Navigation to map keys to increment and decrement.
Upon further review, you are still screwed.
09-10-2009 04:01 AM
Once again I want to emphasize that none of the workarounds make the slider work exactly as it should. The interaction between the slider and the digital display is not so simple because there a couple of interdependences. Yes, I need a slider, a digital display with increment/decrement arrows and I need to be able to enter the values directly into the display. That's why I bought LabVIEW and I don't think that what I need is something complicated or strange. I just need that the digital display allows me to enter the same values the slider allows me to do. The slider is a standard component in LabVIEW which is advertised to do exactly what I need. Who could expect that it is only able to work correctly with integers - that's ridiculous! NI confirmed that the implemented behavior of the slider is not the expected behavior. They told me that the bug will be solved, but right now I don't expect that this will happen soon if it happens at all.
In my program I have about 20 sliders which behave in a similar way. Their limits are read from a device and set programmatically at program statup. Additionally a single value change event handles all sliders, and writes multiple items into a queue that drives a queued state machine loop. Implementing any workaround causes a complete rewrite of the code, handling the sliders separately and adding a bunch of variables to communicate between the event handling loop and main loop. I would need a lot of time to rewrite (redraw) the program and who is going to pay me for this? Additionally the program is so slow and I expect that any workaround will make it even slower if I try to simulate what a slider with a working digital display should do. No other programming language I know is so slow on updating its interface. I am not a LabVIEW hater, I am just angry that it is not able to handle such simple things in version 9. If there was a simple possibility to set an artificial decimal point on the slider and the digital display this would also solve my problem...
09-10-2009 04:15 AM
elset191 wrote:
altenbach wrote:Have you tried making the upper limit e.g. 45.0001. You can coerce it in the code if needed.
This worked when I tried it. I thought he said in his original post that he tried this and it didn't work, though.
Enter -45,0001 as Minimum and 45,0001 as Maximum. Enter any number into the digital display. This number will be ALWAYS -0,0001 off and 0 will show up as -0,0! Welcome to LabVIEW...
09-10-2009 07:25 AM
AStankov wrote:... Welcome to LabVIEW...
Correction:
"Welcome to the world of digital computers."
Analogy time:
If you have a complete set of drills starting at 1/128 and have every size in 1/128 th inch steps, you will still never be able to drill a hole exactly 1/3 inch because 42/128 is too small and 43/128 is too large.
DIGITAL computers represent fractional numbers as a ratio where the numerator is an INTERGER over a denominator that is a power of "2" (1,2,4,8,16,32,64,128,...).
Similarly with 1/10... can not be expressed exactly in a digital computer.
So the issue you are seeing is NOT a LabVIEW issue it is a digital computer issue.
Just trying to help,
Ben
09-10-2009 09:04 AM - edited 09-10-2009 09:06 AM
Correction:
"Welcome to the world of digital computers."
Analogy time:
If you have a complete set of drills starting at 1/128 and have every size in 1/128 th inch steps, you will still never be able to drill a hole exactly 1/3 inch because 42/128 is too small and 43/128 is too large.
DIGITAL computers represent fractional numbers as a ratio where the numerator is an INTERGER over a denominator that is a power of "2" (1,2,4,8,16,32,64,128,...).
Similarly with 1/10... can not be expressed exactly in a digital computer.
So the issue you are seeing is NOT a LabVIEW issue it is a digital computer issue.
Just trying to help,
Ben
Sorry but that's just an excuse. I understand the "problem" with digital computers but that cannot be the excuse for LabVIEW not being able to handle limits consistently in a slide. My question is very simple: Why is LabVIEW able to coerce a number greater than the allowed maximum when entered directly into the digital display (e.g. 999) to 45 but it is not able to do the same when I press the increment arrow or the up key? From my point of view this is nothing but inconsistent behavior, maybe due to insufficient testing during development. And for the user of the VI, i.e. our customer, this is nothing else but a software bug. He is able to set a number (in this case 45) using the slider or entering it directly but he is not able to set the same number when using the increment arrow or the up key on his keyboard (because he gets only up to 44,9).
09-10-2009 09:28 AM
Just for testing purposes: Set the increment to 1/4 or 1/8 or some other integer power of 2. Properties: Data Entry: Minimum = -45.0000, Coerce; Maximum = 45.0000, Coerce; Increment = -0.1250, Coerce to Nearest.
I understand that this is not what you or your customer would like to see, but it shows that the slider works consistently with the internal binary representation.
Lynn
09-10-2009 10:12 AM
If you want a solution that does not require any code changes, make an Xcontrol that handles all desired rounding internally and use it as a drop-in replacement.
Frankly, I don't understand your hangups here. As others have mentioned, 0.1 cannot be accurately represented in binary and there is no way around that. Do you really want LabVIEW to ignore standards that everybody else has agreed on? If you want different behavior, you need to program around it and there are plenty off suggestions.
If compilers would start correcting numbers internally by making assumptions about intent, chaos would ensue.
I haven't studied this, but maybe e.g. decimal64 could in the future solve your dillema this if it is ever adapted.
09-10-2009 10:26 AM
You can actually argue that the control is working as intended. See the "Increment/Decrement" help file here:
Using the Increment and Decrement Buttons
Using the Increment and Decrement Buttons
The increment and decrement buttons usually change the ones digit in a digital control. If you click an increment or decrement button and hold the mouse button down, the display increases or decreases until you release the mouse button. If you click the increment or decrement button, hold down the mouse button, and hold down the <Shift> key, the size of the increment increases by successively higher orders of magnitude. The value first increments by ones, then by tens, by hundreds, and so on. As the range limit approaches, the increment decreases by orders of magnitude, slowing down as the value reaches the limit.
To use the arrow keys to change a digital display by a digit other than the default increment, use the Operating tool to place the insertion point to the right of the target digit.
Complete the following steps to practice using the increment and decrement buttons.
- Place a digital control on the front panel.
Place
Find
- Using the Operating tool, click the increment and decrement buttons. The value increases and decreases by one.
- Click and hold down the increment button to increase the value repeatedly.
- Using the Positioning tool, resize the digital control. Notice that the control can be increased in length only horizontally.
- Using the Operating tool again, hold down the <Shift> key while holding down the increment button. Notice that the value begins to increase by one, but then by tens, hundreds, and so on.
- Change the value of the digital control to 10 by double-clicking inside the display window, typing 10, and pressing the <Enter> key.
- Click the increment button two times. The value increases by one with each click and the value is now 12.
- To increment by tens, use the Operating tool to place an insertion point to the right of the tens digit. Press the up arrow key to increase the value to 22. By placing the insertion point to the right of the tens digit, the increment value is changed to tens.
- Move the insertion point to the right of the ones digit, and click the increment button. The value increments to 23. Notice that the ones digit again becomes the increment digit.
Right-click a numeric control and select Visible Items»Increment/Decrement from the shortcut menu to display or hide the increment and decrement buttons. You also can use the Increment/Decrement Visible? property to display or hide the buttons programmatically.
From what this says, I surmise that the Increment/Decrement value was never meant to be fractional. All the references are to integers. While it never states that fractional values aren't recommended, there are plenty of times it would infer this.
Bill
09-10-2009 10:52 AM - edited 09-10-2009 10:55 AM
billko wrote:You can actually argue that the control is working as intended. See the "Increment/Decrement" help file here:
Using the Increment and Decrement Buttons
Using the Increment and Decrement Buttons
The increment and decrement buttons usually change the ones digit in a digital control. If you click an increment or decrement button and hold the mouse button down, the display increases or decreases until you release the mouse button. If you click the increment or decrement button, hold down the mouse button, and hold down the <Shift> key, the size of the increment increases by successively higher orders of magnitude. The value first increments by ones, then by tens, by hundreds, and so on. As the range limit approaches, the increment decreases by orders of magnitude, slowing down as the value reaches the limit.
To use the arrow keys to change a digital display by a digit other than the default increment, use the Operating tool to place the insertion point to the right of the target digit.
Complete the following steps to practice using the increment and decrement buttons.
- Place a digital control on the front panel.
Place
Find
- Using the Operating tool, click the increment and decrement buttons. The value increases and decreases by one.
- Click and hold down the increment button to increase the value repeatedly.
- Using the Positioning tool, resize the digital control. Notice that the control can be increased in length only horizontally.
- Using the Operating tool again, hold down the <Shift> key while holding down the increment button. Notice that the value begins to increase by one, but then by tens, hundreds, and so on.
- Change the value of the digital control to 10 by double-clicking inside the display window, typing 10, and pressing the <Enter> key.
- Click the increment button two times. The value increases by one with each click and the value is now 12.
- To increment by tens, use the Operating tool to place an insertion point to the right of the tens digit. Press the up arrow key to increase the value to 22. By placing the insertion point to the right of the tens digit, the increment value is changed to tens.
- Move the insertion point to the right of the ones digit, and click the increment button. The value increments to 23. Notice that the ones digit again becomes the increment digit.
Right-click a numeric control and select Visible Items»Increment/Decrement from the shortcut menu to display or hide the increment and decrement buttons. You also can use the Increment/Decrement Visible? property to display or hide the buttons programmatically.
From what this says, I surmise that the Increment/Decrement value was never meant to be fractional. All the references are to integers. While it never states that fractional values aren't recommended, there are plenty of times it would infer this.
Bill
But what I think is confusing is that the Property itself is a dbl and so you'd think fractional values were okay. Unless, of course, you were pretty sharp and noticed that dbl isn't going to give you exact increments sometimes.