Movement Accuracy Evaluation

[sebastian]

What ballpark accuracy should I expected from optical home dot calibration and a fully calibrated machine (squareness, slack compensation all enabled)?

I ran the following test:

• home machine (first limit switches then optical homing dot recognition)
• move head to some place in the middle of the table
• move the head to absolute position 0,0
• click Homing -> "measure" button and read the results from console.
• redo movement to table center, back to 0,0 and "measure"

calibrate01.PNG (66.19 KiB) Viewed 13647 times

The measured offsets are:
Run 1:
X: -0.085
Y: -0.127

Run 2:
X: -0.042
Y: -0.127

Run 3:
X: -0.085
Y: -0.127

Now in general 0.127mm accuracy sounds pretty good already.
But its strange that the offset is constant, doesn't increase with number of movements or over time...


Any thoughts?
What results does your machine provide with this method?

[santosp]

As the center of the table (approx) I use X: 290 & Y:190

Run 1:
X: 0.013
Y: 0.039

Run 2:
X: -0.026
Y: -0.039

Run 3:
X: 0.013
Y: -0.039

[JuKu]

[JuKu]

I have crashed my machine badly several times during software development. I have a feeling that something is loose, and/or belts have stretch, or something. Anyway, I need to use the rigorous homing; after that, I get the results shown in the video: Worst case deviation is 1 to 1.5 pixels on camera. I haven't tried to measure how much of the error is from camera, how much is from mechanics.

[wormball]

Hello!

I am experiencing similar problem. If i push home button, error is about +-0.01 mm. But if i move somewhere and then move to 0, 0, then errors become almost exactly +0.1 mm at both axes. Moreover, if i go to some other location, the situation remains the same - if i go from the left, the actual (visual) X coordinate will be 0.1 mm less than in the case i was going from the right (but nominal coordinate is exactly the same). The same about Y axis. Regardless of exact angle and distance of movement.

So i am more than sure this is not mechanical problem cos otherwise errors would depend on speed, angle and distance, not only quadrant.

So main question is - is that a bug of tinyG or liteplacer software? And what is the probability of this being fixed?

[JuKu]

Have you tried rigorous homing and slack compensation on/off? Also, if you do have slack compensation on, try to change the small movement speed. Start with very slow and bring it up.

> actual (visual) X coordinate will be 0.1 mm less than in the case i was going from the right (but nominal coordinate is exactly the same).

To makes sure I get you right: By visual coordinate you mean where the machine actually is, determined by camera. By nominal, you mean what is shown on screen. Correct?

> So main question is - is that a bug of tinyG or liteplacer software? And what is the probability of this being fixed?

Assuming it is a bug, the harsh truth is that probability is close to 100% if I can find a way to reproduce it, close to 0 if not. If you can send me a log about this, I can see what is commanded, and what the machine actually does. Click inside the log window, ctrl+A to select all, copy and paste to a text document. At least we can rule out a case of "with these particular settings*, the machine goes 0.1mm short of what is asked". Also, I'd like to get your TinyG settings: send text $$ and send me the log. (That command dumps all TinyG settings to a log window in human readable form).

*: I'm sure that my machine does not do that, but I'm much less confident that there isn't some combination of settings that could hit a limit case and exhibit this behavior.

[wormball]

I measured voltages on X motor windings after approaching the same point from both sides:

Code: Select all

      A        B
> -1.050 1.181
< -1.179 1.055
> -1.056 1.186
< -1.184 1.059

However commands from program to tinyG tell the same coordinate:

Code: Select all

