Bed Mesh not working during printing

[drewp29]

X-Max 3 Firmware 4.3.10 OrcaSlicer default X-max 3 profiles

I am using the older firmware because the newest 4.3.13 firmware does not work for my particular printer. The Z offset does not save correctly with the 4.3.13 firmware. I would set the Z offset value, run a print that would be fine, set up a second print, and the Z offset would be obviously high with horrible first layer adhesion. Setting the Z offset only affected the following print, so I was having to set the offset before every single print. I rolled back to 4.3.10, which is the previous version available on Google Drive, and the Z offset works correctly every print.

Now for the issue from the title. The bed mesh is not being utilized at all for compensation of the build plate variance. I have manually leveled my bed and the variance in the mesh in Fluidd is 0.1625mm, which should be easily handled by Klipper. I was having issues prior to really dialing in the variance with one corner of the build plate not having any squish during the first layer. This corner was the lowest according to the bed mesh, but my variance at the time was still only 0.4485mm, which should not pose a problem if the printer corrected for the variance the way it is supposed to. By dialing in the bed variance, I get a solid first layer in that corner, but it still shows signs of inadequate squish since it is still the lowest corner on the build plate. Additionally, the high areas as shown in the Fluidd bed mesh show signs of too much squish, but it is necessary to have a little too much in those areas in order to get a solid first layer in the low corner.

This has led me to determine that the bed mesh variance compensation is not happening at all. It does not work, whether or not you run the adaptive meshing prior to the print. This has been confirmed by several of us on the Facebook group.

Please look into this issue.

[CChen616]

I'm not sure what you mean by "dialing in the bed variance." I assume you are manually adjusting a bed mesh profile, such as the default one in the printer.cfg showed below, and then restarting and applying that profile.

#*# [bed_mesh default]
#*# version = 1
#*# points =
#*#       -0.121303, -0.175157, -0.186459, -0.148855, -0.090626, 0.072134
#*#       -0.144116, -0.208022, -0.224116, -0.204324, -0.155157, -0.009897
#*#       -0.139741, -0.200105, -0.238074, -0.230470, -0.192084, -0.095105
#*#       -0.048907, -0.137605, -0.169636, -0.176511, -0.160261, -0.081772
#*#       -0.075418, -0.149480, -0.205261, -0.212970, -0.197032, -0.128126
#*#       -0.116668, -0.189376, -0.253491, -0.281251, -0.263647, -0.176928
#*# tension = 0.2
#*# min_x = 20.0
#*# algo = bicubic
#*# y_count = 6
#*# mesh_y_pps = 2
#*# min_y = 15.0
#*# x_count = 6
#*# max_y = 230.0
#*# mesh_x_pps = 2
#*# max_x = 230.0

If so, the bed mesh is actually being utilized. Rather than the mesh not loading, it sounds more like an incorrect mesh generation. This can be caused by a variety of factors. For example, deviations due to the drag from the wires above as the extruder moves to different corners; discrepancies between the position of the inductive sensor used for probing and the nozzle, leading to inaccuracies in detection when the heated bed is at an angle, etc. Typically, these errors are very small, but when several factors accumulate, they could create a significant deviation.

The above analysis is based on mechanical aspects. For any firmware errors, please follow the Klipper official documentation to load and remove the respective bed mesh profile after leveling to observe whether the bed mesh has been loaded correctly. https://www.klipper3d.org/Bed_Mesh.html?h=bed_mesh_profile+remove%3Ddefault#profiles

[drewp29]

Yes, you are correct regarding "dialing in" the bed mesh variance - I did this manually by turning the bed screws. I ran the bed mesh calibration, but I was having issues in the back right corner of the bed with line separation, yielding a solid layer everywhere except that back right corner.

I have since done the following to ensure that it is not filament drag keeping the extruder from producing the correct amount of plastic from the nozzle:

Replaced the PTFE tubing from the filament runout sensor to the extruder with Creality Capricorn XS ultra low friction tubing.

Printed an angled riser for the lid that has a slot to pass the new Capricorn XS tubing. The PTFE tube does not have any extreme bends at any head position. The tube enters at the rear above the back of the printer and is free to move with the print head.

Replaced the filament runout sensor with a BTT SFS V2.0 sensor. I did not think the stock runout sensor had much drag when pulling filament through, but a few people on the Facebook group said they thought the sensor was a significant source of drag. The SFS V2.0 also allows for reporting of filament clogs in addition to the runout sensor, so I will leave it in place.

After reducing filament drag at every source through these methods, the back right corner of the build plate is still not getting adequate squish. Reducing the mesh variance as reported in Fluidd is the only thing that helped. This has made me determine that the bed mesh is not being used by the printer to compensate for the variance. It is not filament drag, it is the programming that is not using the bed mesh correctly. If the Z-axis tracked the bed mesh it should be an even 1st layer everywhere on the build plate, but like I stated above, the high areas in the mesh show signs of nozzle drag, and the low areas in the mesh do not have adequate squish.

