Backlash compensation causing machine to lose position

[JW]

Hi all,

Still working through getting my new machine to the job it'll complete it's first job, and I got there tonight! However, I spent several hours trying to work out why after completing fiducial alignment of my PCB, the machine would lose position as it progressed through the job.

I.e. by component 30/40 etc, I had a good ~0.5mm or so of position error on the crosshairs.

Long story short, I ran lots of tests - including setting up a macro in Duet to just run the machine back and forth, in X and Y seperately, and XY combined, hundreds of times, and at the end of this test the machine returned to exactly where it started.

The machine is on ballscrews, with guaranteed backlash that is less than the pixel resolution of the cameras.

I turned off backlash compensation in OpenPnP, and the problem went away immediately, so I of course suspected an issue with the calibration - I re-ran the backlash calibration, and the issue persisted.

I fully appreciate OpenPnP is mature and widely used now, so it must be something I've done.

In hindsight, there is no need for backlash comp on my machine, which got me thinking - without understanding how the backlash comp works in details, presumably there's a fundamental limitation that says if your backlash is less than the camera resolution, which is being used to measure the backlash, then backlash comp cannot help further?

I've recorded lots of videos of the various tests, so if these will be helpful, I can pop them up on YouTube?

I've seen plenty of other ballscrew builds, so I guess others in the community have experience with backlash comp + ballscrew builds?

[mark maker]

Your other posts indicate problems with the camera calibration, maybe it is also related to a detection problem with the calibration fiducial.

Backlash calibration in turn completely relies on the camera giving very accurate fiducial results. So you must solve the first problem first.

> The machine is on ballscrews, with guaranteed backlash that is less than the pixel resolution of the cameras.

Ball-screws usually do have backlash when tuned for speed (as they should be for PnP), because preloading them for reduction of backlash increases friction a lot. AFAIK, preloading is therefore only done for slow machining where load-bearing direction-changes are involved while the tool is engaged (CNC mill).

Please send a screenshot of the backlash comp results, and/or the machine.xml

And yes, post some videos.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8d1c2f3f-346b-46a0-865e-c7e4a88300aen%40googlegroups.com.

[SM]

>> Ball-screws usually do have backlash when tuned for speed

Good ballscrews (ground) with 32mm or more pitch are really expensive.
I use very cheap ones (SFY1620, SFY2020) and have never had any problems with backlash, as it is negligibly small and therefore does not need to be compensated for.

This is what my backlash looks like (4mm left/right) after about 1.5 million component placements:
https://streamable.com/7atr3s

[JW]

Hi both, thanks for your feedback so quickly!

I'm also using relatively cheap rolled ballscrews, also 1620 and 2020, but their specified backlash is still < the camera resolution.

You're right Mark in that zero backlash screws are typically higher friction, and often run special nuts which are really 2 nuts preloaded against each other. I'm only using a single nut, so there is technically some backlash, but it's small enough you can't even see it with the cameras.

So, this video shows running through the placement positions in a job, with backlash compensation enabled. You can see very quickly we lose machine position, and by the time we get back to the fiducials, the machine is well out of position.

This video shows the machine in a fixed position, and me doing my best to move the head by hand (note this is not back driving the motors through the screws, as they are closed loop steppers holding their position, this is mechanical deflection in the gantry).

This video shows a positioning repeatability test running a macro script in Duet, which just performs a 25mm diagonal move, back and forth, 40 times (I ran it much longer, and the result is the same). You can clearly see the machine returning to exactly where it started.

This video, is the same as the first, but with backlash compensation turned off, which demonstrates the problem goes away entirely.

Re camera, I'll reply in that seperate thread to keep it all clean.

[mark maker]

> You can see very quickly we lose machine position, and by the time we get back to the fiducials, the machine is well out of position.

Like I said: backlash compensation relies on the calibration fiducial being detected reliably. I suspect this is not the case. Therefore, perhaps the backlash calibration obtained completely wrong results. Watching your videos, it should not find any backlash and propose to switch compensation off. But if the fiducial is detected wrong, all bets are off. 

Another vague possibility: if your camera (or lens) can't take the super-brutal and stiff accelerations you ball-screw guys are famos for, it might slightly tilt the view axis. This will likely result in an "artificial" backlash being detected. For instance: my ELP camera has a single tiny set-screw to fixate the camera lens thread, which is not really entirely wiggle free. Given enough stiff acceleration I can imagine it would shift. Others have reported that even the sensor inside the camera can apparently shift. This might also be limited to the special short distance direction reversing moves of the backlash calibration cycle (causing resonant agitation in the camera/lens mechanics), and not otherwise occur in normal longer distance moves.

If anything like this is the case, the backlash calibration would propose a misguided settings, it will position with a large offset depending on which side it comes from (per axis).

Note, it is almost impossible that this is a permanent machine offset. OpenPnP uses absolute coordinates. How could backlash compensation cause permanent offsets?

Send the log at TRACE logging level, then we see what G-code is sent and what coordinates.

And I repeat: Please send a screenshot of the backlash comp results, and/or the machine.xml

> running a macro script in Duet, which just performs a 25mm diagonal move, back and forth

This is not a conclusive test. To test backlash you need to position to the same position coming from two different sides (per axis), and ideally also coming with different speeds (that's exactly how the automatic calibration works, but again relying on reliable calibration fiducial recognition).

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a040bfcb-cb22-4d50-98e3-7e23877ba18cn%40googlegroups.com.

[JW]

Thanks for your feedback already Mark, machine.xml attached now - apologies!

I'll setup another test from both sides and at different speeds too, in Duet, just to be sure.

>>  Another vague possibility: if your camera (or lens) can't take the super-brutal and stiff accelerations you ball-screw guys are famos for, it might slightly tilt the view axis.

This is an interesting one... the main reason I built this 'halfway house' was to learn about the typical pitfalls before I spend the real money building a near-industrial level machine, and these little ELP cameras are top of my list for replacement with an industrial FLIR/Cognex type camera in a rigid machined enclosure. I've already seen the lens move several times having just nipped up the single lock screw finger tight, so you might be onto something with this...

>>  Note, it is almost impossible that this is a permanent machine offset. OpenPnP uses absolute coordinates. How could backlash compensation cause permanent offsets?

May you elaborate on this a little, I don't think I'm following? Why/how would backlash comp not introduce a permanent offset? Is this because the comp handles backlash by approaching from a single direction only, i.e. intentionally overshooting then re-approaching from the other side, rather than just adding/subtracting calculated values?

I'll setup the debug log and repeat later on today when I'm by the machine.

[JW]

>> Watching your videos, it should not find any backlash and propose to switch compensation off. But if the fiducial is detected wrong, all bets are off. 

Ah and yes, this! I did not know it should suggest switching it off, and it certainly didn't suggest that for me - so yes, more and more this is pointing to vision issues, as per my other thread too. I should be able to get to re-trying with a smaller fiducial in an hour or so.