Disabling Bed Leveling Doesn't Actually Disable Mesh Compensation

Instead, it just prevents re-probing. The previous mesh data is still applied, which seems like a terrible idea, since it is likely outdated.

IMO, we should have 3 options:

  • Re-mesh
  • Existing mesh
  • No mesh

It seems like we could probably achieve this just through a start G-code modification. Anyone want to help?

Here is the default section of code:

;===== bed leveling ==================================
M1002 judge_flag g29_before_print_flag
M622 J1

    M1002 gcode_claim_action : 1
    G29 A X{first_layer_print_min[0]} Y{first_layer_print_min[1]} I{first_layer_print_size[0]} J{first_layer_print_size[1]}
    M400
    M500 ; save cali data

M623
;===== bed leveling end ================================

So, can we just make a small mod like this?

;===== bed leveling ==================================
M1002 judge_flag g29_before_print_flag
M622 J1

    M1002 gcode_claim_action : 1
    G29 A X{first_layer_print_min[0]} Y{first_layer_print_min[1]} I{first_layer_print_size[0]} J{first_layer_print_size[1]}
    M400
    M500 ; save cali data
	
M622 J0

	M420 S0

M623
;===== bed leveling end ================================

My standard workflow is to turn the machine on and run the bed level on the first print of the day. I then disable it for every subsequent print that day because I know the machine remembers and I’d just be wasting time.

The last thing I’d want is for bed leveling itself to be disabled when I turn off the bed leveling process. Use the data, don’t probe the plate.

I do not think the printer preserves the bed level data across power cycles. So you could just turn the machine on and not run bed leveling and you’d be printing with a mesh that was effectively all zeros. I could be wrong about the volatility of the data, though. If the machine remembers across power cycles, this idea is NFG. :slight_smile:

1 Like

I’ll try that out.

Just tested the above code and the printing just stopped / cancelled at that point.

Neither:

M420 S0

nor

G29.2 S0

disable mesh compensation. :neutral_face:

Why would you want no mesh? I don’t think these printers are built with perfectly flat beds, so an outdated mesh would always be better than none? I don’t even think an outdated one is really outdated unless you have a habit of dropping the printer on the floor.

1 Like

The beds are not perfectly flat. In fact many of the X1C beds are really bad.

But, the mesh leveling is just there to get a decent first layer. If you have a decently flat bad and are printing relatively small objects, you really don’t need it.

For some reason, Bambu has decided not to add the feature of tapering out mesh compensation, like other firmware has. This means that the compensation is applied equally to every layer, so your top layer will be just as un-flat as the bottom. For some parts this is not good.

Also, it means Z is constantly trying to keep up with X and Y, which are much faster and more powerful. Z is fairly slow since it is a single stepper, belt driving 3 lead screws. This can cause localized under and over-extrusion when Z isn’t keeping up with X and Y. It’s similar to how extruder flow doesn’t keep up and we need pressure advance.

Mesh compensation is preserved after power cycling as well.

:triumph:

I actually prefer how it works. IMO, no need to complicate things. Disable the re-level to save time when things are constant (same bed, same plate, and same side of plate). But if you change the plate or flip it over, a simple re-mesh or two and then you are good until you change something in the system or run into to problems.

I can appreciate the need to average out the mesh over the print, but that could very well destroy the machine’s accuracy at a vital point in the print too. Not sure which way is best, leave the mesh un-adjusted, or adjust it out over the print. Its all very geometry dependent. If I had to choose for everyone, I likely would just keep the offset in the print to be consistently offset the entire print. I’d imagine those that need perfect top and bottom had a plan to get it (machining flat and printing with extra material), so any pre-built in slicer adjustment to that is just going to wreak havoc with their accuracy. Also for folks looking for the maximum accuracy, its very like they would buy a bed that promises that, near perfect flatness. Or maybe machine their own.

There is no risk of “destroying the machine’s accuracy”.

Tapering out mesh compensation is very common and does not affect accuracy, if done right. We are talking about a max correction of like 0.3mm. Blend that out over 10mm / 0.15mm layers = 66 layers of blend. 0.3mm / 66, is 0.004mm of correction reduction per layer. The flow error caused by that is tiny, not even measurable in deviation caused in XY.

I assumed you were talking about real accuracy. But honestly… I don’t really see the need to average it out if you don’t care if every layer is a little off on purpose.