Looking at the printer.cfg file, the start_print macro is blank, with a commented out macro called hot_bed_calibration or hot_calibration_start, or something like that. i do not have the printer.cfg file in front of me right now to confirm what the macro is, but it is not a standard Klipper macro.

The hot_calibration_start macro is directly above the start_print area in the configuration file. I am assuming this is a custom macro that exists somewhere, but I do not know where it is placed. Maybe in moonraker.cfg?

I do not believe that the generated bed mesh is incorrect. The low areas and high areas as shown in Fluidd track exactly to the areas with "not enough" squish and "too much" squish. The printer is not using the z-axis to compensate for the bed mesh, so it is probably an issue with the custom hot_calibration_start macro, or whatever it is called.

[drewp29]

Also, thank you for your help with this. I would really like to track this down and fix the problem. Otherwise, the X-Max 3 is a fantastic printer! I am just trying to work through these little kinks to make it print as good everywhere on the build plate as I know it can. There are quite a few reports of this problem on Facebook, so it is not just my particular printer that has this issue. The people who have not discovered it yet have likely not printed anything that used the entire bed surface.

I have a number of prints here soon that will use a 324x324mm area on the build plate, and I am printing with ASA, so I need as much of an even first layer as possible to keep the print adhered over the course of a 20-21 hour print.

Edit:

