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

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. 


Comments

  • 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.
  • 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. 
  • 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.
  • 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. 


  • That should reset to defaults, yes.
  • 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.   
  • 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.
  • 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. 
  • 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.
  • Thank you!
  • 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. 
  • 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.
Sign In or Register to comment.