[GUIDE] Octoprint + (stock) Filament runout detection

I finally sat down and worked through getting runout detection working in octoprint using the stock sensor, so I figured I should put it up here in case others want it as well.

Prerequisites

  1. You must set your slicer to use relative extrusions. I use Prusaslicer, and the setting is called “Use relative E distances”. IHNI if luban supports it, but let’s be honest, if you’re using octoprint, you’re probably not using luban :slight_smile:
  2. You should have octoprint set up already, and understand how any settings you’ve configured that aren’t mentioned in this guide may affect the runout resume process.
  3. You will need to install the Terminal Response plugin for octoprint (use the plugin manager).
  4. You will need to flash new firmware to your machine:
    Snapmaker_V4.7.2A_20250115.zip (170.1 KB) (see below for detailed instructions).

Setup

  1. Install the Terminal Response plugin. You should be able to do this using the plugin manager in octoprint.
  2. Go to octoprint settings > GCODE Scripts and set up the following:
GCODE Scripts
Before print job starts
M75
After print job completes
M77
After print job is cancelled
M77
Before print job is resumed
; ======= OCTOPRINT RESUME START =======
M77
M75
; ======= RELOAD POSITION =======
{% if last_position.x is not none %}

; absolute XYZ
G90

; move back to pause position XYZ
G1 X{{ last_position.x }} Y{{ last_position.y }} Z{{ last_position.z }} F4500

; reset to feed rate before pause if available
{% if last_position.f is not none %}G1 F{{ last_position.f }}{% endif %}
; relative E, since octoprint extrude sets to absolute
M83
{% endif %}

  1. In octoprint settings > printer > serial connection disable both Log position on pause and Log position on cancel.
    When this setting is enabled, octoprint sends a M114 after the pause, which causes a loss of the Z position when resuming the print. I tried using this and pause_position, but it wasn’t working correctly for me in octoprint Version 1.10.3
  2. In octoprint settings > plugins > Terminal response add a response:
Terminal response

regex
Filament OUT
command

M114
M600
M76

  1. Save the settings
  2. Install my custom firmware: Snapmaker_V4.7.2A_20250115.zip
Firmware installation
  1. Download the firmware
  2. Unzip it
  3. Place the firmware on a USB stick (for my machine, only the stick that came with the machine seems to work, so probably best to use that)
  4. Plug the USB stick into the machine
  5. Go to Files
  6. Go to USB
  7. Click the .bin file
  8. Agree to the prompt to install

If installing the firmware didn’t reset your octoprint connection, you should probably disconnect/reconnect (or even just reboot your Snapmaker) to make sure all the settings take effect.

Usage

Unfortunately, even with everything done, it’s still a bit of a hacky setup in octoprint to be able to use the filament runout sensor.

  1. Start a print
  2. Run out of filament (I tested this many times by just cutting the filament right above the extruder)
  3. The machine should now automatically move to the park position (“top right”)
  4. Octoprint will look to be unresponsive (all buttons grayed out)
  5. Go to the terminal tab, and expand the Advanced options
  6. Click Fake Acknowledgement
  7. You can now use octoprint to feed in some filament via the Control tab
    WARNING: The first extrude command seems to go super fast for me, I set my extrude amount to only 5mm and do multiple extrudes. The subsequent extrudes will be at the right speed.
    NOTICE: I have not tested feeding filament into both extruders, if you do this, make sure to set the tool back to the right tool that was active at the time of pause, octoprint doesn’t have a good setup to restore the active tool when the filament ran out and will just restart the print with whatever tool is currently active.
    FURTHER NOTICE: The setup I’ve detailed does not do anything to restore the bed/tool temperature, so make sure you don’t change those since your slicer probably doesn’t update the temp, so the print will continue with whatever setting you set last.
  8. Once the filament is fed in, it’s probably best to back out ~5mm to prevent filament leaking
  9. Click Resume in print controls

FAQ

