Octoprint ignores Z-Offset, nozzle starts too low at random heights

Get Help
1

I just installed an Octo/RaspberryPi combo on my CR-10 running TH3D firmware and an EZABL. Everything was running fine before Octoprint. When I send prints through Octoprint, the z-offset is way off every time. It's so low that filament won't even come out. I have to baby step out of it.

After research, facebook groups, and reddit, I tried redoing the entire z-offset and EZABL tuning process again to start fresh. I did 2 thin first layer test prints that worked just fine with my Z-offset set to -1.950, which I found through setting up the EZABL. One print was straight from the SD, the second pushed from Octo. Worked great. Just started a third print pushed from Octo and the nozzle is pressing into the bed hard enough that filament wont come out. Z-offset is still reading -1.950 on the LCD. I had to baby step back out to -1.325. The problem came back.

I can't figure out what is going on. Is Octo ignoring my z offset? Is something happening after the print is done where the printer loses it's Z value, which breaks the EZABL probing for the next print? Prints work fine from the SD directly on the printer. The stock TH3D firmware + EZABL was behaving normally before Octo.

Latest Octo print and pi version
Latest TH3D firmware
CR-10

Start code (from TH3D install guide):
M75 ; Start Print Timer and Engage Fil Sensor if USB Printing
G92 E0 ; Reset Extruder distance to 0
G1 E-2 ; Retracts filament to prevent blobs during probing
M84 E ; Disable E Motor for probe accuracy on direct drive systems
G28 ; home all axes
G28 Z ; home Z to get more accurate Z position
G29; EZABL mesh generation
G4 S10; wait for heaters to recover
(then extruder priming stuff)

I'm going to go back and start all over again and do logs while I repro the issue, so hang tight for those.

Thanks!

2

In a case like this, I think I would visit the Control tab of OctoPrint and run some manual Gcode commands without heating anything or turning on the fans.

G28 X0 Y0
G28 Z0
# Observe where your extruder is in relation to your bed.

For my printer, homing Z pushes the movable bed all the way to the floor. And then I might move the extruder to the center of my bed:

G0 X60 Y60

Actually, it would be easier to just use the jog commands on the Control tab.

Then use the jog commands to bring things together: (I don't remember if I do "up" or "down" on this, but I'm moving the bed up) up 100mm, up 10mm * 4, up 1mm, etc. I've got a piece of paper sitting on the bed and I'm noting how far this takes. For my printer with a Buildtak sheet on the bed, I know that I want it so that the extruder pinches the paper a little; it takes a small tug to pull the paper as trapped between the extruder and the bed.

In this way, you can deduce what the z-offset could be from what the current settings are as saved in your printer's EEPROM.

I use the EEPROM Marlin Editor plugin to adjust mine since I'm not fond of using other means to do so. For a while, I was printing on two completely different beds and their heights were different; I spent a fair amount of time figuring all this out.

For you, I would very much recommend that you install, configure and use the excellent Bed Visualizer plugin. If I remember correctly, it has to install numpy so don't be surprised if this takes a lonnnng time to install. The fruit of all this is to have a visual representation of your bed after that G29 autolevel command has finished; it's a visual representation of what that determined about this "virtual plane" that it's generated for you. This is important since that leveling routine will determine what happens during your print jobs.

Lastly, you should know the different between absolute and relative movement modes in Gcode. If you get this wrong it's easy to drill your hotend into your bed and to do other damage to your printer.

3

Thanks for your reply, but I think you may be missing my issue. I don't have a problem finding out the proper z-offset for my setup. Zero confusion here. I have my printer working perfectly with TH3D firmware, an EZABL, and a properly setup z-offset. My printer auto-homes just fine (G28) via the control box, or sending a G28 command. EEPROM works, I can change my z-offset whenever, and update the EEPROM with the new setting. The setting sticks as well. I can print from my SD card inserted into the printer without fail, every time.

The problem I'm having is I send a .gcode file from Octoprint, in my browser, to my printer, it disregards all my z-offset settings on the printer or the firmware, or at least, that's what it appears to be happening.

4

Here's an update after more testing (problem persists)
-Printed a single layer "first layer test" from straight off printer SD, printed fine
-Printed a single layer "first layer test" from Octoprint, printed fine
-Turned off printer, kept Raspberry Pi on
-Powered printer back on, z offset readout is correct
-Printed a single layer "first layer test" from Octoprint, nozzle jammed into bed. Z position reads out normally
-Canceled print
-autohomed
-Z axis now reads 5.3, instead of 5 (correct for TH3D firmware)
-Restarted printer, auto homed, Z axis reads 5 again, Offset is correct still
-Printed straight from printers SD, nozzle jammed into bed

5

At any point when your motors are trying to move and they are prevented in any way from doing so, the where-am-i audit is bound to be wrong after that. I'm sure people may argue this point but what I've learned from experience is that any time you ask for a move and something prevents that, it's a good idea to stop, home all three axes, run a G92 at this point and then try to resume or just bail on the job entirely. There are times when this is true of the extruder as well (if you've managed to jam up the hotend) but it's not quite so dire.

For what it's worth, here's my OctoPrint -> Settings -> GCODE Scripts -> Before print job starts

G91            ; Set to relative positioning
G28 X0 Y0 Z0   ; Home all three axes
G90            ; Set to absolute positioning
G92 E0         ; Set position (zero out) the extruder
G29            ; Run the autolevel routine

Before I added the G28 like this, I note that OctoPrint would be confused about where it actually is.

And yet, it's not too different from yours.

For most printers and Z accuracy, it's necessary to run it to one of the endstops and then walk it back.

You might try a small test print without the autolevel routine. It's entirely possible that there's something going on with your probe. I'm guessing you didn't install the visualizer which would have given you some insight into your bed and how much your leveling routine is trying to inject into your jobs. (Alternately, hold your thumb/finger lightly on the z-screw while that single-layer is being printed; is it moving while the single layer is being printed? If yes, then maybe your bed is super-warped.)

6

The motors aren't getting stuck trying to get away from the bed, they are purposely driving the hot end towards and into the bed. Nothing is preventing the move. Before Octo, things were good. I even tried moving my Z manually from the printer's controlbox all the way up to see if anything is making it difficult. Smooth as butter.

Not trying to resume a print or fix mid print, I'm just trying to get the first layer to exist. When I start it, and the z offset is essentially ignored, I baby step out while its doing a few layers of rim, and its fine the rest of the print. In last nights case, a 10 hour print. I shouldn't have to baby step every print. The stock printer has never needed this. My goal here is to send a print from Octo and walk away, just like I did when I would print straight from the SD on the control box. Unable to even start a print correctly, we'll get to resuming and bailing on prints when I'm able to get past the first layer :slight_smile:

Visualizer is and has been installed. I even was using one before I got Octo by sending a G29 from Pronterface, and pasting in the coordinate info it spat out to an external visualizer. ABL was working, making a mesh, and using it from what I could tell from the quality of my test prints.

Thanks for the suggestion, I tried this earlier. Ran a G28 on power on of printer, before print and after bed leveling. Problem still happened.

Like I said, Z accuracy has never been an issue or needed any sort of tuning. Printer was fine, I hooked Octoprint up, 10 min later, z accuracy is all over the place.

So I narrowed it down to a few things. It has to be the probe, or something about the Octoprint setup, firmware/software or hardware, that isn't playing nice with this probe.

I can print 100% fine now with Octo and NO probe, no G29, etc. Powered printer and RaspberryPi on and off, started another test print, still fine. Something related to the EZABL + Octo is causing issues. One cannot exist with the other. For the meantime, I've put the EZABL probe setup to the side in a box-o-shame, while I enjoy normal printing from Octo. I'd rather deal with a slightly warped bed and some money lost than deal with that probe again. Thanks for the help! Although its unresolved, I've found a way to use my printer again.

1 Like
7

I contracted for a while at Robo 3D, a San Diego—based printer manufacturer. Probes are problematic, I'll have to say that (especially the IR type). I've seen times when you'll ship a printer and you've tested it like crazy, the end-user slaps blue tape over the bed and it works fine. Another user slaps green tape over the bed and the hotend drills into the bed. :facepalm:

Feel free to create an issue on the OctoPrint repository regarding this printer, the type of probe and what you're experiencing. A drilled hotend is no fun; you should see my current (scarred) print bed.

And for what it's worth, I completely redesigned two aspects of my own printer's leveling. Once I did that, things ultimately became beautiful.

1 Like
8

Folks - I'm having same problem - HOWEVER I have no auto-bed-leveler. I have an Ender 3 with the factory firmware and OctoPi on latest code. My Z offset seems to be ignored. Im going to try and print from SD and from Cura. If Z offset can't work with Octoprint reliably I dont know how I can keep using it. Grumble.

9

Dang. I ruled my issue out by removing my ABL from the equation. Curious to see what your results are without octo. I feel like the same .gcode file sent via SD card right on the printer should print the same exact result as uploading to your Pi via Octoprint. Curious about your results.

10

I just printed a GCODE file stored on the SD Card straight from the LCD panel of the printer - Z Offset still ignored. Im also very new at this, (first printer - have it about 3 weeks) but maybe this is exclusively a printer firmware prob? I just assumed Z Offset (being set in the printer hardware after all) is something the slicer making GCODE and the print controller would not need to be aware of, and that the printer firmware just added that value to all Z positions received.

To be extra sure I disconnected OctoPi, rebooted printer, checked that Z Offset was still set, and ran a print local from printer SD via LCD panel again. Same prob- ignoring my offset.

I'll poke around the Ender 3 forums and I'll read up on Z Offset in Marlin docs. This stinks. I'm trying to print a few layers onto the surface of another object, which is on the print bed and is approx 2mm high. Don't want to manually hack the GCODE fixing every Z coordinate. Yikes.

