Feature/Better Backlash Compensation

[markmaker]

Description

What is it?

Backlash compensation is used to avoid the effects of any looseness or play in the mechanical linkages of the given axis. When the actuator reverses the direction of travel, there is often a moment where nothing happens, because the slack from a belt or play from a screw or rack and pinion etc. needs to be bridged, before mechanical force can again be transmitted.

What has changed?

Backlash Compensation was removed from the GcodeDriver. All drivers can now use it. The actual Backlash Compensation is now performed by the MotionPlanner, all compensatory moves are now normal driver moves.

The settings are per Axis:

Everything is migrated automatically.

WARNING: Early adopters of the testing version will not have full auto-migration (unless they perform a fresh migration, of course). They need to check their settings on the axes.

Features

There is a the new BacklashCompensationMethod you can select.

• None: No backlash compensation is performed.
• OneSidedPositioning: Backlash compensation is applied by always moving to the end position from one side. The backlash offset does not need to be very precise, i.e. it can be larger than the actual backlash and the machine will still end up in the correct precise position. The machine always needs to perform an extra move. This is equivalent to the former GcodeDriver Backlash Compensation.
• OneSidedOptimizedPositioning: Works like OneSidedPositioning except it will only perform an extra move when moving from the wrong side. Only half of the extra moves are needed.
• DirectionalCompensation (Experimental!): Backlash compensation is applied in the direction of travel. Half of the offset is added to the actual target location. No extra moves are needed. The machine can also move more fluidly, as there is no direction change inserted. Try jogging very quickly!

Despite being somewhat independent as a feature, it is designed on top of #1042. I.e. this is the next version for testing.

Justification

1. Can now be used with all Drivers.
2. New Backlash Compensation Methods can eliminate half or even all extra moves.
3. Even before jerk control can be applied, DirectionalCompensation eliminates much of the vibration problem in iterative drill-down Vision.
4. Setup of MOVE_TO_COMMAND becomes so much easier.

Instructions for Use

For the Axis setup see above and here:

The GcodeDriver will display error messages as long as you still have old Backlash Variables in your MOVE_TO_COMMAND:

You now need to create a simple one-line command (the following is valid for enabled Letter Variables mode with 5 axes, see #1035):

{Acceleration:M204 S%.0f} G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {A:A%.4f} {B:B%.4f} {FeedRate:F%.0f} ; move to given location

If you want to use the new DirectionalCompensation (Experimental!), you need to set up your Backlash Offset very accurately. This is different from the other methods that will always be accurate in the end, even if the Backlash Offset is too large.

Guide to tune it for the X or Y axis:

1. Set the DirectionalCompensation method. Set Backlash Offset 0.0. Apply.
2. Go to a well-defined sharp feature in the down-looking camera (millimeter paper or small fiducial).
3. Zoom the down-looking camera strongly (mouse wheel), until you can see the slightest movement.
4. Jog with 0.01mm into one direction in multiple steps but slowly. Note the characteristics of how the machine advances one step.
5. But note that some machines will not always step, e.g. my machine has 80 microsteps/mm so it will step 4 out of 5 times.
6. Make sure the last Jog was a true machine step.
7. Now change the direction and do one step.
8. Observe if the machine moves with the same characteristics.
9. If it moves not at all or less, increase the Backlash Offset say by 0.05mm. Apply.
10. Then repeat and try to drill down onto the right Backlash Offset, until the first reverse move appears to step with the same characteristics.
11. Don't overdo it. Good is good enough.
12. Try it with Visual Homing and Nozzle tip calibration. Observe how precise it was homed/calibrated.

Obviously this guide won't work for Z or rotation axes. You could try the rotation axis in the bottom Camera, with a large IC on the nozzle. And backlash compensation on the Z axis is not needed IMHO.

Implementation Details

1. Tested both in simulation and on real machine with unexpectedly.
2. Did follow the coding style.
3. No changes in the org.openpnp.spi or org.openpnp.model packages.
4. Succesfully ran mvn test before submitting the Pull Request.

[ian-arkver]

This PR seems to include the 3 commits which were in #1042 and are already merged.

[markmaker]

This PR seems to include the 3 commits which were in #1042 and are already merged.

Yeah, I don't know why git does it. All I did was merge the test branch back to my feature branch. Maybe because it was squashed.

I have given trying to understand git. I always just look at diffs.

_Mark

[ian-arkver]

Hi Mark,

Once you've pulled the merged stuff and updated your fork's test branch, you need to rebase your feature branch onto the updated source branch (test).

If your feature branch is set to track the test branch you can maybe just pull --rebase. If not you may need to tell git to rebase your patches onto the new test branch using git rebase (perhaps with --onto). Generally though it's simpler to tell git that your branch should track Jason's test branch (you can use git branch -u to set this) and then git pull --rebase.

There's some good info on rebasing in the Git book here.

All the best,
Ian