Any prints that are started from OctoPrint are not using the Z Offset.
### What did you already try to solve it?
I searched online for solutions as to why OctoPrint was not using the offset and there were a lot of reasons, but none made sense for my case.
### Additional information about your setup
Ender 3 Pro with v 1.1.15 silent board
Installed BL Touch according to Creality, I flashed the firmware that they said to ( (2019.11.13)Ender-3 Pro1.1.6BLTouchV3.1PowerLossContinueEnglish.hex) and preformed the platform adjustment, setting the Z Offset.
I am using a very vanilla install of OctoPrint, and from what I read OctoPrint is supposed to use the Z Offset value which is saved in the EEPROM.
I installed the EEPROM Editor plugin and from there I can see the correct value.
I took 3 different print gcode's that would not print properly in OctoPrint and copied them to the sd card. They printed simply fine from the sd card. So, at this point I am not sure where the issue is, there are so many different things about this issue that I'm not sure what is the correct thing to try.
OctoPrint Version: 1.5.3
OctoPi Version: 0.17.0, running on Raspberry Pi 2 Model B Rev 1.1
System Information:
connectivity.connection_check: 8.8.8.8:53
connectivity.connection_ok: true
connectivity.enabled: true
connectivity.online: true
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: true
env.hardware.cores: 4
env.hardware.freq: 900
env.hardware.ram: 915726336
env.os.bits: 32
env.os.id: linux
env.os.platform: linux2
env.plugins.pi_support.model: Raspberry Pi 2 Model B Rev 1.1
env.plugins.pi_support.octopi_version: 0.17.0
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 19.3.1
env.python.version: 2.7.16
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.5.3
printer.firmware: Marlin Creality 3D
I read through it all and spent a few hours trying different firmware, https://www.danbp.org/p/en/node/136 I was trying to install 1.1.9.1+ Bugfix + BLTouch for Ender 3 (Aug 3rd, 2020) which is the recommended firmware. I couldn't get it to install. So in the end I'm still using the firmware that came with. I reset up the z offset and it's doing the same thing.
I may well be wrong but a quick look at the page you referenced suggests that the firmware he's compiled is for Ender3 whereas you said you had an EnderPro with a silent board, are the compatible?
I'm surprised that OctoPrint would use the Z value, surely it just send the GCode you specify and the printer adds or subtracts the Z value to any Z move.
In the comments (There are a few hundred comments) on that page people have flashed it with board v 1.1.15 (silent board). On Ender's website they list that the firmware is for Ender-3(Pro)/Ender-5(pro)/CR-10/Ender 3v2 but regardless of that OctoPrint should just send the GCode like your saying to the printer and it does everything else and that's where it I'm at a loss as to why it's not doing that.
So I'm not sure what was going on here, but I'm back to using the firmware from Creality and I reloaded Octopi for a different reason and so far after two prints it's working as expected.
If you power on your printer without the last SD card you used inserted - Is the Z offset reported as 0 or the value it was previously set to? If it is 0 and you then insert the SD card, does it suddenly change to the previously set value?
If you are able to power on the printer without the SD card inserted and the previous Z offset value is displayed, then the firmware you are using is storing the Z offset in the mainboard EEPROM.
If you see 0 but then see the previous value after inserting the SD card then the firmware is storing and retrieving the Z offset from a file on the SD card called EEPROM.dat.
With regard to the EEPROM editor plugin, My Ender 3 v2 reports firmware version 1.1.2 under info on the display panel. I installed the 1.1.2 firmware which is meant to have Marlin firmware 2.0.1 for BL/CR touch which I downloaded from creality.com - the firmware was dated 26 March 2021. The EEPROM editor plugin reports Marlin firmware v1.1.1 - I don't know why the EEPROM editor plugin reports the wrong version but it doesn't matter much since it's unable to Save the configuration without the SD card.
I tried sending M500 via the terminal but I got a "No EEPROM" reply.
I'm beginning to think that either there is no actual EEPROM on the mainboard or if there is an EEPROM then maybe it's too small to store all of the settings needed for Marlin 2.0.1 firmware.
Anyway, I think the only solution to the "OctoPrint not using the Z Offset" problem is to keep an SD card inserted so that the Z offset parameter can be stored in (and read back from) the EEPROM.dat file.
Creality, in their firmware, disabled using the onboard EEPROM for a lot of printers and save it to the SD card instead, who knows why. You can't mix and match here, if it is set in the firmware to use the SD card, it must do that, or it is set to use the onboard chip. Most of their boards do have actual onboard EEPROM they disabled...
Considering the number of bugs we see with Creality's firmware it's highly recommended to build your own or use some other source of firmware - but thanks for sharing one of the very likely causes of this issue.
It just reports what it is told by the printer, using the M115 command data. Creality (once again messing with things) changed the version numbers in their firmware so what was Marlin 2.0.x became Creality-Marlin 1.x...
I'm struggling with the same issue. I connected my Pi4 with octoprint to my standard ender 5 S1. When the printing starts it raises the bed till the nozzle and keeps going. What to do?
It's been over a year and I don't see anyone anywhere figuring this out. The Ender 5 S1 that uses the BL Touch for its Z reference is a very common printer. I'm surprised that there isn't anyone who has figured out how to make this work. I'd work on it, but Creality gives us nothing to work with and it isn't clear what Octoprint is doing differently than printing from the SD Card. Anyone?
The only thing that we've seen for this issue, referenced above is that you have to print with the SD card in. If you take the SD card out, it seems to get confused as the settings are no longer readable and can do strange things.
It's not the definitive solution - there are lots of issues with these printers and firmware. In general, people have fixed this by using different, non Creality firmware.
Tried that, no dice. I have an older Ender 5 S1 (with the Z Axis Limit switch at the bottom). All Creality firmware above V1.05 are for the newer version (without the Z Axis switch) - and they all hammer these machines. Clearly something else changed in the newer version. Creailty provides a Github repository with the source code of firmware but with version info and history. Don't know what that is for. I can't find a non-Creality firmware for it, but would like to. Just my luck to find the only printer on the market that won't work with OctoPrint...
Since Creality is blocking us from fixing their firmware... out of desperation I bought the $170 Creality Sonic Pad and Cam to get the functionality. It's almost like they planned it that way. Ok, they got me this time. But after buying two Creality printers I will NEVER buy another.
I was counting in the Sonic Pad to 'just work'. Spending enough money sometimes makes that happen. So, that's discouraging. Looks like TH3D has firmware for it. Does anyone know if Octoprint will work on an Ender 5 S1 with TH3D firmware installed?
For "anyone" to answer your question, they would probably need to have the same identical hardware as you do. Since the answer just involves installing firmware, you are in the unique position to answer your own question.
If it doesn't work, you just install the firmware you have now.
It most likely will. OctoPrint works with the vast majority of printers & firmware setups. TH3D is a well known vendor, and I understand that their firmware has no issues with OctoPrint.
Creality takes that firmware, and makes changes to it, normally adding a few bugs and broken parts to it, and then they release it with their printer. They could, of course, not add the bugs if they tried at all. I would not expect any of their products to have high quality software - whether you spend $170 on it or not, it comes from the same place.