11

So the problem still happens without Octo, then Octo isn't causing the issue, and you're going to find answers faster on a different forum probably. Sounds like it is maybe Marlin related maybe? I highly recommend joining a facebook group for your printer. I've learned a lot from the CR-10 group I'm on, had questions answered quickly, etc.

12

Also, I would recommend an X/Y/Z home after every bootup of your printer/OctoPrint. It just seems to help.

13

I use two different headers in my gcode. Done by Slic3r. One is the global gcode options for the printer. This calls up my presaved mesh in the eeprom and add a fade etc.

Then I have a second header that is executed after the global header. This is one per filament. I use do this as different filaments like different amounts of squish.

I alter these z offset values and determine what is a good off set and then stick with that.

here is that gcode.

G1 Z0.30 F500  ; Go to the level of 0.3mm for Z-offset
G92 Z0       ; This redefines the zero Z level
2 Likes
14

I run the same Code Script from Simplify3d as I do in Cura, MatterControl and the new Pathio from E3D.

M75 ; Start Print Timer and Engage Fil Sensor if USB Printing

G92 E0 ; Reset Extruder distance to 0

G1 E-2 ; Retracts filament to prevent blobs during probing

M84 E ; Disable E Motor for probe accuracy on direct drive systems

G28 ; home all axes

G28 Z ; home Z to get more accurate Z position

G29; Determine Mesh

M500

M420 S1 Z10; Fade ABL compensation.

G4 S10; wait for heaters to recover

M117 Purge extruder

G92 E0 ; reset extruder

G1 Z1.0 F3000 ; move z up little

G1 X0.1 Y20 Z0.3 F5000.0 ; move to start-line position

G1 X0.1 Y100.0 Z0.3 F1000.0 E15 ; draw 1st line

G1 X0.4 Y100.0 Z0.3 F5000.0 ; move to side a little

G1 X0.4 Y20 Z0.3 F1000.0 E30 ; draw 2nd line

G92 E0 ; reset extruder

G1 Z1.0 F3000 ; move z up little

M117 Printing.....

And I have Zero Problems with OctoPrint losing my Z-Offsets. Until I learned that G28 turns off Auto Leveling I had the same issue as you're running into. Apparently when you runa G28 after all other G or M Codes it erases all Stored those codes and therefore it should be done first and never entered again once a print has been initialized. At least, that is what works for me. If as in other CNC Control Programs Marlin Provided Soft Limits there would never be issues such as these amonst so many of us.

1 Like
15

By the way, then you use this icon for formatting, you do not need interleave space lines:
grafik

eg:

M75 ; Start Print Timer and Engage Fil Sensor if USB Printing
G92 E0 ; Reset Extruder distance to 0
G1 E-2 ; Retracts filament to prevent blobs during probing
...
16

The replies about G23 are great - thanks so much. I will give a try and report back. In the interim, I have found that Ultimaker Cura (my slicer) has a plugin available for setting a Z Offset per job called "Z Offset Setting" in the Marketplace in community plugins.

17

Hi,

Have you resolved the issue? I had a similar issue. I know my Z-offset is correct but every time sending a print job from Octoprint. The Z-offset is off...

My resolution now is Turn on/off the printer, Set z-offset to zero then Set the correct z-offset. Click "X/Y" Home on Octoprint but do not click Z for home then print from Octoprint. If you click HOME on Z. Everything on z-offset is off again.

Printing again but need to wait until next project to see if I need to recalibrate the z-offset.

18

I have the EXACT same problem! I cant believe I found this thread. My problem is the following:

  1. Everything is fine when printing from octoprint
  2. Turn off printer
  3. Turn printer back on (Usually i have been clicking the Home ALL either from Octoprint, or from the printer it self). I am going to try to leave the nozzle somewhere in the middle of X,Y,Z and see if that helps)
  4. Reprint IDENTICAL g-code from octoprint, the nozzle now is WAY too close to the bed and starts to scrape against the bed
  5. Cancel the Job
  6. Press print on the exact same job, Everything is fine and prints fine.

Can you please tell me what you mean by setting z-offset to zero then the "correct" z-offset? I would really appreciate some help.

Thanks a lot!

Edit: I have no auto-leveling on my printer.

19

I'm experiencing this too.

I have a CR-10S with BLTouch. It worked great!

Installed Octoprint, and things went fine at first, but now the z-offset is ignored. At first it was ramming into the print bed, now it sits too high (and I'm not sure what I changed).

I'm wondering if it's some plugin somewhere, though, since it did work for a little while?

20

It's been a while since I went through this issue, but I how I originally solved it at the time was using TH3D's latest build of octo (instead of the regular octo) , getting a marlin update that came out shortly after my original issue, and going with a BL touch.

I never did figure out what was wrong. I am beginning to think there was a bug somewhere in a combination of marlin ver, octo ver, and the janky abl sensor that I determined to be faulty. Sorry I can't be more of help. I just changed enough things that it eventually worked out.