Callibration for independent tower tilts

I looked at a possibility to calibrate out tower tilts of a linear delta printer. Each tower can be tilted in any direction. I have a printer with deviation of about 0.8° from the ideal perpendicular direction. That is quite a lot.

I also calibrated (micro)step length. This may be useful if belts are not tightened the same. Though it is more likely to diverge.

The good news is that it does not seem hard to to. And the calibration procedure identified the tower tilt about right.

The bad news is that it does not seem to help as much as I hoped. Well, this may have been expected since it has rather long diagonal rods and small build plate. Because of that a simple endstop adjustments can compensate the most of the errors (with a bad consequence of getting skewed prints). Also step length calibration probably drifted a bit.

Here is the expected position error (there is no direction in the error - can be in X/Y/Z direction to any degree) after calibrating everything but the diagonal rod lengths.

It seems rather random - probably errors in the z-probe data.

Here is the comparison of how position error changes with the selection of different calibration parameters. This shows the disappointing part.


I'll. probably return to it when I get shorter rods ... or I get bored.

Can you share your method please? I have some errors in my printer that I suspect might be caused by tower tilt, but I'm not sure.

How do you know that the measured error is due to tower tilt? And then how do you input the tilt into (e.g.) Repetier to correct it?

FWIW, I have a Java app which uses a genetic algorithm to minimise delta errors. So far it only uses tower angles, diagonal rod length, and endstop distances. However, I'm keen to add other variables. Especially if they can be fed back to the firmware to improve its positioning.

Quote
frankvdh
Can you share your method please? I have some errors in my printer that I suspect might be caused by tower tilt, but I'm not sure.

[github.com]
The general approach is the same as I published in 2013.

Quote
frankvdh
How do you know that the measured error is due to tower tilt?

Because the maxima notebook shows bigger errors when the calibration does not compensate for the tilt. Also I know that the towers are not perfectly perpendicular (nor equidistant).

You can simulate the tilt errors using the calibration maxima notebook.

• Fill in all the probe data [(itas, itbs, itcs)] from a precise printer (i.e. from a mathematical model of a linear delta printer which does not have any errors).
• Fix all the calibration parameters to values which contain some tilt.
• Let the notebook show you the impact on the hotend position error.

Quote
frankvdh
And then how do you input the tilt into (e.g.) Repetier to correct it?

AFAIK, the current Repeteir does not support compensation for tilted towers. I use repetier with a small custom patch to print (itas,itbs,itcs) triple when Z-probing. Tower tilt support can be easily added but I did not do it yet. I'll probably do it ... maybe by the end of this year ... though I'm not sure I'll keep the stupid way how repetier defines tower positions. The polar coordinates are pain in ....

You do not need a working 3d printer with support for tilted towers to simulate how hotend position improves after support for tilted towers would be added. See the notebook for details.

Quote
frankvdh
FWIW, I have a Java app which uses a genetic algorithm to minimise delta errors. So far it only uses tower angles, diagonal rod length, and endstop distances. However, I'm keen to add other variables. Especially if they can be fed back to the firmware to improve its positioning.

Genetic algorithm sounds like a time consuming way to solve this. Why using essentially a random search to optimize the fitness function when you can use gradient directed search. I used minpack library for that but only because it is built in maxima. There are better packages for this now.

Edited 1 time(s). Last edit at 08/26/2018 04:52AM by hercek.

Another probing data set from the same printer.
It seems that the error distribution is partially random:


This already done on a printer with an alpha tower tilt support.

You sure it is tower tilt causing the "random" like errors, looks a little more like it might be unevenness in the rail surface or the need for a little more preload on the bearings, although looks like tower tilt had the biggest impact on accuracy for you

Yes, tower tilt optimization helps most (after endstop and tower position optimization). But notice it is not much. Only about 1 microstep per probing point. That is negligible.

The surface is glass. It is flat.

The random like errors may be caused by backslash. The point is that there were about 270 probing points and they were tested in random order. Each next point was selected randomly from the set of all points which were not probed yet. I do not see other reason for the errors than backslash ... for now.

The current status:

