Mini v3 increasing bed mesh points, adaptive mesh

General LulzBot Mini
1

Hi, I’m working with a Mini v3. I’d like to increase the amount of points probed in the bed mesh, 4x4 or 5x5 would be helpful. I would also like to enable the adaptive pre-print mesh at a similar number of probe points.

I have configuration files pulled, not sure what to edit with those. I changed y=3 x=3 to y=5 x=5 but there is still the array and I think that’s preventing it from changing. The log returns y=3 x=3 when I send a mesh command.

Does the adaptive pre-print mesh use the stored mesh to make a final mesh or does it disregard the stored mesh and use only the adaptive mesh? Either way it would be helpful to have both.

If I need to answer why I want this to get help;
the stored bed mesh with only 3x3 is so far off on one out of 9 points it is preventing extrusion. I’d like to expand the number of probe points to help me understand the shape of the bed.
Adaptive bed mesh is cool and something I’d like to understand further for a larger printer.

Thanks!

2

The adaptive mesh in the Mini 3 is set to a 5x5 grid with adaptive meshing. The way adaptive mesh works in Klipper, it will reduce the number of grid points to 4x4 or even 3x3 if the print is smaller and the adaptive mesh area is therefore smaller.

If you just want to get a look at the bed mesh, you can go to the Mainsail web interface, go into the Mainsail settings, and enable the Heightmap page (it’s off by default). Then go to the heightmap page and click calibrate. Because you are not printing, it should probe the full area of the bed with a 5 by 5 mesh and then show the mesh on screen in Mainsail.

If you wish to experiment with probing settings, you can copy the [bed_mesh] section out of the lulzbot.cfg file in the config/lulzbot folder, and paste it into printer.cfg and modify the settings there.

3

Thank you for your response!

When I do a height map it’s only 3x3. When I send a mesh command through the port as part of the response it returns “x=3 y=3” before doing the 3x3 height map.

I’ve never seen it do an adaptive mesh, is that something I can toggle on the touch screen or mainsail interface?

this is lulzbot.cfg [bed_mesh]
[bed_mesh]
mesh_min: 36, 22
mesh_max: 175, 173

probe_count: 3,3
horizontal_move_z: 8
speed: 150
fade_start: 1
fade_end: 0
#fade_target: 0

faulty_region_1_min: 80, -23
faulty_region_1_max: 152, 44

I will try changing the probe count in lulzbot.cfg today.

It seems like it is using the information from printer.cfg, I’ll double check but I think I remember it listing out the points matrix along with x and y values

#*# [bed_mesh Test]
#*# version = 1
#*# points =
#*# 	1.054500, -0.567167, 0.298250
#*# 	1.209500, 1.172000, 0.392000
#*# 	1.155750, 1.173250, 1.310750
#*# min_x = 36.0
#*# max_x = 175.0
#*# min_y = 22.0
#*# max_y = 173.0
#*# x_count = 5
#*# y_count = 5
#*# mesh_x_pps = 2
#*# mesh_y_pps = 2
#*# algo = lagrange
#*# tension = 0.2
#*#
#*# [bed_mesh default]
#*# version = 1
#*# points =
#*# 	  0.823250, 0.982417, 1.504500
#*# 	  0.958250, 0.929500, 1.088250
#*# 	  0.837000, 0.887000, 1.020750
#*# x_count = 3
#*# y_count = 3
#*# mesh_x_pps = 2
#*# mesh_y_pps = 2
#*# algo = lagrange
#*# tension = 0.2
#*# min_x = 36.0
#*# max_x = 175.0
#*# min_y = 22.0
#*# max_y = 173.0
4

Strange. The mesh should be 5x5, as indicated in the lulzbot.cfg file here:

The saved meshes in printer.cfg will have the number of points that were called for when the mesh was probed, not sure why that’s 3x3. I guess look at your lulzbot.cfg and look in printer.cfg to see if there’s any [bed_mesh] sections in there overriding lulzbot.cfg.

5

Ok, if I call bed mesh profile “Test” I get the 5x5. If I call bed mesh profile “Default” which it was doing this whole time I get the 3x3. this is in printer.cfg

I’m used to a different brand where you can set the mesh via the display or Mainsail. Is it possible to request that for a future firmware update? There are multiple meshes but there’s no way to change the number of probe points.

#*# [bed_mesh Test]
#*# version = 1
#*# points =
#*# 	1.054500, -0.567167, 0.298250
#*# 	1.209500, 1.172000, 0.392000
#*# 	1.155750, 1.173250, 1.310750
#*# min_x = 36.0
#*# max_x = 175.0
#*# min_y = 22.0
#*# max_y = 173.0
#*# x_count = 5
#*# y_count = 5
#*# mesh_x_pps = 2
#*# mesh_y_pps = 2
#*# algo = lagrange
#*# tension = 0.2
#*#
#*# [bed_mesh default]
#*# version = 1
#*# points =
#*# 	  0.823250, 0.982417, 1.504500
#*# 	  0.958250, 0.929500, 1.088250
#*# 	  0.837000, 0.887000, 1.020750
#*# x_count = 3
#*# y_count = 3
#*# mesh_x_pps = 2
#*# mesh_y_pps = 2
#*# algo = lagrange
#*# tension = 0.2
#*# min_x = 36.0
#*# max_x = 175.0
#*# min_y = 22.0
#*# max_y = 173.0

It’s also doing the dynamic pre-print mesh.

