Anycubic Kobra V1 (large direct drive block) and Octoprint Bed Visualizer plugin - how to report to printer?

What is the problem?

I cannot find the correct GCode to get the Bed Visualiser mesh data to report to my printer to account for what appears to be a lopsided bed (no adjustment, off by about 1mm)

What did you already try to solve it?

I have tried several gcodes but some stick the printer in a bed levelling loop, others have no effect

Have you tried running in safe mode?


Did running in safe mode solve the problem?


Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)


Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

I am trying to get octoprint's bedlevelvisualizer mesha data to report to the printer so it can account for any out of level part of the bed. Having tried several that I have found online, so far i am either doing something totally idiotic, or im just not getting the gcode right. I have been printing fr a coule years but admittedly only just started with octpprint.

Hello @PriceAdam1978 !

Obviously you don't understand the purpose of the Bed Visualizer.

It's a Visualizer. It gets the bed mesh data from the printer and makes a visual.

The bed mesh data is already with the printer.


I get that it’s a visualiser, but I was (possibly mistaken now) that the mesh data it generates needs a code in order for the printer to compensate.

Is this an incorrect way of thinking in terms of what this tool does? If I use bedvisualizer the sensor doesn’t take the mesh’s data into account so I always have an unadjustable high spot…

Sorry if im Benig dim here….

Ewald is correct, it's your printer that is accounting for the adjustments, my plugin only shows you what it has recorded from the probing process. What it sounds like to me is that you need to add M420 S1 to your slicer's start gcode after the G28 command in order to activate the use of the bed mesh.

1 Like


Thanks guys, it appears that my start code has m420 L before m420 s1;

If I remove m420 L, will it then compensate for the slightly unlevel bed? We’re taking from -0.2 to 0.2 which in real terms isn’t a lot but enough to drive me bananas

So does this indicate that when I used abl in the printer, it hasn’t stored the info about the mesh?

If it was that simple, I’m pretty sure that would be the problem. Cos last time I used bed levelling on the printer itself, re-did the z offset but still that problem of a raised (slightly) bed on the rhs

This just means to load the mesh data from EEPROM with the L parameter and then enable with the S1 parameter. It doesn't hurt having the load, but assumes you have a mesh saved to EEPROM. I guess the question would be do you see the z moving at all while the hot end is moving across the bed? If not, then it's not enabling the mesh. If the mesh is too far off it can also make things harder for the firmware to compensate. Make sure you've manually leveled the bed with the feeler gauge/paper method and then run your probing process.

Boom; you just revealed the answer and I can’t believe I didn’t notice it; I don’t see any z movement as it moves across the bed.

I guess what I need to do then is to see how to save the mesh that the printer does to eeprom.

So I guess it’s a printer more so than I to print problem

M420 V will typically tell you what the stored mesh is. After running leveling M500 would typically save it. Depending if you have UBL or Bilinear on your printer's firmware you could have a single mesh, or multiple. With UBL running M420 L1 for example will load slot 1 mesh data, M420 L2, etc.