After Filament Runout Sensor was triggered, gives "State: Cancelling" when it is still actually printing normally

I am new to Octoprint and to the forum, this is the last thing giving me some trouble....

What is the problem?

Octoprint UI state is changed to "canceling" after a Filament Runout is triggered...

  1. Start OctoPrint and Printer
  2. Start a Print form SD - observe normal behavior
  3. Trigger Filament Runout Sensor
  4. Observe OctoPrint UI State. Says "State: Cancelling"

This error also occurs when Pausing a print from the SD.

Should not say "Cancelling" unless being canceled. The print, however, is still running normally.

Now any additional Filament Runout triggers do nothing, as well as cancel or pause from UI.

I can only "print from SD" to use the printers runout sensor. If I print from the UI the runout is NEVER triggered. I am not using a Pi


What did you already try to solve it?

Google Search
Different USB cables
Re-checked F/W
Found GitHub Bug Report #4862 - No help, but waiting on reply (original report started over one-year ago)

Have you tried running in safe mode?

Yes, the same results.
Tested in Safe Mode before saving this latest bundle.

Did running in safe mode solve the problem?

NO

Systeminfo Bundle

octoprint-systeminfo-20240719183102.zip (100.7 KB)

Additional information about your setup

Octo4A Server for Andoird
TronXY VEHO600 (basically an Ender)
MarlinFW 2.1.1
OctoEverywhere

THESE ENABLED IN F/W:

#define HOST_PROMPT_SUPPORT
#define ADVANCED_PAUSE_FEATURE
#define HOST_ACTION_COMMANDS

TIA!!!!

Linking comments on issue tracker. [BUG] After Filament Runout Sensor was triggered, gives `State: Cancelling` when it is still actually printing normally. · Issue #4862 · OctoPrint/OctoPrint · GitHub

Do you have anything set in OctoPrint's GCode Script settings for After print job is paused?

M25 is the standard Marlin command for pause SD print, but still doesn't answer why the printer thinks it got an M5.

Currently nothing in that script section. But I did find some sample scripts last night that I am going to try. It will have to wait till Monday tho.

{% if pause_position.x is not none %}

; relative XYZE

G91

M83

; retract filament, move Z slightly upwards

G1 Z+5 E-5 F4500

; absolute XYZE

M82

G90

; move to a safe rest position, adjust as necessary

G1 X0 Y0

; relative XYZE here so that you can adjust your filament via octoprint while paused

G91

M83

{% endif %}

So I added these scripts.

There is still an issue with printing from SD with runout and pausing.

But now I am able to trigger a runout from UI printing. But the notification that the Filament T0 runout is always present. Have to do some more digging.

Before print job starts

G90 ; use absolute coordinates
M83 ; extruder relative mode
M140 S80 ; set final bed temp
M104 S200 ; set temporary nozzle temp to prevent oozing during homing
G4 S10 ; allow partial nozzle warmup
M412 R S1 ;runout sensor
M412 D15 ;15mm post-sensor filament use, change if reverse bowden is replaced
M412 H1 ;enable host mode, so octoprint can respond
M413 S1 ;enable Power Loss Recovery
G28 ; home all axis
M75 ;Start Timer

After print job completes

M77 ;End Timer

After print job is paused

{% if pause_position.x is not none %}
G91
M83
G1 Z+5 E-5 F4500 ; retract filament, move Z slightly upwards
M82
G90
G1 X10 Y10 ; move to a safe rest position, adjust as necessary
G91
M83
{% endif %}

Before print job is resumed

{% if pause_position.x is not none %}
M82
G90
G92 E{{ pause_position.e }}
G1 X{{ pause_position.x }} Y{{ pause_position.y }} F4500
G1 Z{{ pause_position.z }} F4500
{% if pause_position.f is not none %}G1 F{{ pause_position.f }}{% endif %}
M412 R S1 ;Reset and re-enable filament runout detection
{% endif %}

Here is my latest bundle file with a safe mode test:
octoprint-systeminfo-20240725143520.zip (198.5 KB)

Still having this canceling issue with SD printing.

Question: When starting a print from the SD, from the UI, should the LCD display printing information? Mine is just the home screen on the LCD.

But here is another problem. The place with the printer has no internet. So I am using a Moto One 5g with Octo4A and Octoeverywhere. This way I can monitor (also with AI) my prints, which are all over 24hr ea. So I cannot use a Pi like a normal setup. I need to print from the SD because if I print from the UI octoprint "stutters" and the print gets jacked up. So printing from UI is a NOGO.

Going to try this setting next....

#define BLOCK_BUFFER_SIZE 64
#define BUFSIZE 32
#define TX_BUFFER_SIZE 32
#define RX_BUFFER_SIZE 2048

Since this topic is getting no where, I did tons of testing and I am now able to print from the UI with "virtually" no issues. So now the need for SD printing is a moot point. But there is still a bug issue with the printing from SD canceling status on runout and pause....

I have created a post outlining my working firmware and GCODE mods here: