Bed not leveled despite using CR-Touch

Basic Information:

Printer Model: Anycubic Chiron
MCU / Printerboard: Big Tree Tech GTR
klippy.log (766.9 KB)

Describe your issue:

I have been having trouble levelling my printer and have not been able to find a solution. I am running an Anycubic Chiron, which has been upgraded with a Micro Swiss NG as well as a CR Touch. It is also running 2209s with sensorless homing on x and y and stock optical z endstops on both axes’. I have set the probe offsets. My issue is that despite probing my bed and loading the mesh, it seems as though some areas are too far away from the nozzle and some are too close. I am not sure what is causing this.

I have attached a photo of my bed mesh; it is an older photo but still shows the shape. I currently have a 9,9 matrix, but it made no difference. Also attached is a photo demonstrating what happens when I try to print. You can notice on the right that the nozzle seems closer to the bed than on the left. Keep in mind that the rest of my print turns out okay. It is just an issue with the first layer.

Would anyone have some suggestions for what the issue could be? Could it be that a Z stepper is losing steps? Twisted x-axis? Is there any way for me to tell? It’s bizarre. Perhaps I just missed something. I have also not set up anything relating to Z tilt. My config is in the drive link.

If you have any pointers, I would appreciate it!



Looking at you klippy.log I don’t see any START_PRINT macro, any BED_MESH_CALIBRATE or load BED_MESH_PROFILE. The mesh isn’t load automatically. You should do a BED_MESH_CALIBRATE or load a mesh in the start printing sequence.

You don’t need a START_PRINT macro if you do that stuff in the slicer.

According the log, the bed mesh is performed:

probe at 47.000,11.000 is z=-0.635000
Stats 31191.7: gcodein=0  mcu: mcu_awake=0.004 mcu_task_avg=0.000009 mcu_task_stddev=0.000011 bytes_write=154807 bytes_read=295950 bytes_retransmit=9 bytes_invalid=0 send_seq=9815 receive_seq=9814 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168000162  heater_bed: target=50 temp=50.8 pwm=0.102 mcu_temp: temp=34.1 sysload=0.18 cputime=818.286 memavail=718064 print_time=1005.138 buffer_time=0.000 print_stall=0 extruder: target=0 temp=83.8 pwm=0.000
probe at 47.000,11.000 is z=-0.635000
Stats 31192.7: gcodein=0  mcu: mcu_awake=0.004 mcu_task_avg=0.000009 mcu_task_stddev=0.000011 bytes_write=155762 bytes_read=296607 bytes_retransmit=9 bytes_invalid=0 send_seq=9856 receive_seq=9856 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168000154  heater_bed: target=50 temp=50.7 pwm=0.208 mcu_temp: temp=34.0 sysload=0.18 cputime=818.356 memavail=718316 print_time=1006.194 buffer_time=0.000 print_stall=0 extruder: target=0 temp=83.6 pwm=0.000
probe at 47.000,11.000 is z=-0.632500

Hi guys, thank you very much for the reply.

When I start a print, (and remember to do it), I will load the bed mesh manually with the button in mainsail. I will know it hasn’t been loaded properly because the hotend will be printing in mid air. It might be beneficial to add the mesh to my gcode to save the risk of forgetting it. If this is the incorrect way of doing it, that might be influencing my problem.

I believe that klippy.log just contains a bed mesh probing and nothing else. I can send one of me probing, saving and then printing if you wish.

I have a spare z + x axis gantry for the machine, basically the top half. I could swap it over to see if there is a difference. Perhaps something is bent or warped.

Thank you again


Try Axis Twist Compensation - Klipper documentation
If this yields an improvement, then most likely you have some mechanical issues with the axes.

Thank you very much. I will try this and report back with results.

Good evening,

X twist had no effect, so tonight I replaced the gantry. Immediately after my first probe, I had this result.
This is certainly different than before. But could be chalked up to the endstops not being in the same place as previous. After leveling quickly adjusting the screws as well as disabling x axis compensation, I was left with this result.
This yielded a first layer that looked like this.

Weather or not this is an improvement, is hard for me to tell. Perhaps I need to do a larger mesh.

Thank you again for the help guys!


Hi again, this problem seems to still be showing in my machine. I really am not sure what’s causing it. Even with x axis compensation it still comes through. Would it make sense that it could be the rollers? Would squaring have an effect? I’m not sure. Thanks for reading!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.