Presently the auto bed leveling is done over the entire span of the print bed but will it be possible to make a plugin that will do this process just over the area where the object is to be printer? In that case this addon should be able to
- Read the area where the print is to be made
- Then on this area select points for bed leveling in the form of a 3x3 grid
- Use the leveling probe at these points for auto bed leveling
- Save the settings.
Will this be possible? Could this be better than the normal pan print bed method?
1 Like
Hello @sheminasalam !
Afaik, the area to level is hardcoded into Marlin.
It's the same with Klipper.
Maybe with RepRap for almost everything is set by Gcodes.
definitely would be something to tackle on the firmware side I think. otherwise the processing required to do that in real-time via plugin would probably not be able to keep up. the math required I think would be astronomical to apply a probe mesh to gcode directly. it does however remind me of something similar in the CNC industry where you can do exactly that, I remember seeing a This Old Tony video about it on YouTube.
What if instead of doing all the maths in the plugin, there is a plugin in cura or other slicers which can do the maths and then export the points for probing with the gcode. In that case the plugin in octoprint has to just take this probing points and conduct the leveling operation before printing.
1 Like
that would be more viable probably. doing some quick searching this appears to be the open source go-to for GRBL firmware GitHub - martin2250/OpenCNCPilot: autolevelling gcode-sender for grbl. but then I ran across an old forum post from 2017 and that led me back to the Marlin firmware documentation for leveling. Bed Leveling (Bilinear) | Marlin Firmware. The examples show exactly what you are trying to achieve I think.
You would just need a plugin to know the bounds of the gcode file, and use that in the G29 command. Of course you'd probably want to take into account prime lines, etc.
2 Likes
I started this post only because I read about G29 but it was mentioned that leveling points is a firmware hardcoded feature. I believe there is even an option to set probing points from the LCD(do have to check). It would be awesome to have such a plugin. It seems the background for this is already done as evident from the projects you shared. I am not an expert with coding. Hope someone would make it happen.
This was actually the very first plugin I did for OctoPrint many years ago.
If you are using bilinear mesh bed leveling you can specify the left, right, front, and back limits for probing. It wasn't much of an issue to get the X and Y coordinate limits for the print as a whole, but the problem was that any prime lines would also register in this, so you were always probing more of one dimension than you needed. SuperSlicer provides bounding box information for each object, so that would be easy to parse. You could also pre-process with object tags from Cura/PrusaSlicer to determine the limits that didn't include things like prime lines.
1 Like
I don't see it in your GitHub.
I think those were my pre-GitHub days. I did look through my files and found it. Honestly, I had almost no idea what I was doing at the time or if the last implementation I tried even worked. I'll throw it up there if there is possibly anything useful in there.
1 Like
It would be great if you can make this work.
What slicer do you use?
Ultimaker Cura 5.0 generates the following at the beginning of the gcode:
;FLAVOR:Marlin
;TIME:8248
;Filament used: 1.7092m
;Layer height: 0.1
;MINX:106.284
;MINY:120.254
;MINZ:0.3
;MAXX:174.179
;MAXY:160.217
;MAXZ:48
;Generated with Cura_SteamEngine 5.0.0
Unfortunately, the variable {MINX}
(and others) doesn't appear to be available, but a slicer plugin could easily solve that.
that would probably work just by slapping a python compatibility flag on it. I think in lieu of re-analyzing though, would use the returned metadata analysis maybe in your on_event callback with something like self._file_manager.get_metadata("local", payload["path"])
"analysis": {
"printingArea": {
"maxX": 179.6230010986328,
"maxY": 155.34500122070312,
"maxZ": 2.200000047683716,
"minX": 60.0,
"minY": -3.0,
"minZ": 0.0
},
"dimensions": {
"width": 119.62300109863281,
"depth": 158.34500122070312,
"height": 2.200000047683716
},
not sure if those are taking into account the prime line either though, but likely with a -3 minY. would require some additional checking.