I have run into this problem in programming. It may be that 90 is never = 90, but rather 90.0000001 due to floating point rounding errors. And like you I have solved the problem by using < and >, or by truncating the value to the needed accuracy.
Im working on a macro for fine tuning my A axis index points of 0, 90,180, 270. basically it accounts for pulley variation and encoder error. After the A axis is commanded to a position, the adjustment macro is called which starts with:
A = GetOEMDRO(803)
This part works fine and returns the value that is currently in A axis dro. Then i run through some if then statements to move the axis to corrected value. For example:
if A = 90 Then
code "G0 A89.9780" // calibrated position for exactly 90 degrees from 0
elseIf A = 180 Then
code "G0 A179.7803" // calibrated position for exactly 180 degrees from 0
etc.
Problem is, A = 90 and A = 180 etc isnt working. I also tried exactly as its shown in dro, like 90.0000, still doesnt work.
I tried using a range of more than and less then, which seems to work. for example:
If A < 90.01 And A > 89.99 Then
code "G0 A89.9780"
Why does it work this way but not when using "=" ?
Similar Threads:
- New Machine Build- Profile Rail Wood Frame Router, 25" x 37" x 6" working area
- "Probe" and "Verify" not working - Mach3 & ESS
- Need help working out feed rate for "C" Axis and "Z" axis simultaneously.
- Error: ..."Script Control (msscript.ocx)" when creating pipe network
- Problem- X Axis "Goes Off Pattern", "Awry", "Skewed", "Travels"
I have run into this problem in programming. It may be that 90 is never = 90, but rather 90.0000001 due to floating point rounding errors. And like you I have solved the problem by using < and >, or by truncating the value to the needed accuracy.
Jim Dawson
Sandy, Oregon, USA
i bet thats exactly what it is. I forgot mach3 is using something like 12 decimal places even though only 4 are displayed. since my steps per degree is 45.51111111111, 90 degrees is going to round to nearest step which puts dro at 90.000000002197. Not a big deal to use the <> range, at least now i know why. thanks!
Try something like this, to see what the actual value of A is.
A2 = FormatNumber(A,15)
MsgBox (A2)
EDIT
Looks like it might need to be:
A2 = Format(A, ##0.000000000000000000)
Gerry
UCCNC 2017 Screenset
[URL]http://www.thecncwoodworker.com/2017.html[/URL]
Mach3 2010 Screenset
[URL]http://www.thecncwoodworker.com/2010.html[/URL]
JointCAM - CNC Dovetails & Box Joints
[URL]http://www.g-forcecnc.com/jointcam.html[/URL]
(Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)
I'll try it out, good to know I can check the actual value like that.
I wonder if I can actually use this to allow the use of equals. I can format A2 as only 2 or 3 decimal places, then use it in the rest of my script. At that point it should truly be equal to 90, 180, 270. I'll test it tonight. Probably what Jim meant by truncating the number
The scripting Mach3 uses, Cypress Enable, is a little different than VB, which is why I added the Format above. The Format returns a string, so you'd need a different function to get rid of the decimals, but yes, that's the best way to go about it.
Gerry
UCCNC 2017 Screenset
[URL]http://www.thecncwoodworker.com/2017.html[/URL]
Mach3 2010 Screenset
[URL]http://www.thecncwoodworker.com/2010.html[/URL]
JointCAM - CNC Dovetails & Box Joints
[URL]http://www.g-forcecnc.com/jointcam.html[/URL]
(Note: The opinions expressed in this post are my own and are not necessarily those of CNCzone and its management)
This is a pretty common issue with floating point numbers in any software.
Depending on the language I'll write an "isClose" utility function which takes the two numbers being compared, an optional precision eg 0.001, and contains:
return ((a - precision <= b) && (a + precision >= b))
or just use ABS(a-b)<0.001 instead of a==b
This is a pretty common issue with floating point numbers in any software.
The bane of novice programmers in almost any language.
Cheers
Roger
hy quin if you wish to fine tune your code, then maybe this helps :Im working on a macro for fine tuning my A axis index points of 0, 90,180, 270
... unidirectional positioning : for 90*, always approach from 89*; same, for 180*, always approrach from 179*; same, for 270* approrach from 269*; for 0*, approach from 359*; thus, for x*, always approach from x*-angle_value_greater_then_backlash(avgtn)
... always execute avgtn, at a small feedrate
if you will implement those 2, then you may achieve a higher consistency, but in reality, this extra-precision may not always be a must thus, even if you code those inside your itsi-bitsy macro, it won't boost your machine if there is too much wear; play with avgtn and small feeds
in most cases, for general software, it may be a floating error, but cnc's may be coded differently, and the field that stores data may have noise inside it, that is not present when machine is delivered, but is build up in time because of math calculations; if you wish to find out the error, then try this :Why does it work this way but not when using "=" ?
x=90
x=x-90
repeat x=x*10 until_something<>0_will_popp_up; this will tell something about the precision of your cnc
if this value is aproxE10-3 then you may machine without worries, and also without using macros; if you wish to use macros, then you won't be able to reach a level of calculations that leads to an error sum > then the needed precision, and in many cases you may have to use a particular approach to handle the except yup, as you can see, you may replace 'a=b' with '|a-b|<eps'; this is also present on modern machines, but at a smaller scale, and it leads to misscalculations inside mathematic formulas; if you wish to live with it, you have to keep the numbers in a range that is not affected by noise / kindly
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
You do get used to the limitations of floating point calculations.
Mach3 sometimes annoys me with the formatting of the DROs. I tell the CNC to go to X=40.0 and the DRO shows it has gone to X=39.9997. Why hasn't it gone to where I told it to?
In reality it can not. The single step resolution of the ball screw is 0.8 microns; the position 'error' is 0.3 microns. That is s close as it can get.
While this has actually nothing to do with the floating point resolution in the SW, it is in many ways the same problem. The system can only operate to within certain error bands, and hoping to get exact equality is futile. We must work within the abilities or limitations of the system. Yes, that means you have to think.
Cheers
Roger