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?
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.
Me neither, but it sounds like the printer has a mesh - and maybe once is using it and once isn't. That could be fixed in two ways, either by enabling RESTORE_LEVELING_AFTER_G28 in the firmware or by using M420.
If your probe is deployable there's nothing against running a G29 in your starting GCODE but I use a manual probe and very much shy away from using a G29 in my starting gcode. not having the probe mounted and running leveling is a source of anxiety for me.
Edit: Actually I think a printer that comes with a Z-probe should have RESTORE_LEVELING_AFTER_G28 enabled normally. But than again its Creality.
Again, there are no standards for doing this either. OctoPrint can't contain printer-specific code in its core. Printer-specific code can be handled by plugins to a certain extent.
I believe the right place for bed leveling is in the firmware on the printer. The Marlin firmware has demonstrated that this can be done successfully even in the 8 bit microprocessors commonly used. If more complex calculations are needed, printer controller boards with 32 bit processors are becoming common.
I believe the right place for bed leveling is in the firmware on the printer.
Completely agree, but at the same time one could make that point for the different filament runout plugins.
I agree that this should definitely be handled in a plugin and not in core. But it seems you're painting this relatively black and I fail to see the reason.
Again, there are no standards for doing this either.
There also aren't standards for handling filament runout - just put something matching to the GPIO pins and use a plugin. I don't see why the same thing could not be done for a bed leveling probe. In parts this would basically be the exact same technology, a microswitch.
And again one could argue (and I would) exactly what you said, that filament runout should be a feature of the firmware and that many printers have shown this to be working quite well. But there are printers that lack a way to connect a filament runout sensor and for those printers there's a plugin.
I'm with you that this should be a feature of the firmware but I'd challenge whether there should or should not be a plugin for systems lacking a probe possibility.
Not trying to be confronting, just trying to understsand the rationale.
We are just debating the issue (and doing a better job than the presidential candidates).
I have no objection to a plugin and there are already five plugins with "level" in their title. However, those plugins are not manipulating every G0/G1(/G2/G3) command that is passing through OctoPrint on its way to the printer which, if I understand what you are asking for, would be necessary for the compensation to occur there. In addition, complex leveling (i.e. mesh based) could require converting one GCode command into multiple GCode commands.
I'm not saying it can't be done, just questioning if it should be done. In fact, it has been done (in a slightly different fashion).
The Klipper firmware does all the GCode interpretation in the RPi including the bed leveling compensation. It then feeds a simplified set of commands to the micro-controller attached to the printer.
This is exactly what I was thinking. The caveat to doing this with a plugin is the risk of blocking the serial communication layer as it's rewriting all those commands being sent to the printer and the large amount of math required to evaluate nozzle position and compensate for the difference in offset. It could potentially end up causing print artifacts and blobbing due to this.
I added the M420 S1 command after G28 and it fixed the problem. It appears Creality has bed leveling enabled if you print from the SD card but not through the serial port. I will bring this up in the Creality forum because their slicer must not output M420 if their test files don't have it.
Thank you for your help. I am very happy that I can print using Octoprint with my new CR-6SE.
I have other issues with the CR-6SE and Octoprint but I will post to the appropriate thread.
Pacey, I have been using OctoPrint for 2 months with an Ender 5 and I had the exact same questions that you have raised here. I would like to get the current status of the thoughts on this thread, if you know of any other work on this topic, and to add my perspective.
I have been looking seriously at adding the BLTouch to my Ender 5, and have read many posts and watched many excellent videos to learn the details. This leaves me very hesitant due to the following:
There are many hardware modifications required.
There are firmware modifications required and too many options I would need to choose, including which firmware type and version to use, what to delete in the firmware configuration due to space limitations. No mention of how to capture your current firmware code to reset it if things go bad.
Slicer modifications/settings needed, and a vast choice of slicers.
Note that I am an experienced senior software/electronics engineer. Perhaps that experience gives me the realization of the number of problems and issues that could arise? Maybe a 14-year-old home user would just do it and have it work just fine?
I was hoping find a very simple solution to using the BLTouch without these issues as I can't imagine many non-engineering users to be confident with these needed steps to install and use the BLTouch.
The envisioned solution that I was looking to find is to:
Connect the BLTouch to the OctoPrint's Raspberry PI.
Have an Octoprint plugin to drive the BLTouch and to modify the Z values in the gcode being sent to the printer.
I see the following PROs:
No printer hardware or firmware changes would be needed.
Very easy to install and use.
The Raspberry Pi should easily handle the calculations needed.
And the following CONs:
The BLTouch would not work directly with the printer, Octoprint and the Raspberry Pi would be needed. For a typical home user I don't think this would be an issue, advanced and industrial users would go with the hardware and firmware upgrades.
I am about to research how to write an OctoPrint plugin and come up with a prototype unless I can find one that someone else has already done. Given my experience I would expect a few days of work to get a simple prototype of the working once I understand how to write and install an OctoPrint plugin.
I welcome other thoughts on the topic, and once I have a prototype plugin running would welcome help in the detailed specs on the plugin. Thanks
Depending on the printer, adding a BLTouch can be very straightforward, or more difficult. For example, newer Creality boards (V4) have a dedicated port, and they provide firmware for it as well. So it is very easy. When you don't have a port on the board, this is where it gets difficult.
The problem you have with attaching the probe to the Pi is accuracy and timing. The serial connection is not realtime control of the steppers. OctoPrint sends to the firmware 'move to X position', then the firmware interprets this, buffers it and then calculates the steps needed to move there and then finally starts moving and moves on to the next command in the queue. When the FW is in control of probing, it can move a step and measure the probe all the time. Of OctoPrint were to do it, it would have to command a baby step, wait, send M400 (I think) to clear the buffer, measure the probe then move again. A very slow process to probe, and likely to be very in accurate in case the printer is not in exactly the position you think it is, because again no real time control.
There already exists the 'Gcode Levelling' plugin, where you can enter a mesh manually and it will compensate. But this still isn't as good as the firmware, and I can give an example. If you have a straight line, from one corner of the bed to the other, OctoPrint can only compensate for the ends of this command, whereas the firmware can compensate across the entire motion.
Your pros are OK, but for many connecting the BL Touch to the Pi is the same amount of effort as connecting it to the 5 pins on the motherboard. But I think you miss the cons I have mentioned above, and I don't want you to waste too much time on this. You can try it and see, maybe you get a good result but in my opinion it will not be the result you are looking for, without significant amount of reinventing the wheel.
A replacement controller board isn't that expensive. You can purchase one with BLTouch hardware (and firmware) support. You'll then have your existing controller board (with its current firmware) as a backup.
CP, I appreciate your thoughtful reply and the timing and control issues. I will try to do some testing to understand this better and it will help me to learn more about the current state of the art with 3D printing and OctoPrint. The balance between software, firmware, and hardware is where things are interesting as you map capabilities to them.
The original post mentioned the mattercontrol method of bed leveling. IMO that is the one best feature of mattercontrol. Quick and easy way to check and update bed leveling at the beginning of every print. It would be easily implemented in octopi by someone with octopi chops and would actually way reduce overhead in firmware,not increase it as has been argued here. Why? firmware leveling requires breaking each line of gcode into many parts and adding a z to it based on the mesh. A much better job for a ghz pi than a 16 to 120mhz microcontroller. I have the coding skills from 25 years of motion control coding but after looking at what it takes to write octopi plugins, I don’t have the knowledge or the time to get it for that environment. Willing to have a conversation with someone that does though. I would love to sidestep firmware leveling. IMO it works but i find it finicky. The mattercontrol method is simple, quick, and reliable. (That is perhaps the only good thing I have to say about MC) It would be a great octopi feature.