11:48 AM
Points: x: 3, y: 4
11:48 AM
Algorithm: lagrange
11:48 AM
Object bounds, clamped to the bed_mesh: (62.056, 40.569), (117.944, 141.813)
11:48 AM
4 object points, clamping to bed mesh [(36.0, 22.0) (175.0, 173.0)]
11:48 AM
fuzz_max : 4.000000
11:48 AM
fuzz_min : 0.000000
11:48 AM
fuzz_enable : 0
11:48 AM
status_macro: 'status_meshing'
11:48 AM
led_enable : 0
11:48 AM
File selected

however at the end of the bed mesh it sends it to an out of bounds point to start printing

11:51 AM
Move out of range: 58.232 43.800 -3.495 [30.000]
11:51 AM
Bed Mesh state has been saved to profile [default]
for the current session. The SAVE_CONFIG command will
update the printer config file and restart the printer.
11:51 AM
Mesh Bed Leveling Complete

The print cancels itself. I will look to disable dynamic meshing for now. I don’t see that as an option in Mainsail or on the touch screen which would be helpful.

If I could get a more verbose dynamic meshing I could possibly try to figure out why it thinks it needs to go 3.5mm under the bed.

I’m starting to think it might be better to start with a totally clean SD card and brand new firmware from the website. We have a second machine that is only doing 3x3 meshes too. I didn’t get to set these machines up from the box, it was an outside contractor. Could they have done something during the initial construction to make all these weird things happen?

I’m noticing there is print_area_bed_mesh.cfg that establishes “status_meshing” and also adaptive_mesh.cfg only adaptive_mesh.cfg has the "fuzz”parameters.

6

The [bed_mesh Test] and [bed_mesh default] sections are saved meshes that were run previously. I don’t believe the parameters in those saved meshes have any influence on how future meshes are done. Future meshes will be performed according to the settings in the printer.cfg or other cfg files that are included in the printer.cfg, with the last settings in effect.

I think there’s definitely something strange going on with your printer, someone had been experimenting and changing the configuration. Your console output for the mesh shows fuzz_max, fuzz_min. These are commands I don’t think we’ve ever used in the Mini 3. Also, I don’t think we’ve ever used an adaptive_mesh.cfg file.

We did use the print_area_bed_mesh.cfg in the past, and I think that file is a leftover from then. But when they added adaptive meshing to klipper, we just switched to using that. I don’t think that file is included into printer.cfg or in include_files.cfg, so it shouldn’t be active.

I’m not 100% sure of the above, I’d have to check when I get back to work on Monday.

You can do meshing through Mainsail with the Heightmap page. If it’s not present on the left bar (we turn it off by default). Click on the gear icon at the top right corner. In the Interface Settings window, click on Navigation, and then click the checkbox for Heightmap, and it should appear in the left side navigation bar.

On the Heightmap page in Mainsail, you can use the icons at the top bar to home the printer and then click calibrate to probe a mesh. When done it should show you a 3d visualization. You can also load the previous saved meshes on the right side with the up arrow circle icon.

You should also be able to do bed mesh operations with the touchscreen through KlipperScreen. Just go to More, then Bed Mesh. You can load previous meshes, do new ones with the calibrate button, and look at the mesh values. It’s not quite as nice since it doesn’t do the 3D rendered mesh, but it should work fine.

It might not be a bad idea to just start over with a fresh SD card. It takes a bit of work because after flashing the card and booting up klipper you have to query the CAN Bus IDs for the Manta and EBB and put them into the .printer_ids.cfg file (or just save the file you have and put it back on the new card), then you would have to recalibrate the Z-Endstop position and BLTouch offset.

The problem with that, is I just looked at the usual places we put stuff like firmware and software, and I’m not finding the Mini3 SD card image available anywhere for download. I’ll check into that on Monday and see if it can be put up somewhere like firmware.lulzbot.com.

7

Mini 3 SD card image is up at Index of /Mini_3/SD_Card_Images

I’d recommend using a new SD card so you still have the current one to go back to if things don’t go as planned. The card needs to be at least 8 GB, but I’d recommend 16 or 32 GB. Write the image to a card with something like Raspberry Pi Imager or Balena Etcher. With the R-Pi Imager you don’t even need to unzip the file.

8

The new firmware looked ok, it was confirmed with Balena Etcher, and I was trying to get it to zero with the Z stop close enough to use the probe when it decided to really break itself.

Now it moves X and Z at the same time when homing X, and often with G code inputs. When it goes to print it sends the print head all the way to +x and bumps against the top of the machine before hitting any stops.

I checked for updates and it said some of the options for update manager were corrupt. It downloaded new ones from Github and is still broken. WIth the old SD card it is still broken in the same way.

Is it possible the image from that zip file is so out of whack it flashed bad firmware to the control board?

9

The card image should be good. It’s the image that was used to make the master SD card that is copied to make new SD cards for production Mini 3 printers.

The usual cause of the Z moving when it should just be X moving is loose set screws on the pulley on one of the two motors in the bottom of the printer.

10

It’s X moving when it should be just Z moving. The stepper motor is pushing it. Only during a Z home operation, G0 X command can move the X independently.

11

Oh, I was thinking the other way.

It might still be loose set screws. Because of the way that CoreXZ works, to move straight in the X or straight in the Z direction, both of the motors have to turn at the same time, and if one stops because the pulley slips, it will move diagonally. I’ve seen that sometimes the set screws will catch and it will work as expected for a bit, then start slipping again and will move diagonally.