Hi David, I've been away from the printer for quite some time now. As soon as I find some time I'll look at your config. In the meantime, could you explain again what is your issue? I thought it was about the X-offset and not about the servo position.

Had the same issue. I remember I tried to fix the Klipper config. I don't remember if it worked :-) Pretty busy these days... I'll post back when I have a chance to restart using the printer.

Hi Dries, I finally found some spare time to draw the scheme about the BED_MESH_OFFSET. Please keep in mind this rational only applies to a bent/curved X axis. For the Y axis there is no need for correction because everything is aligned. For a curved bed, there is no need for correction either. When both the X axis and the bed are curved, I don't think this technique will work. Feel free to let me know if you have questions or to challenge my rational.

Hi Douglas, Good to know you have better results now. Did you try the Z_TILT_ADJUST to compare to your previous results? Also, my printer is pretty good in the center area but is not as good in the corners. Are you still using a bed mesh? Did you try a similar test in the corners? In case you don't know, Cura Calibration Shapes plugin has a good test called "Bed Level Calibration" . See https://marketplace.ultimaker.com/app/cura/plugins/5axes/CalibrationShapes. Essentially, it will print 9 small 1-layer squares over the whole bed surface.

Hi Dries, Sure, no problem :-) I've been pretty busy those days with my work. No much time for printers. I'll try to get something until Sunday. Best

Hi, My understanding and observations are the following: 1) It will use all of the 4 z stepper motors to level the bed 2) In my case, the adjustment is persistent as long as the steppers are not turned off. After I shutdown the printer for some days, the next time I perform the z-tilt, I usually get a larger difference to correct. Therefore I also added a Z_TITL_ADJUST in my start g-code :-) 3) Here is a typical output I get on the console: 8:14 PM Retries: 0/2 Probed points range: 0.015833 tolerance: 0.050000 8:14 PM Making the following Z adjustments: stepper_z = 0.065298 stepper_z1 = 0.057394 stepper_z2 = 0.038401 stepper_z3 = 0.046304 8:14 PM probe at 230.000,3.000 is z=1.871039 8:14 PM probe at 230.000,3.000 is z=1.871039 8:14 PM probe at 230.000,3.000 is z=1.871039 8:14 PM probe at 230.000,248.000 is z=1.863539 8:14 PM probe at 230.000,248.000 is z=1.863539 8:13 PM probe at 230.000,248.000 is z=1.863539 8:13 PM probe at -10.000,248.000 is z=1.876039 8:13 PM probe at -10.000,248.000 is z=1.876039 8:13 PM probe at -10.000,248.000 is z=1.876039 8:13 PM probe at -10.000,3.000 is z=1.878539 8:13 PM probe at -10.000,3.000 is z=1.878539 8:13 PM probe at -10.000,3.000 is z=1.881039 8:13 PM Z_TILT_ADJUST Best Regards

Hi Peter, The PROBE_OSSFET is enough for T0. With this instruction, Klipper always knows where the T0 tool is. The SET_GCODE_OFFSET is required to account for the distance between T0 and T1. Now the BED_MESH_OFFSET is a bit more complex in the case of the DSH and bent linear rails, which I believe is my case. It should not be required for straight and at square axes. For bent axes, this command is needed because the x coordinate of T0, T1, the probe and the attachment of the DSH to the X linear rail are all different. Therefore, when the probe measures difference in z-height during bed-mesh, it is mainly due to the linear rail and not to the bed (in my case). As such, you need to also compensate for the distance between the tool and the DSH attachment point. I'll try to draw a scheme... but I'm very bad at drawing :-)

Hi Peterg, Having the STAR_PRINT and END_PRINT in the slicer is perfectly fine. My personal preference is to have all my G-Code in one place (e.g start, end, T0/T1, ...). It gives me a better overview of the different G-Codes and I can use the Klipper Jinja2 scripting feature. It's also more generic, although not fully, in case you want to switch slicer. Moreover, it's stored on the rpi which goes along with the printer as opposite to be stored on a computer. As a benefit, I can easily use different computers, even different printers. All I need to have is the same very simple START/END G-CODE in Cura or another slicer. Hope that clarifies why I recommended this. In the end, it's about your own preference and needs.

