[BUG] Runout sensor not pausing print immediately

[Zol-Tank]

Description

When the filament runout sensor trips the print doesn't immediately pause and will keep printing for several seconds. This cold potentially feed the filament beyond the toothed gear and make changing it difficult.

Steps to Reproduce

1. Print
2. Trip filament runout sensor

Expected behavior:
The print to immediately pause when the sensor is tripped.

Actual behavior:
It keeps printing for several seconds.

Additional Information

I have the BLOCK_BUFFER_SIZE set to 64 and the BUFSIZE set to 16. I'm not sure if this is how pause works, but maybe it's finishing all the gcode operations in cache before pausing, so it's taking longer for it to pause in my case.

Marlin.zip

[reloxx13]

do u use octoprint for the sensor? or directly with marlin?

[Zol-Tank]

Direct to Marlin.

[InsanityAutomation]

Do you have anything defined with #define FILAMENT_RUNOUT_DISTANCE_MM? It needs to finish its current command, however that shouldnt be too terribly high of a feed amount in most cases.

[Zol-Tank]

I don't. It's commented out.

[InsanityAutomation]

Can you confirm if it is finishing the current move only, or executing new moves after it? I typically run with a small amount there as a solid debounce personally so I havnt tested that code branch personally in awhile.

[Zol-Tank]

Can you confirm if it is finishing the current move only, or executing new moves after it? I typically run with a small amount there as a solid debounce personally so I havnt tested that code branch personally in awhile.

How would I do that? My test piece is a big single layer print (I also use it to adjust my Z offset) with a diagonal fill. If I trigger the sensor it will often finish the line it's on, start another one, and usually start even one more.

What is a "solid debounce"?

[InsanityAutomation]

For cheap sensors to prevent it from triggering on noise, or by getting stuck, I let it feed 5mm. Ill peek at how the command is queued sometime tonight and see if anything is amiss.

[Zol-Tank]

For cheap sensors to prevent it from triggering on noise, or by getting stuck, I let it feed 5mm.

I really like that idea. I'm stealing it.

[AnHardt]

This problem is already known for a while.
It's hard to solve.
For one of the older issues i wrote AnHardt#87.

[Zol-Tank]

This problem is already known for a while.
It's hard to solve.
For one of the older issues i wrote AnHardt#87.

Then I was correct in assuming my large buffer is the main culprit in the abnormally long time it takes to stop after the filament out sensor is tripped?

[InsanityAutomation]

Mostly. M600 should go to the front of the queue so it can execute as quickly as possible, however there may be quite a bit of moves planned before it get to the pause action unfortunately.

[ManuelMcLure]

I wouldn't want an explicit M600 that's explicitly in my gcode (for a color change, for example) to execute before the preceding move in the gcode file had completed. An M600 introduced by filament runout is a different matter, of course.

[InsanityAutomation]

Yup, that's the only way it could! Edit : LCD menu triggering it could too.

[Zol-Tank]

Mostly. M600 should go to the front of the queue so it can execute as quickly as possible, however there may be quite a bit of moves planned before it get to the pause action unfortunately.

Thank you, that gives me something to work with. Since it's expected behavior, I'll just move my filament sensor further from my extruder.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.