I also need to state that my manual leveling of the bed was done with the bed heated to 100C and the chamber temp at 60C, which are the temperatures I am using for the ASA. I let the bed heat soak for a minimum of 15 minutes, probably more like 30 minutes, ran a calibration mesh with the induction probe, then removed the PEI plate and adjusted the bed with the screws (and didn't get burned - safety first!). I then heated the bed and chamber back to those temperatures, let it heat soak for at least 10 more minutes, and ran the bed mesh calibration again. I did this around 10 times over the course of a Saturday, and the resulting bed mesh variance was 0.1625mm. I did have it at 0.1538mm, but the rear right corner and right edge of the build plate were lower than they are at the 0.1625mm variance, so I left it with the 0.1625mm variance.

[CChen616]

In your printer.cfg, there should be a macro section like the following:

[gcode_macro G29]
variable_k:1
gcode:
    {% if k|int == 1 %}
        BED_MESH_CLEAR
#    G28   
        BED_MESH_CALIBRATE PROFILE=kamp  
    {% endif %}

This runs the BED_MESH_CALIBRATE process to generate and apply the adaptive bed mesh. Leveling selected before printing is saved to the kamp profile. Meanwhile, selecting Auto Bed Leveling in Calibration page performs full bed leveling and saves it to the default profile. So please check you have similar things in your Gcode file or did a full bed leveling before printing.

Regarding the leveling process and configuration file saving, we have not made changes in version 10 of the firmware.

If you have already generated profiles, in this klipper version, it will automatically activate default profile on startup.

To find out whether the bed mesh is ineffective or if the bed compensation is insufficient, instead of manually adjusting the screw, you can open the printer.cfg file and look at the bottom for something similar to:

#*# [bed_mesh default]
#*# version = 1
#*# points =
#*#     -0.121303, -0.175157, -0.186459, -0.148855, -0.090626, 0.072134
#*#     -0.144116, -0.208022, -0.224116, -0.204324, -0.155157, -0.009897
#*#     -0.139741, -0.200105, -0.238074, -0.230470, -0.192084, -0.095105
#*#     -0.048907, -0.137605, -0.169636, -0.176511, -0.160261, -0.081772
#*#     -0.075418, -0.149480, -0.205261, -0.212970, -0.197032, -0.128126
#*#     -0.116668, -0.189376, -0.253491, -0.281251, -0.263647, -0.176928
#*# tension = 0.2
#*# min_x = 20.0
#*# algo = bicubic

These points are the Z-axis coordinates probed during the calibration process, and the bed mesh is formed through bicubic interpolation of these points before being applied for compensation. You can then load the corresponding profile in the Fluidd interface.

Here are the probed points and the generated bed mesh.

If you change one of the values, for example, changing the last value from -0.176928 to -0.876928, save it, restart Klipper, and load the corresponding profile, the generated bed mesh will be shown as follows.

You can follow this method to adjust areas where you believe the printing quality is poor. For instance, continue to lower the points where extrusion appears insufficient and observe the results. Before test printing, make sure the profile is active.

If there is an improvement, it means the bed mesh compensation is actually effective, but due to mechanical reasons, the compensation might not be fully reaching or accurate. If there's no improvement, I would consider looking for causes from different angles. Such as

Downgrading from 4.3.13 to 4.3.10. Corrupted Adaptive_Mesh.cfg file which rewrite the BED_MESH_CALIBRATE macro

[drewp29]

I did not have time this weekend to do any testing, but I did look at the printer.cfg file and it contains the mesh coordinates at the bottom in the auto-generated section. I also located the G29 macro and it looks the same as what you posted.

What screen in Fluidd shows the default mesh as active? I will look for that when I get home this evening from work.

[CChen616]

In Tune page, if you load a profile

Then it is active

[drewp29]

Just stopping in to say I am still here.

I am going to replace the induction sensor with a Cartographer eddy sensor to see if the induction sensor just has enough float to not quite sense the min/max areas correctly. Everything else looks to be fine in the config file, and the bed mesh is loaded correctly.

Do you have the pinout of the THR42 variant toolhead board? There is no screenprinting on the board to tell me which pins are which, so having the board pinout would be really useful.

Is there a way to wire the Cartographer to the toolhead board? The Cartographer model I have is both USB and CanBus capable depending on which firmware is loaded. I can run another USB line to the motherboard, but it would be great if I did not have to do that. The THR42 already runs a USB cable, but I do not know if the board can handle the USB output from the Cartographer.

[Fisheye3D]

Just stopping in to say I am still here.

I am going to replace the induction sensor with a Cartographer eddy sensor to see if the induction sensor just has enough float to not quite sense the min/max areas correctly. Everything else looks to be fine in the config file, and the bed mesh is loaded correctly.

Do you have the pinout of the THR42 variant toolhead board? There is no screenprinting on the board to tell me which pins are which, so having the board pinout would be really useful.

Is there a way to wire the Cartographer to the toolhead board? The Cartographer model I have is both USB and CanBus capable depending on which firmware is loaded. I can run another USB line to the motherboard, but it would be great if I did not have to do that. The THR42 already runs a USB cable, but I do not know if the board can handle the USB output from the Cartographer.

You can not use the canbus support on the cart probe, The toolhead uses USB not canbus. You need to run the USB cord.

[drewp29]

Hi Fisheye3D, thanks for your response. I agree the toolhead uses USB, and unlike the commercially available THR42, does not have provisions for CanBus communication.

If I set up the Cartographer for USB output, is there a way to connect to the THR toolhead board such that the USB signals are sent down the stock cable? What does the induction sensor use for communication? I am not that familiar with what can and cannot be done here. Can the toolhead firmware be customized for the pinouts available for the induction sensor?

[Fisheye3D]

Hi Fisheye3D, thanks for your response. I agree the toolhead uses USB, and unlike the commercially available THR42, does not have provisions for CanBus communication.

If I set up the Cartographer for USB output, is there a way to connect to the THR toolhead board such that the USB signals are sent down the stock cable? What does the induction sensor use for communication? I am not that familiar with what can and cannot be done here. Can the toolhead firmware be customized for the pinouts available for the induction sensor?

Unfortunately no, Unless you change the mainboard and the toolhead board there is no way to connect to the toolhead on this printer

[drewp29]

Hi Fisheye3D, thanks for your response. I agree the toolhead uses USB, and unlike the commercially available THR42, does not have provisions for CanBus communication. If I set up the Cartographer for USB output, is there a way to connect to the THR toolhead board such that the USB signals are sent down the stock cable? What does the induction sensor use for communication? I am not that familiar with what can and cannot be done here. Can the toolhead firmware be customized for the pinouts available for the induction sensor?

Unfortunately no, Unless you change the mainboard and the toolhead board there is no way to connect to the toolhead on this printer

Hmmm, semi-disappointing, but not unexpected. Thanks! I will update this when I get it installed and let you know how the first layer turns out with the eddy current versus the induction sensor.

[Fisheye3D]

Hi Fisheye3D, thanks for your response. I agree the toolhead uses USB, and unlike the commercially available THR42, does not have provisions for CanBus communication. If I set up the Cartographer for USB output, is there a way to connect to the THR toolhead board such that the USB signals are sent down the stock cable? What does the induction sensor use for communication? I am not that familiar with what can and cannot be done here. Can the toolhead firmware be customized for the pinouts available for the induction sensor?

Unfortunately no, Unless you change the mainboard and the toolhead board there is no way to connect to the toolhead on this printer

Hmmm, semi-disappointing, but not unexpected. Thanks! I will update this when I get it installed and let you know how the first layer turns out with the eddy current versus the induction sensor.

I use 2 carts and a beacon on diff printers and its well worth it.

[Booldegum]

Dans la page Tune, si vous chargez un profil   > > Ensuite, il est actif ![ Image](https://private-user-images.githubusercontent.com/88018764/316769284-3036a096-70e3-4455-afaa-4e39d05a981a.png? jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTI1NzI0MzMsIm5iZiI6MTcxMjU3MjEzMywicGF0aCI6Ii84ODAxODc2NC8zMTY3NjkyODQtMzAzNmEwOTYtNzBlMy00NDU1LWFmYWEtNGUzOWQwNWE5ODFhLnBuZz9YLUFtei1Bb

Bonjour, How did you do to get a bed as plane as this please ? I can achieve a levelling so plane.

[CChen616]

Bonjour, How did you do to get a bed as plane as this please ? I can achieve a levelling so plane.

This isn't an actual bed mesh; it's one that has been reset at some point, with all points being zero, and thus cannot used for printing.

[thetoadsage]

Hi! From my research and personal experience, I have my suspicions that it isn’t the bed mesh not working, but the high amount of backlash in the Z that prevents it from working properly. You can measure Z backlash using the beacon probe and the amount that I have seen measured is more than enough to prevent proper meshing