Also, I also assumed you were talking about 2-3x that deviation (beds deviating 0.9 mm or maybe even more). A 3D printer that can hold 0.3mm is pretty accurate to me. But to each their own, don’t let me influence your stance, because I’m really indifferent when it comes to 0.3mm deviations on a 3D printer.

I explained above the reasons I want mesh compensation disabled. It reduces the accuracy of your extrusion control. This can make for weaker parts if the localized under-extrusion happens at a critical point.

It really doesn’t matter how big the deviation is. On all but the shortest models, you can find a blend distance that eliminates any issue.

I think both statements are not right.

At any time, the firmware takes the commanded speed and checks if any axis (including the feeder) exceeds its max speed. If so, all axes are slowed down by the same factor until all axis are within their limits. This has been implemented in good old marlin firmware more than 10 years ago and is state of the art for all current CNC machines.

Also pressure advance doesn’t compensate a too slow feeder but it is there to take into consideration that the filament flow does not only depend on feed rate but also on pressure inside the hotzone. So if X / Y are going to accelerate, the feeder will push extra filament in advance to build up extra pressure before the gantry accelerates. When the gantry decelerates, it reduces the pressure in advance. In extreme cases, it might even slightly retract to extrude material slow enough.
So in contrary, pressure advance needs an even faster feeder that will work much harder than is demanded by the gcode.

I think the mesh that is probed at the start of a print is not saved. In my opinion , only the mesh is saved that you can generate during printer calibration together with resonance frequency and so on.
But that is just my understanding without proof, so I could be completely wrong.

I hear what you are saying, and yes that function of the firmware prevents a steady state issue where an axis is asked to travel faster than its maximum. But, that is not the issue. The issue is that the acceleration mismatch causes a transient speed mismatch.

The X1C we have at work has a taco bed and I have watched this with my own eyes, many times. Local areas of over and under-extrusion, that correspond with the Z axis have to correct a lot.

But, I’m really not here to convince anybody to stop using mesh compensation. Just trying to get some help in disabling it (sometimes) for myself.

That sounds really bad. I think this limiting should also be applied to accelerations, so when an axis exceeds its acceleration limit, acceleration should be reduced as well. I’m not 100% sure. But well possible that Bambu have messed up that part. Nobody knows their implentation. Maybe they apply the mesh correction after limiting speeds and accelerations coming from GCode? That would be a serious flaw in my view.

I can’t help with your original question, sorry. Maybe Bambu Support is willing to tell you the necessary steps, if you explain your situation.

Did you claim the bed of the printer at work? I have read of quite some bent beds that were replaced by Bambu. Seems like a sufficiently flat bad would solve the root cause.

Umm, if I’m right with my assumption, maybe this could be a workaround for you: Put a really flat surface on top of the print bed. It doesn’t need to be magnetic, just prevent it from floating around. Maybe a good sheet of glass, a floor tile or similar.
Perform bed leveling in the printer settings. The printer would save a very flat mesh.
When you print without bed leveling, the printer will use the saved almost flat mesh, so close to no compensation at all.
When you want to use the mesh, enable leveling at start of print, so it will probe your actual bed.

Following up on this topic, I got it to work (or stop working, really).

Putting the “G29.2 S0” as the last line of the machine start g-code will disable mesh leveling.

Any homing move will automatically re-enable it, and that’s what was defeating me initially.

For those who don’t understand why you would possible want to disable it, here is an example. This top was printed with mesh leveling on and despite the cylindrical shank being very straight and aligned almost perfectly with the tip, the larger flywheel has enough mesh leveling correction in it to introduce a large amount of wobble. This imbalance ruins the part.

Are you sure this is coming from mesh leveling? I thought that it applies to the first few layers only. E.g. in the first layer, it completely follows the measured bed surface. At the second layers it still follows it but not fully, so that elevated sections of the bed have a little bit thinner layers. This continues until at layer 10 or 20, it doesn’t follow the bed surface at all anymore and every layer is printed at a constant height.

100% sure.

That is how it should work, but Bambu did not implement a “mesh compensation taper height”, like other firmware has, and refused my request to add it.

Here it is reprinted with mesh compensation disabled (ignore the wobble in the bottom taper, there were braces down there that I cut off):