06-04-2009 06:33 AM
09-08-2009 04:21 AM
09-08-2009 05:05 AM
Hi AStankov,
what about this little work-around:
You check the limits in an event case and set only the increment of the slider...
The problem mainly results from límited resolution of DBL floats and your use of a "0.1" increment, which cannot be represented as DBL correctly.
09-08-2009 05:45 AM
Hi GerdW,
Thank you for the tip! Unfortunately I use Value Change event cases which handle multiple slides at the moment. Also my limits need to be read from a device configuration. Additionally I use a queued state machine. So I will have to check if this can be implemented. And after all I bought LabVIEW to make my life easier and not to fix its problems with workarounds...If I remember I had tried a similar workaround in the past but could not solve the problem.
Best regards,
Anguel
09-08-2009 01:37 PM
AStankov wrote:Hi GerdW,
Thank you for the tip! Unfortunately I use Value Change event cases which handle multiple slides at the moment. Also my limits need to be read from a device configuration. Additionally I use a queued state machine. So I will have to check if this can be implemented. And after all I bought LabVIEW to make my life easier and not to fix its problems with workarounds...If I remember I had tried a similar workaround in the past but could not solve the problem.
Best regards,
Anguel
Ouch! From what I have read so far, this isn't necessarily a LabVIEW issue as much as it's an issue with how computers represent floating point numbers?
Bill
09-08-2009 01:46 PM
Hi Anguel,
I have to echo Bllko's sentiment when he questioned if you read;
"
The problem mainly results from límited resolution of DBL floats and your use of a "0.1" increment, which cannot be represented as DBL correctly.
"
Please see these links on "epsilon" for more reading on this subject.
Only an old analog computer could do an exact match and trust me they where much hardrer to program (required a soldering iron or a wire-wrapping tool).
Ben
09-08-2009 02:07 PM
Anguel,
If you really need a slider which can only go in 0.1 increments (as perceived by the user), make the control an integer control and divide by ten.
If the integer control has a range of -450 to +450 this will give you what you seem to be seeking. Adding DBL indicator(s) will allow the display of the decimal point. Notice that I hid the DBL slide indicator behind the I32 slide control. The Control's scale is blank. The Indicator's scale is visible. The Numeric indicator is positioned over the Digital display of the I32 control so that the decimal point shows. Sample VI is in LV2009.
Lynn
09-09-2009 03:30 AM
Thanks to all for the comments and workarounds. As I already said I would have to rewrite my complete code if I wanted to try to implement them. Adding the workarounds would also render my code even slower than it is at the moment. I don't think that this was my intention when I paid for LabVIEW.
As far as I see it is simple to solve the problem. The problem is that LabVIEW adds the increment every time the number in the digital display is being increased by the user. The error caused by DBL representation sums up and when I want to increase from 44.9 to 45 LabVIEW calculates the 45 as 45.00000000000000XXX which is greater than 45 and does not allow this number. If there were an option in LabVIEW to make the 45.00000000000000XXX coerce to the upper limit which is 45 everything would be fine...
Best regards,
Anguel
09-09-2009 12:09 PM - edited 09-09-2009 12:12 PM
AStankov wrote:Thanks to all for the comments and workarounds. As I already said I would have to rewrite my complete code if I wanted to try to implement them. Adding the workarounds would also render my code even slower than it is at the moment. I don't think that this was my intention when I paid for LabVIEW.
As far as I see it is simple to solve the problem. The problem is that LabVIEW adds the increment every time the number in the digital display is being increased by the user. The error caused by DBL representation sums up and when I want to increase from 44.9 to 45 LabVIEW calculates the 45 as 45.00000000000000XXX which is greater than 45 and does not allow this number. If there were an option in LabVIEW to make the 45.00000000000000XXX coerce to the upper limit which is 45 everything would be fine...
Best regards,
Anguel
Wow, now you're blaming LabVIEW about a coding decision that YOU made... I get the feeling you're just a LabVIEW hater. 😉
Anyway, what's wrong with rounding the number to the nearest tenth?
Edit:
Also, I don't see how implementing johnsold's solution would require a complete rewrite... or are you that umm... well I won't go there, I promised not to start any flame wars today. 😄
Bill
09-09-2009 02:38 PM
Have you tried making the upper limit e.g. 45.0001. You can coerce it in the code if needed.