Bug: Filament Jam Treated as Fatal Abort Instead of Recoverable Pause (Inconsistent with Runout Handling) #1197

New Issue

MrUnknownDE · 2026-04-05T16:59:43+02:00

MrUnknownDE commented

2026-04-05 16:59:43 +02:00

Originally created by @donaldvintika-creator on 1/3/2026

Is there an existing issue for this problem?

I have searched the existing issues

OrcaSlicer Version

2.3.1

Operating System (OS)

Windows

OS Version

11

Additional system information

CPU: Intel Core i7 11th Gen
Memory: 32 GB
GPU: NVIDIA (exact model not relevant to issue)

Issue is not hardware performance or rendering related.

Printer

Klipper based printer (Voron class)

How to reproduce

Start a print with sufficient filament loaded
During the print, induce a filament jam or extrusion fault (e.g. spool tangle, excessive drag, filament caught on holder)
Observe printer behavior when jam is detected

Actual results

When a filament jam or extrusion fault is detected, the print is immediately aborted.

The job is terminated, the print cannot be resumed, and otherwise valid work is lost even though the issue is external and user recoverable.

Expected results

For the purists and armchair maintainers up front: sorry, this is a bug.

If two fault conditions result in the same physical outcome no filament is being extruded then treating one as recoverable and the other as fatal is an inconsistency, not a feature.

Filament runout pauses the print, parks the toolhead, allows user intervention, and resumes successfully.

Filament jam or extrusion fault should follow the same recovery path, or at minimum provide a user configurable option to do so.

Expected behavior:
• Pause the print
• Park the toolhead safely
• Maintain temperatures
• Prompt user to clear the jam
• Resume print on explicit user confirmation

In the rare case of a true hardware failure, resuming does not introduce additional risk. If extrusion cannot continue, the user can still abort manually, resulting in the same outcome as the current behavior but with an opportunity to recover.

Project file & Debug log uploads

Not applicable for this issue.

This is not a slicing, geometry, project configuration, or gcode generation issue.
This is a fault classification and state handling issue triggered during active printing.

Relevant logs would be firmware side rather than project specific.

Checklist of files to include

Log file
Project file

Anything else?

This behavior appears to be an implementation gap rather than an intentional feature.

From a control systems perspective, filament runout and filament jam represent the same terminal condition: commanded extrusion is not occurring.

Runout is treated as a recoverable consumable interruption. Jam detection is treated as a fatal error. In real world usage, the overwhelming majority of jams are external, transient, and user recoverable.

Aborting long prints in these cases wastes material and time without providing additional safety.

This is a fault handling inconsistency, not a request for new functionality.

*Originally created by @donaldvintika-creator on 1/3/2026* ### Is there an existing issue for this problem? - [x] I have searched the existing issues ### OrcaSlicer Version 2.3.1 ### Operating System (OS) Windows ### OS Version 11 ### Additional system information CPU: Intel Core i7 11th Gen Memory: 32 GB GPU: NVIDIA (exact model not relevant to issue) Issue is not hardware performance or rendering related. ### Printer Klipper based printer (Voron class) ### How to reproduce 1. Start a print with sufficient filament loaded 2. During the print, induce a filament jam or extrusion fault (e.g. spool tangle, excessive drag, filament caught on holder) 3. Observe printer behavior when jam is detected ### Actual results When a filament jam or extrusion fault is detected, the print is immediately aborted. The job is terminated, the print cannot be resumed, and otherwise valid work is lost even though the issue is external and user recoverable. ### Expected results For the purists and armchair maintainers up front: sorry, this is a bug. If two fault conditions result in the same physical outcome no filament is being extruded then treating one as recoverable and the other as fatal is an inconsistency, not a feature. Filament runout pauses the print, parks the toolhead, allows user intervention, and resumes successfully. Filament jam or extrusion fault should follow the same recovery path, or at minimum provide a user configurable option to do so. Expected behavior: • Pause the print • Park the toolhead safely • Maintain temperatures • Prompt user to clear the jam • Resume print on explicit user confirmation In the rare case of a true hardware failure, resuming does not introduce additional risk. If extrusion cannot continue, the user can still abort manually, resulting in the same outcome as the current behavior but with an opportunity to recover. ### Project file & Debug log uploads Not applicable for this issue. This is not a slicing, geometry, project configuration, or gcode generation issue. This is a fault classification and state handling issue triggered during active printing. Relevant logs would be firmware side rather than project specific. ### Checklist of files to include - [ ] Log file - [ ] Project file ### Anything else? This behavior appears to be an implementation gap rather than an intentional feature. From a control systems perspective, filament runout and filament jam represent the same terminal condition: commanded extrusion is not occurring. Runout is treated as a recoverable consumable interruption. Jam detection is treated as a fatal error. In real world usage, the overwhelming majority of jams are external, transient, and user recoverable. Aborting long prints in these cases wastes material and time without providing additional safety. This is a fault handling inconsistency, not a request for new functionality.

Sign in to join this conversation.

No Label bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#1197