Autoleveling - Automatic correction - Distortion correction

sandro730

Good evening

I am having a lot of difficulty calibrating my Delta Kossel XL

How can I disable all automatic correction functions?

This way I can be sure that I am getting the correct data.

Repetier

Yeah, that is a good tool. We have included it in V2 firmware for easy calibration.
G33 R0
resets distortion matrix to 0.
From repetier.ino

- M320 S<0/1> - Activate auto level, S1 stores it in eeprom

- M321 S<0/1> - Deactivate auto level, S1 stores it in eeprom

- M322 - Reset auto level matrix

- M323 S0/S1 enable disable distortion correction P0 = not permanent, P1 =

permanent = default

sandro730

I cannot understand an information inconsistency and or what causes the error.

Z-Probe adjusted and calibrated.

1 - I adjust the end-stops with the pole or bar procedure to bring all the trolleys to the same height.

2 - Configuration.h - #define Z_PROBE_BED_DISTANCE 30.0

3 - I position myself at a Z of 30 mm.

4 - I move to the base of column "A"

5 - I measure the distance of the plane with the G-Code G30

6 - I adjust the registers of the heated bed to bring it to 30mm

7 - I repeat for tower "B" and "C"

8 - The heated bed is parallel to the end-stops

Now if I move hotend to zero altitude at the base of towers "B" and "C" they are close to the heated bed, but when I go to the base of tower "A", hotend is higher than 0.3 0.4mm.

If, on the other hand, I carry out the same procedure bringing the hotend to 0mm and register the plane with the help of a thickness or sheet of paper, when I go to take measurements with the G30 command I get different measurements.

What am I doing wrong or not considering?

Even if I didn't have a precise mechanic I expected the same result with the two methods.

Am I using the G30 command incorrectly?

Thanks

Sandro

sandro730

I was able to calibrate the printer with wizarddelta.

Following this procedure

1 - Limit switch calibrated as documented in z-probing Delta Printer

2 - To detect the values to be entered in wizarddelta I used the probe with
the G30 command with the following code: escher3d.com_pages_wizards_wizarddelta.gcode

4 - Do point 2 3 times until I have all probe values very close.

Last result:

X 0 Y 140 Z-probe 30,029

X 121,24 Y 70 Z-probe 30,026

X 121,24 Y -70 Z-probe 30,013

X 0 Y -140 Z-probe 30,006

X -121,24 Y -70 Z-probe 30,006

X -121,24 Y 70 Z-probe 30,046

X 0 Y 70 Z-probe 29,989

X 60,62 Y -35 Z-probe 30,046

X 60,62 Y -35 Z-probe 30,063

X 0 Y 0 Z-probe 30,006

5 - Now bring the nozle to the center of the top at a height of 0.5mm.

6 - When I move the nozle to tower z the nozle goes down.

7 - When I move the nozle away from tower Z the nozle goes up.

Checking with a thickness gauge I found an error of about 0.7mm

It seems that the plane is inclined towards the Z tower,
but if I probe the plane with escher3d.com_pages_wizards_wizarddelta.gcode
i have all values in the order less than 0.1mm

What am I wrong or am I not considering?

What can I do to find out where the error is?

Why do I have an inconsistency between the real quote and the one detected by the z-probing?

Note

Do you think to make V2 firmware available also for AVR or ATMega2560 + Ramps 1.4?

Repetier

When you disable everything you should run G28 as last to be on safe side, also I think it is not a problem.
I assume all points were reachable from script.
In escher config tool you need to enter also the end stop offsets you defined in 1. When you omit this the result will be wrong.

The calibration method has it's limits. The 6 parameter version recalculates the offsets, horizontal distance and I think 2 angles. If anything else on printer is not perfectly calibrated this will always leave an error and only reduce the average error on the measured points. In fact, that is exactly what the tool does. It tries to find the the minimum square error of the distances by modifying the parameters selected. So if some of the diagonals have different length or parallel distances are not ideal you will keep getting moving errors from that. That is a result of the nonlinear delta behaviour and what makes it so hard to get a proper calibration. Most do not have the expensive equipment to physically calibrate it with highest precision.

V2 for avr is planned at least to try - if speed will be satisfying especially with the cpu intensive delta math - will be to prove then. But when I can not say. My complete day is always filled with support and programming all stuff that currently is urgent.

sandro730

Thanks for the replies.

For the V2 version I don't want to rush you I just wanted to understand if it will be implemented or not.

What I don't understand is why the probe gives me values for a parallel plane instead by checking the nozle of the hotend no.

For an error that high the nozle moving away from tower C or Z which value do I change first?

Thanks

Repetier

You mean moves to Y- direction make move up? First check if all diagonals are same length. Best is to make a grid image of z to see if it is a local or symmetric error. But it is really hard to say with local errors. Any change also changes results in other arrays. Changing +alpha(210) and -beta(330) angle would change that effect I think. When direction is wrong inverse. But also check the other areas how they change.

sandro730

Thanks I solved that error by entering this data.
330.218 - Alpha B (330)
089.782 - Alpha C (90)
I calibrated the probe in the center of the plane.
I don't understand why the probe gives me values that are discordant from the check with a feeler gauge of the hotend nozzle.

To search for a probe detection error.
Is it possible to print the values detected by the probe at each contact of each repetition ?

#define Z_PROBE_USE_MEDIAN 0/1
Mathematically what is the calculation difference between setting 0 or 1 ?

Thanks

Repetier

In console firmware writes the resulting z but not every z for repeated measurements.

Z_PROBE_USE_MEDIAN 0 -> Z is average of measured values.
1 -> Values are ordered by Z and we take the middle one. Usefull if you sometimes have a "wrong" value while normally all values are correct.