First layer height changes along X axis when autobedleveling enabled. G32 & G33 in starting script

good_idea

Liebe Kollegen,
first of all thank you for brilliant software and support.
1/ Problem:
When printing first layer line along X axis with height 0.2 mm its height on the left side of the bed is 0.3 and gradually changes to 0.15 on the right side of the bed. It is reproducible at any Y position of the table.
I use Cartesian printer with prusa-like kinematics and 8-bit MKS Gen-2Z board. Table is mirror. Z probe is metal stift + optical sensor with measurement repeat-ability 0.007 mm. Distance between X-rods and Y rods is equal on left and right.
Filament diameter is constant, 1.75. Extrusion rate is constant: while the layer height becomes lower the width of layer increases.
Autobedleveling is enabled. It measures 9 points. It works fine: if I intentionally make bed tilt the first layer is still accurate with the same height difference on left and right sides of table.
I thought that autobedleveling compensates everything but not the changes in z_probe_height. So may be the carriage rotates around Z axis because of luft and z_probe_height changes? Have checked that, there is no luft, everything is tight.
Any ideas? Could autobedleveling calculate the wrong rotation matrix?

2/ I try to workaround the problem using the distortion matrix. What would be the correct sequence in the starting script:
G28 ; homing all axes
G32 S1 ; autobedleveling with grid
G33 ; create distortion matrix
P.S. I don't store distortion matrix in eeprom because I change mirrors on which I print.

Thank you again.

Repetier

Distortion matrix is always stored in eeprom, or you need to disable that in config and redo before using.

There is also a feature called bending correction. It spans a correction defined at the 3 points you define and adds that correction to measured points. Maybe it is set to non 0 or if it is you could use it to compensate the error.

The bed is computed by autoregression building best plane by minimizing squared distance of measured points. For measurements of 3 points it will exactly hit the points, for more it reduces average error. I think the math is correct as it also follows changes, just like you already tested. It sound more like a systemic error. Is that the bed with th e9 measurement points? As fas as I know these need to be hit exactly as the original tries to find peaks to adjust position errors as well. So measuing 1mm more right would give you a different height then.

good_idea

Thank you for explanations. What would be the correct starting script for the following conditions:
- i change the mirrors i print on before each print, so they could have different distortions, so i need to reset old and create new distortion table before each print and i don't mind wearing off Z axis leads
- i use bed_leveling method 1 (grid)
- i use bed correction method 0 (rotation matrix) and need to delete old andcreate new matrix before each print

Does this sound logisch:

G28 ; homing all axes
M322 S1 ; reset autolevel matrix in EEPROM
G33 R0 ; reset bump map
M323 S1 ; enable distortion correction
G33 ; create distortion matrix
M320 ; activate auto level temporarily
G32 S1 ; autobedlevel with grid

Thank you.

Repetier

No, first if you do it for every print to not save changes in eeprom. Just wears out number of changes possible in eeprom.

Then G33 MUSt be after G32 as the distortion corrections get added to rotation. So
G28
G32
G33

Is all you need.

good_idea

So, if I don't know what data in autolevel matrix and distortion matrix are stored in EEPROM now it would be good to reset them once:
M322 S1 ; reset autolevel matrix in EEPROM
G33 R0 ; reset bump map
Is it true?
Thank you.

Repetier

That should reset to defaults, yes.

good_idea

Liebe Kollegen,
thank you for answers. Introducing G33 command did not make any difference on first layer height. It is still 0.3 on left side of the table and 0.15 on the right. Nozzle does not follow the curvature of the glass.
I did check the z_probe_height: it is 0.1 mm bigger on the left side of the table than if I check it on the right. I can't imagine what produces this difference on prusa-like kinematics.
The bending correction feature did help. It is a nice workaround, but for perfectionist like me it is still annoying to know there is an issue in the printer you don't understand. Thank you again.

Repetier

Some beds distort when hot or are already distorted when being cold. Some printers bend down to the center from the weight, especially if head is heavy and linear guide flexible. Head can also rotate a bit. There are quite a lot of possible reasons for changing height over cordinates.

good_idea

Thank you. One more question on this topic. There is an Octoprint plugin called "BedLevelVisualizer".
https://github.com/jneilliii/OctoPrint-BedLevelVisualizer
It uses the code below to get the table of the bed heights and to make a graphical representation of the distortion:

G28

M155 S30

G29 T

M155 S3
As I understood from GCODE Wiki G29 T does not produce the needed for this plugin table. In Repetier firmware it only measures three points. Which GCODE could be used to get the needed table (link is above)?
Thank you.

Repetier

This is only a marlin compatible visualizer. In Repetier-Host there is a similar function bed height map that you can use for our firmware. You can connect it to our server running on a pi if you can not connect to windows directly.

good_idea

Thank you!

good_idea

I am glad to report that BedLevelVisualizer Octoprint plugin now supports Repetier firmware.
I just want to report that my working gcode is as following:
G28
M155 S30
G32
@BEDLEVELVISUALIZER ; this line may not be needed, I don't know
G1 X0 Y0
G33
M155 S3
If there is no line "G1 X0 Y0" before G33 than at the end of G32 command firmware "thinks" that Z-probe is at the X0 Y0 position (but it is not) and executing G33 with move the Z-probe out of printing area. And here firmware reports an error. Because of this lets move the Z-probe to real X0 Y0 position before G33 and everything will be fine.

Repetier

I don't think firmware doe snot know where it is, host will not know. More likely is that activation at that point is not possible at that point so move helps here to get to a working position.