Is there no software bed levelling in OctoPrint?
I mean like there is on Mattercontrol, where you probe a set of points with a paper test and the programme works from there.
It works brilliantly and Octoprint seems to me an ideal platform to have something similar.
There's no software bed leveling in the core OctoPrint but there are plugins. If you have OctoPrint running, open the Plugin Manager, click on Get More..., and type "level" in the search box.
I'm not finding one there that does what I'm talking about. The mainly seem to be utilities to help move the head around to assist the adjusting of screws.
On that count I like the feature in Klipper that runs the probe around the bed and tells you how much to turn each screw.
OK, so it doesn't quite get it right, but the principle is helpful.
Bed Level Visualizer will show you the grid which will aid in adjustments. Bed height compensation would technically possible with OctoPrint but I have a feeling that the overhead might be too much to do on the fly on something like a Raspberry Pi. It would be way more efficient to just do it in firmware.
1 Like
@Hairyloon, I think there is some confusion here between what you calling "Software Bed Leveling" and what @kantlivelong and I are assuming that means.
MatterControl is an integrated modeling, slicing, and printer controller/monitor. Octoprint is just a printer controller/monitor. The "Software Bed Leveling" in MatterControl uses data collected from the printer to control the slicing (or more appropriately, the generation of the gcode). In OctoPrint, the gcode has been generated elsewhere and is passed to the printer almost exactly as received.
Klipper is a combination of firmware in the printer and additional software on the RPi. When integrated with OctoPrint, the gcode is sent to the additional software (which appears as a virtual printer) and that software converts it and sends Klipper commands to the printer.
The most popular firmware for printers is Marlin and Marlin has a variety of automatic bed leveling algorithms along with a code to interface with various hardware probes. At this firmware level, gcode is translated into real time control of the stepper motors and the stepping can be "modified" by the data collected during the automatic bed leveling phase.
If our "answers" don't match your "question", then perhaps you can ask a different question and we can try to answer that.
2 Likes
Yeah, good point. I hadn't thought about how the code actually works.
The question is moot for me now since I'm using klipper which sorts it out another way, but thank you all anyway.
Nothing beats manual bed leveling. Learn how to level the bed and you won't need any software wizardry to try to fix the problem. Try to visualize what software has to do to compensate for a non level bed. You're just kicking the can down the road.
1 Like
I agree there is nothing better than a manually leveled bed, this plugin just helps with understanding how far off your bed really is relative to the mechanically moving parts and inconsistencies in the bed itself due to either being warped, tightened down to much, etc.
Ah, but you cannot manually level a bed that is bent and it's a simple enough task for a computer to compensate for a little bit of wobble.
Alternatively if a perfect bed is so important, has anyone tried strapping a sander to the print head so it can mill itself flat?
So are you trying to bed level with a mesh manually? or do you have a probe? Eitherway you need to adjust your firmware and make the commands according to the setup you want. You can use a command mod to make gcode buttons and save them for use.
As I said in an earlier post: Klipper sorts it out nicely (apart from the fact my probe is crap).
It has a feature that probes the corners and tells you how much to turn each screw to level it.
Somebody might want to implement something similar for Octoprint, unless there already is one.
Bed Leveling Wizard:
Get your center set with Z-Offset, then run the wizard. Head will go to each corner and pause while you adjust the bed then will do it again.
Once that's done, run your ABL probe, save your mesh data and print away.
I have a similar question. I have been using Octoprint to send gcode from my computer to the OctoPi to drive my Ender 3 Pro and all works fine. I just drag and drop the file to the left hand side of the screen into the Octopi (not the Ender SD card) and then select the file from the list and hit print.
I recently got a Creality CR-6SE with a fixed bed and built in auto bed leveling and connected it to the same OctoPi and sent a Creality sliced CR-6 test print in the same manner and it printed. However one edge was curled and detached from the bed so I printed the same file directly at the printer from the SD card and it printed fine. It appears the Octoprinted file ignored the bed leveling information.
My question is: If I print a file thru Octoprint connected to my CR-6 does it use the auto bed leveling features of the CR-6?
Thanks for the help.
It might be, that if you print from the SD card the printer assumes an M420 S1 command to restore bed leveling information, or may not be doing a G28 when printing from SD card. you could make sure that your start GCODE contains M420 S1 to restore bed leveling after homing.
Bed leveling is normally handled by the firmware in the printer. The start GCode in the slicer is usually printer specific and includes any GCode commands (G28, G29, etc.) that tell the printer firmware to do bed leveling. Since the slicer puts the commands in the GCode file, it should print exactly the same from either the SD card on the printer or uploaded to OctoPrint and printed from OctoPrint.
Coming back to the original topic I'd tend to disagree with the notion that compensating for bed leveling might be too much of an overhead for a raspberry pi. There should be more than enough processing power if this can be handled pretty well by those 8-Bit controllers.
And I'd support development going into that direction. I have a printer that for some reason has a issue with a somewhat buggy firmware (basically the printer does not recognize his probe) and it would be an easy workaround and a great feature for cheap printers lacking this feature or having it locked away in firmware.
One of the biggest problems with doing the compensation within OctoPrint is the lack of any standards for obtaining the compensation matrix from the printer.
If the bed is flat but tilted from level, then a simple adjustment of the z values on each GCode command would suffice, but if the bed isn't flat, then one command might have to be converted to multiple GCode commands and this may overwhelm the serial communications (much the same problem as circular features of a model getting converted to too many short GCode commands).
The RPi probably has the computing power necessary, but it may not have the bandwidth necessary in the communications path to the printer (and the cheaper the printer, the more likely that the communications path is "cheap" as well).
Thanks to you and B-Morgan for such fast replies.
I checked the Gcode from the Creality provided test file and it does not contain the command M420 S1. I will add that and see if it fixes the issue.
Maybe I'm misunderstanding something here but my idea would be to take the probe measurements in Octoprint instead of importing the mesh from the printer (which would probably be a nightmare).
The compensation could - like in your example - still easily overflow the control connection - but at least you don't need to rely on manfuacturers to provide a clean interface to their mesh information.
I'm not convinced that it is just an M420 S1 that is missing. This command says enable the bed leveling but contains the caveats:
G28 disables bed leveling. Follow with M420 S to turn leveling on, or use RESTORE_LEVELING_AFTER_G28 to automatically keep leveling on after G28.-
A valid mesh is required to enable bed leveling. If the mesh is invalid / incomplete leveling will not be enabled..
A valid mesh is (usually) generated by a G29 following the G28. However, we are talking about a Creality printer here so who knows what they have done with the firmware.