Why does it require a custom firmware/does this include the vibration compensation branch?

Unfortunately, the stock firmware actually disables the runout detection when printing from anything other than the screen or luban (which goes through the screen). The change to enable runout detection is quite simple and I’ve opened a pull request for the Snapmaker team to look at.

@Zoe or @Alan it’d be great if the pull request could be included in the next release (and the vibration compensation branch) so people don’t need to install a custom firmware. Also, if you pointed me at a repo for the vibration compensation branch, I’d be happy to make a pull request there as well.

Alternatively, if someone else wants to dig through the firmware to find somewhere where there’s a gcode command that lets us set the systemservice.cur_status_ to SYSTAT_WORK, then we could use that instead of M75 that I made work in my custom firmware (but I looked and didn’t see anything).

Will this work on the J1

No, it’s a different firmware and the problem is probably different (runout detection seems to go through a totally different code path).

Will this work with the single extruder

Probably? I’ve honestly never plugged my single extruder back in after getting the dual extruder, so IHNI if things are different there (but e.g. the M600 code appears to run single extruder functions, even when the dual extruder is connected).

Can you make the usage process simpler/less hacky?

I didn’t see why the fake acknowledge is required, there doesn’t seem to be anything explicitly in the firmware code that sends the acknowledge that octoprint expects (for any gcode command), so I don’t know what octoprint is expecting. It could also be that the M600 is the problem, but that seems to be what triggers octoprint to see the M76 as a runout instead of just a pause. You could probably also set a macro that includes a reasonable feed speed so you don’t need to feed 5mm at a time. However what I’ve done works, and works consistently to go back to the correct spot in the print to resume printing.

6 Likes

Totally awesome! Thanks for digging into this, and Snapmaker, please consider to add it to the official firmware!!!

Thats great News. Hopefully snapmaker will add that.
But i have still one problem with octoprint in some cases: that i cannot Change z level while printing as snapmaker provide it in Touchscreen. It is a useful option. The babystep addon did not work for me. How do you handle that?

Yea, baby stepping might be the next thing I look at. AFAIU, it’s currently only available via a special message from the touch screen (i.e. the touch screen uses SerialConnection instead of gcode). It would need to be another firmware modification to make it work.

1 Like

Thanks for this, but its just a bit too complicated at this stage, maybe Gina from octoprint could make a minor change to make it a bit more friendly and Snapmaker include your suggestion so we don’t need special firmware so we can still update to the latest as they happen. Keep up the good work.

I had previously tried enabling HOST_ACTION_COMMANDS , HOST_PROMTS, and ADVANCED_PAUSE_FEATURES, but none of those led to the filament runout being sent to Octoprint. Your changes worked! But when it finally runs out Octoprint keeps receiving:

Recv: echo:busy: paused for user

This is continuous, and while the Fake Acknowledgement works to enable the extrude button on the control panel, the printer doesn’t respond to any commands so I can’t reload the filament. Any idea if this is due to a conflict between those enabled definitions and your edit?

Tim

Hmmm, it could be that or it could be if there were some changes made since I posted this. I haven’t been able to touch my printer basically since I posted this, so I’m not sure if there’s a firmware update that maybe broke things.

Hey, @nivekmai massive props and thanks for your work on digging into this!

I keep getting erroneous Filament OUT messages from the firmware, that as you can see from my logs are then quickly corrected within 0.8s with a Filament IN

this causes my print job to pause unnecessarily, this is not an issue when printing from luban/touchscreen - I’m not sure if they’re behaving differently with a ?

I wondered if you’ve also observed this and if you’ve got any advice on how to mitigate this, perhaps in octoprint config to give it a second or two before pausing?

Thanks in advance for any thoughts!

2025-07-03 17:00:53,656 - Recv: ok
2025-07-03 17:00:53,657 - Send: N937733 G1 X289.479 Y219.269 E.07091*105
2025-07-03 17:00:53,672 - Recv: ok
2025-07-03 17:00:53,673 - Send: N937734 G1 X290.004 Y219.646 E.07699*111
2025-07-03 17:00:53,689 - Recv: ok
2025-07-03 17:00:53,690 - Send: N937735 G1 X290.531 Y219.948 E.07213*106
2025-07-03 17:00:53,827 - Recv: ok
2025-07-03 17:00:53,828 - Send: N937736 G1 X291.041 Y220.178 E.06663*105
2025-07-03 17:00:53,851 - Recv: ok
2025-07-03 17:00:53,851 - Send: N937737 G1 X291.333 Y220.279 E.0367*91
2025-07-03 17:00:53,874 - Recv: Filament OUT
2025-07-03 17:00:53,934 - Recv: ok
2025-07-03 17:00:53,934 - Send: N937738 M114*22
2025-07-03 17:00:53,943 - Recv: X:291.33 Y:220.28 Z:6.40 E:1663.19 Count X:127331 Y:94621 Z:19978 B:0
2025-07-03 17:00:53,943 - Recv: ok
2025-07-03 17:00:53,943 - Send: N937739 M600*21
2025-07-03 17:00:53,952 - Recv: ok
2025-07-03 17:00:54,403 - Recv:  T:205.50 /205.00 B:65.34 /65.00 T0:205.50 /205.00 T1:39.90 /0.00 @:0 B@:0 @0:0 @1:0
2025-07-03 17:00:54,431 - Send: N937740 M76*44
2025-07-03 17:00:54,683 - Recv: Filament IN
2025-07-03 17:00:55,002 - Recv: MC REQ PAUSE
2025-07-03 17:00:55,002 - Recv: SC req PAUSE
2025-07-03 17:00:55,005 - Recv: SC req -> Success
2025-07-03 17:00:55,005 - Recv: ok
2025-07-03 17:00:55,005 - Changing monitoring state from "Printing" to "Pausing"
2025-07-03 17:00:55,010 - Changing monitoring state from "Pausing" to "Paused"
2025-07-03 17:00:55,010 - Recv: QS recorded pos X: 323.332, Y: 243.280, Z: 6.201, E: 1663.175
2025-07-03 17:00:55,017 - Recv: QS at logical pos: X: 291.332, Y: 220.280, Z: 6.401, E: 1663.175
2025-07-03 17:00:55,017 - Recv: leveling OFF
2025-07-03 17:00:56,404 - Recv:  T:204.80 /205.00 B:65.34 /65.00 T0:204.80 /205.00 T1:40.00 /0.00 @:127 B@:0 @0:127 @1:0
2025-07-03 17:00:58,399 - Recv:  T:204.50 /205.00 B:65.34 /65.00 T0:204.50 /205.00 T1:40.00 /0.00 @:127 B@:0 @0:127 @1:0
2025-07-03 17:01:00,400 - Recv:  T:205.20 /205.00 B:65.26 /65.00 T0:205.20 /205.00 T1:40.00 /0.00 @:0 B@:0 @0:0 @1:0
2025-07-03 17:01:02,404 - Recv:  T:205.90 /205.00 B:64.99 /65.00 T0:205.90 /205.00 T1:40.00 /0.00 @:0 B@:0 @0:0 @1:0
2025-07-03 17:01:04,389 - Recv:  T:206.10 /205.00 B:64.80 /65.00 T0:206.10 /205.00 T1:40.00 /0.00 @:0 B@:127 @0:0 @1:0
2025-07-03 17:01:06,399 - Recv:  T:205.60 /205.00 B:64.80 /65.00 T0:205.60 /205.00 T1:40.00 /0.00 @:92 B@:127 @0:92 @1:0

I have not seen that, mine’s pretty consistently correct. It sounds like a hardware issue to me.

If you want to solve it in software I think the best step would be to enhance the filament response plug-in with the delay functionality you’re hoping for.

1 Like

Thanks for coming back!
Will try the other nozzle and it’s probably due a proper clean
:folded_hands: