LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I reach the Limits on a DBL Slider


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.

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 21 of 39
(1,489 Views)

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.

Message Edited by Darin.K on 09-09-2009 04:40 PM
0 Kudos
Message 22 of 39
(1,475 Views)

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

0 Kudos
Message 23 of 39
(1,450 Views)

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

0 Kudos
Message 24 of 39
(1,448 Views)

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 25 of 39
(1,434 Views)

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

Message Edited by AStankov on 09-10-2009 04:06 PM
0 Kudos
Message 26 of 39
(1,428 Views)

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 

Message 27 of 39
(1,413 Views)

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.

 

 

0 Kudos
Message 28 of 39
(1,394 Views)

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.

  1. Place a digital control on the front panel.

     Place  Find
  2. Using the Operating tool, click the increment and decrement buttons. The value increases and decreases by one.
  3. Click and hold down the increment button to increase the value repeatedly.
  4. Using the Positioning tool, resize the digital control. Notice that the control can be increased in length only horizontally.
  5. 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.
  6. Change the value of the digital control to 10 by double-clicking inside the display window, typing 10, and pressing the <Enter> key.
  7. Click the increment button two times. The value increases by one with each click and the value is now 12.
  8. 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.
  9. 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

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 29 of 39
(1,386 Views)

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.

  1. Place a digital control on the front panel.

     Place  Find
  2. Using the Operating tool, click the increment and decrement buttons. The value increases and decreases by one.
  3. Click and hold down the increment button to increase the value repeatedly.
  4. Using the Positioning tool, resize the digital control. Notice that the control can be increased in length only horizontally.
  5. 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.
  6. Change the value of the digital control to 10 by double-clicking inside the display window, typing 10, and pressing the <Enter> key.
  7. Click the increment button two times. The value increases by one with each click and the value is now 12.
  8. 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.
  9. 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.

Message Edited by billko on 09-10-2009 10:55 AM
Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 30 of 39
(1,366 Views)