X:
CNC_XYA_m, x: 89.70674692, y: 34.284, a: 0
==> {"gc":"G0 X89.788 Y34.284 A0"}
<== {"r":{},"f":[1,0,31,132]}
<== {"sr":{"posx":77.790,"vel":22.43,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":89.786,"posy":34.284,"vel":96.17}}
<== {"sr":{"posx":89.788,"vel":0.00,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}
X:
CNC_XYA_m, x: 101.70674692, y: 34.284, a: 0
==> {"gc":"G0 X101.788 Y34.284 A0"}
<== {"r":{},"f":[1,0,32,133]}
<== {"sr":{"posx":89.790,"vel":22.43,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":101.786,"vel":96.19}}
<== {"sr":{"posx":101.788,"vel":0.00,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}
X:
CNC_XYA_m, x: 89.70674692, y: 34.284, a: 0
==> {"gc":"G0 X89.788 Y34.284 A0"}
<== {"r":{},"f":[1,0,31,132]}
<== {"sr":{"posx":101.786,"vel":22.43,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":89.788,"vel":22.44}}
<== {"sr":{"posx":89.788,"vel":0.00,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}
X:
CNC_XYA_m, x: 77.70674692, y: 34.284, a: 0
==> {"gc":"G0 X77.387052 Y33.884 A0"}
<== {"r":{},"f":[1,0,34,135]}
<== {"sr":{"posx":89.786,"posy":34.284,"vel":20.05,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":77.389,"posy":33.884,"vel":20.05}}
<== {"sr":{"posx":77.387,"vel":0.00,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}
==> {"gc":"G1 F1000 X77.788 Y34.284"}
<== {"r":{},"f":[1,0,34,135]}
<== {"sr":{"posx":77.390,"posy":33.887,"feed":1000.00,"vel":45.18,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":77.788,"posy":34.284,"vel":0.00,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}
X:
CNC_XYA_m, x: 89.70674692, y: 34.284, a: 0
==> {"gc":"G0 X89.788 Y34.284 A0"}
<== {"r":{},"f":[1,0,31,132]}
<== {"sr":{"posx":77.790,"vel":22.43,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":89.788,"vel":22.44}}
<== {"sr":{"posx":89.788,"vel":0.00,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}
X:
CNC_XYA_m, x: 101.70674692, y: 34.284, a: 0
==> {"gc":"G0 X101.788 Y34.284 A0"}
<== {"r":{},"f":[1,0,32,133]}
<== {"sr":{"posx":89.790,"vel":22.43,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":101.788,"vel":22.44,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}
<== {"sr":{"posx":101.788,"vel":0.00}}
X:
CNC_XYA_m, x: 89.70674692, y: 34.284, a: 0
==> {"gc":"G0 X89.788 Y34.284 A0"}
<== {"r":{},"f":[1,0,31,132]}
<== {"sr":{"posx":101.786,"vel":22.43,"stat":5}}
<== {"qr":31,"qi":1,"qo":0}
<== {"sr":{"posx":89.788,"vel":22.44}}
<== {"sr":{"posx":89.788,"vel":0.00,"stat":3}}
ReadyEvent stat
<== {"qr":32,"qi":0,"qo":1}

So it's definitely tinyG bug.

"Vigorous homing " has nothing to do with this, but "slack compensation" solves this problem at expense of slightly slower operation.

[JuKu]

I’m traveling this week and I don’t have access to my machine until next week. I’ll have a look at this then and I’ll talk to the TinyG manufacturer. Thank you for your observations!

[wormball]

I'm sorry, i was most probably wrong.

First, when i tried to reproduce 0.1 mm difference, i got random differences about the same value but not exactly 0.1 mm. So it may be mechanical issue. Maybe it is due to low rigidity of the "new" camera mount. I will examine this later.

Second, i calculated a little and realized that abovementioned difference in motor voltages can not explain the difference in coordinates. I use 1.8 degree motors, so one step is 40 mm /200 steps = 0.2 mm and one microstep is 1/8 step = 25 micrometers.

Angle difference between measured motor voltages is (arctan2(-1.179, 1.055) - arctan2(-1.050, 1.181)) * 180/pi = -6.54 degrees or 1/13.77 of full step or 14.5 micrometers.

So electric difference can explain only 1/7 of mechanical difference. Interestingly, it is not multiple of 1/8 step, as you may expect with 1/8 step driver.

Maybe i will make motor phase indicators from cheap chinese nano stepper motors.