The Klipper bed-mesh feature should compensate for bed imperfections provided that: the X and Y linear rails are not bent and are in the same plan; and the mesh-model has a sufficient resolution the mesh-model is predictive of the actual bed surface (Probed versus Mesh in Mainsail) In case both the bed and the linear rails are faulty, I don't think the bed-mesh feature will work properly. In my case, the MIC-6 bed is not perfect but good enough. However, I strongly suspect my linear rails to be bent. Therefore I have to use the BED_MESH_OFFSET command in the T0/T1 macro.

Hi Douglas, Did you try to use the bed-mesh with the offset compensation? Check my T0/T1 macros below. [gcode_macro T0] gcode: {% set svv = printer.save_variables.variables %} # Set svv to point to variable.cfg ARM_POSITION A={svv.left_ang} # Switch to T0 {% if "xyz" in printer.toolhead.homed_axes %} G0 F5000 # Set speed SET_GCODE_OFFSET X=0 Y=0 Z=0 MOVE=0 # Account for different X, Y and Z offset BED_MESH_OFFSET X=12 # (+12 + 0) Account for offset from linear rail fixture to probe due to bended gantry {% endif %} ACTIVATE_EXTRUDER EXTRUDER=extruder G4 P2500 [gcode_macro T1] gcode: {% set svv = printer.save_variables.variables %} # Set svv to point to variable.cfg ARM_POSITION A={svv.right_ang} # Switch to T1 {% if "xyz" in printer.toolhead.homed_axes %} G0 F5000 # Set speed SET_GCODE_OFFSET X={svv.x_off} Y={svv.y_off} Z={svv.z_off} MOVE=0 # Account for different X, Y and Z offset BED_MESH_OFFSET X=24.5 # (-15 + 39.5) Account for offset from linear rail fixture to probe due to bended gantry {% endif %} ACTIVATE_EXTRUDER EXTRUDER=extruder1 G4 P2500 The BED_MESH_OFFSET command is there to use the correct bed-mesh compensation as the probe, the hot end and the attachment point to the X carriage have different coordinate. Please note that for the compensation for work, the printer has to be homed before the T1 macro is called.

I have pi 4 with 8gb, heatsinks and no active cooling. I do not experience the slowdown you are describing. On Mainsail you can monitor the pi cpu usage. That should give you an indication. Also, could it be a faulty ribbon cable? These cables tend to be unreliable at least in my experience.

The data is saved to the end of the printer.cfg file with the name you gave when starting the bed mesh calibration. The calibration will not be lost. However, the latest version of Klipper is not automatically loading the 'default' bed mesh anymore. You would need to load it before starting a print or add a macro in your printer.cfg to load it automatically. I only run it once for a defined temperature or when I remove the flexible print plate. Yes, it should compensate for it, IF the observed curvature is effectively due to the bed and not the linear rails. Another limitation would be if you have a very sudden change in the z height on the bed, like a deep scratch.

Hi Douglas, Thanks for providing the bed mesh. IMO, it looks too much bent compared to what was advertised for the MIC-6 bed... The washers you are proposing seems to make a lot of sense to me even if I'm really not an expert in mechanics. How do you know the observed curvature is due to the bed and not to the linear rails? In my case, I suspected the linear rails because the automated bed mesh compensation Klipper provides was not making the correct adjustments. I could identify some systematic offset between the mesh model and what I could observe from the hot end and the bed. That offset was also different between T0 and T1. Looking forward to know if the washers can improve the situation.

Hi Robin, Can you provide the output of the following commands from the putty terminal? lsusb and dmesg | grep usb The idea is to check if the SKR 2 board is being detected by the Raspberry pi. Also, maybe the 1st thing to try is to change the usb cable from the pi to the printer mainboard. Note that both the pi and the printer board have to be powered.