• backslash errors may screw it up despite the abundance of probing points to average the errors out
• identification of tower tilts is not stable enough over multiple data sets (possibly because of the backslash ... or maybe long arms)
• if the towers are almost perpendicular (error less than ±0.5°) and arms are long (min angle around 30°) then the optimization for tower tilts does not help much
• I have some bug somewhere (probably in firmware) which causes it the firmware result to conflict with the match in wxmaxima notebook when tower tilts are set to non zero values in firmware configuration; I have to review all the math (especially in firmware) again to be able to continue and to come to new conclusions

OK, the Repetier branch which properly compensates for independently tilted towers if available here (the branch is named towerTilt):
[github.com]
Only the 8-bit ArduinoAVR tree is patched with tower tilt support. It is probably easy to port it to a ArduinoDUE tree but I do not have any ready hardware to do it and test it. So it is up to somebody else to do. If you have some tower tilted in a different direction than other towers then feel free give it a try. It will work fine if you can measure and enter the tower tilts manually(*). It adds only very little overhead for each segment in the integer branch (something like 3 multiplies, 2 shifts and 2 additions for each tower). It should be completely negligible among all the other things.

(*) towerTilt.wxm script will help you to convert tilts in the radial/diagonal direction (which are easy to measure on a delta) to the tilts in X/Y direction which are needed by firmware.

Notice that the branch changes meaning of "Z max length" from height of hotend over bed to height of a carriage over bed when the printer is homed.

The branch also adds a 2D matrix for YX coordinate scaling. It may happen that your XY dimensions are wrong after a numerical bed levelling. The common reasons are:

• incorrect step length,
• incorrect diagonal rod length and delta diameter compensating for it,
• slight rotations of the platform holding hotend (e.g. because of rotated tower or diagonal rods not having the same length - e.g. my test printer has them in the range of 0.4° peak-to-peak).

You can use the added repetier feature XY-scaling to partially compensate for this. The compensation will not be perfect because the scaling error is not linear. You can use xyScaling.wxm to find the best calibration parameters.

All the calibration related scripts are available here:
[github.com]

The calibration results:

• identification of tower positions and endstop offsets is working reliably as it was in the past with the numerical calibration approach
• identification of tower tilts is not stable on the printer I tested it with; the probable reason is too much noise in the measurement data .... probably because of backslash
• calibration of microstep length was never tried because Repetier does not support it at all by any chance and adding it is a lot of work

Notice that you can use the calibration.wxm script (possibly together with perfectProbing.wxm) to see how different kinds of errors would influence the bed levelling ... and how the other calibration parameters can compensate for it. That leads to all kinds of funky geometric errors in the printed parts, of course.

Here is an example of a tilted tower C in the positive Y axe direction by 0.53°. That is quite a lot (my test printer has tilt errors in the range of 0.3° and smaller). The other towers in this sample chart are perfectly perpendicular to bed.


Notice that the rather big tower tilt error can be quite well compensated for by adjusting tower positions and endstop offsets. But it is clearly not perfect. There are errors in the range of 2-7 microsteps.The problem is that the probing errors from my test printer are in the range of 2-6 microsteps as well. Here are some real probing data from the printer (ignore the probe height average offset of around 14.3 mm):


The result: I'm not surprised I cannot reliably identify tower tilts of this printer using the numerical method in calibration.wxm. With a precise enough printer (very little backslash) it should work enough to be useful since the tower tilt error shape is not well compensated by other calibration parameters. I think the signal is swamped in the noise in my case and the optimization finds wrong local attractors.

I tried to filter the probing data over multiple runs as well as a gausian 2D filter in the XY plane to check whether tower tilts can be identified better when the measurement errors are averaged out a bit. It did not lead to any significant improvement in tower tilt identification. But I managed to hit some maxima errors and I found a beast from Space Invaders hidden in the rounding data

So the recommendation stays the same. If you think you have tilted towers then measure it(*), put the measured values in the firmware configuration and the calibration notebook and calibrate tower positions and the end-stop offsets. Callibration of these parameters is stable and works like a charm

(*) One can measure this quite well by measuring the gap between a rectangular triangle and a bed/tower. I measured this in the diagonal and radial directions and converted it to tilts in the direction of X and Y axe. Those can be directly entered in the firmware.