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?
N/A
Did running in safe mode solve the problem?
N/A
Systeminfo Bundle
You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
WRITE HERE
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.
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…
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.
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.
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.