Hi David, Not related to the DSH not switching at the beginning of the print, but I see that your macros T0 and T1 contains some hard-coded values for ARM_POSITION and SET_GCODE_OFFSET. This is overriding the values defined in the variables.cfg file. For the issue described in this post, I don't see anything from the T0/T1 macros. Could you check that the g-code file generated contains a T0 instruction at the beginning? For example, this is what I get from Cura sliced models: ;Generated with Cura_SteamEngine 5.2.1 T0 M82 ;absolute extrusion mode START_PRINT EXTRUDER_TEMP=210 BED_TEMP=60 LAYER_HEIGHT_0=0.2 Also, I would recommend to have a START_PRINT macro instead of having the start G-Code in the slicer. This is how mine looks like: [gcode_macro START_PRINT] gcode: {% set BED_TEMP = params.BED_TEMP|default(60)|float %} {% set EXTRUDER_TEMP = params.EXTRUDER_TEMP|default(200)|float %} #This is only for setting the temp of the extruder that is going to be used first. Cura will warm up the other extruder while the first one works. {% set LAYER_HEIGHT_0 = params.LAYER_HEIGHT_0|default(0.3)|float %} M140 S{BED_TEMP} ;Start bed heating M190 S{BED_TEMP}; wait for bed to reach the temperature G28 ;Home Z_TILT_ADJUST M104 S150; Start heating the hot-end to a safe temperature G28 ;Home G90; absolute coordinate G1 X20 Y-5 Z5 F3000; move to bottom left corner for priming M109 S{EXTRUDER_TEMP}; Wait for hot-end to reach the initial temperature M82 ;absolute extrusion mode G92 E0 ;Zero Extruder G1 F200 E30 ;extrude some material (+30mm) G92 E0 ;Zero Extruder again G1 Z{LAYER_HEIGHT_0} ;Move to first layer height. The extrude filament will get wiped with the next move G1 Y5 F1500 And then my START G-CODE in Cura START_PRINT EXTRUDER_TEMP={material_print_temperature_layer_0} BED_TEMP={material_bed_temperature_layer_0} LAYER_HEIGHT_0={layer_height_0} And my END G-CODE END_PRINT Let me know if that helps or if you have questions.

Could you share your T0/T1 macros. Assuming you are using Klipper. Alternatively you could share your T0/T1 code from your slicer.

That is wired... setting the variables in variables.cfg should do the trick. Did you restart Klipper after making the change in the file? Also, make sure you have a SET_GCODE_OFFSET X=0 Y=0 Z=0 MOVE=0 in the T0 macro and SET_GCODE_OFFSET X={svv.x_off} Y={svv.y_off} Z={svv.z_off} MOVE=0 in your T1 macro.

Can't help much. Definitely too slow. Could it be linked to the rpi you are using? Could it overheat and throttle?

Hi Douglas, To activate the bed mesh option, you need to add a section in printer.cfg and restart klipper. See below: [bed_mesh] mesh_min: 16.5, 25 mesh_max: 289.5, 292 algorithm: bicubic probe_count: 10, 5 mesh_pps: 3, 3 fade_start: 1 fade_end: 10 fade_target: 0 horizontal_move_z: 5 Documentation can be found here: https://www.klipper3d.org/Bed_Mesh.html Then you should get a new menu available in Mainsail called Heightmap. With the system homed, heat the plate to an average temperature, say 60°C, and click on Calibrate once the temperature is stabilized. Once the bed mesh is completed, you should get a 3D view as in point (3) and some statistics as shown in (4). When a bed mesh is loaded, Klipper will use this information to adjust the z height on the first few layers (fade_start, fade_end ). In theory this allows for a close to perfect first layer. However, the assumption is your gantry is perfectly flat and at 90° in both X/Y axis. In that case, the obtain map is reflecting the curvature/imperfections of the bed. You could also have bent X/Y axis (linear rails), which would result in a similar map. This would work as well with a single extruder. With the DSH, because there is an offset between the position of the nozzles and the position to where the DSH attach to the X axis, one would need to use the BED_MESH_OFFSET Klipper command to account for this offset on tool change. In my case, I have the feeling the above bed mesh is the result of bent X/Y axis during the transport, while the MIC-6 bed is actually very flat. Therefore I would be curious to know what you guys get for a bed mesh.

Congratulations! I would be keen to see a bed mesh of your setup. Do you think you could post one in the coming days?