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.
Why is probing hard? You go the xy position you want, deploy the probe and do a g30 and wait on it to return the z value, lift and then reset the probe. 4 lines of gcode. None of it time critical. That is no different than homing the machine, or doing basic movement from the motion keys. You can manually do it from terminal, anything that can be done manually from terminal can be automated.
We're talking about two different things. This thread (or at least the last few comments) are talking about connecting the BL Touch to the Raspberry Pi, with motors on the printer motherboard + firmware. This is where the disconnect is, two different systems. You can't send a gcode to the printer to start probing if it doesn't have a probe.
What I think you're thinking of, is BL Touch still connected to the printer, controlled by the firmware. Yes, this is doable and at that point you don't need OctoPrint to do the probing, that's the printer doing the probing.
Correct, I'm talking about just using the g30 single probing in firmware (for a probe on a printer) to have octopi build a mesh stored on the pi and apply it to gcode as it is output to the printer. I have used firmware mesh leveling but like the simplicity and speed of leveling in mattercontrol which is creating and storing the mesh on the pc. When gcode is sent, the breaking up of long moves and modifying the z for each segment is done on the pc. The only thing I don't like about it is having to be tethered. Well aside from the boneheaded way they choose points and other bugs. Octopi could easily handle this. I'm an old school assembly/c embedded systems programmer and trying to navigate the environment for octopi is more daunting than I can make time for.
If you think firmware leveling is better, that is validly discussable. But the mesh on PC method allows throwing a random build plate on and be printing with perfect z values 3 minutes later. I've found firmware mesh leveling to take significantly longer and stored meshes to require verification more often than I like on my printer.
Ok, so we are both aligned with talking about doing this differently from the original topic. As already mentioned, someone made a plugin to pre-process the gcode. I assume it works. From what I can see, the only thing it doesn't do is automatically collect the mesh. You could start there, if you wanted to get into it and fork the plugin to add automatic collection capabilities.
Well, the original topic wasjust doing it like mattercontrol, the hooking a probe to the pi was a fork, which is of course a bad and impossible idea, which was correctly pointed out, maybe by you?
Starting from the existing preprocessor is a great idea. I’ll take a look. Thanks!
Author says the latest version of this now has autoprobing so it should represent a complete solution to what we have been discussing. I haven't tried it yet.