[BUG] Unpredictable filament runout/clog false positives. Runout remaining seemingly inaccurate/slow-update count.

[nikkoderic]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I have a smart filament (motion) sensor installed with an advertised resolution/runout-distance of 7mm. I've been getting unpredictable runout/clog false positives few times during hour-long prints. At first, I tried increasing the runout-distance via LCD to mitigate the problem. I was only able to reduce the likelihood of a false positive when I increased the runout-distance to greater than 10mm.

In an attempt to diagnose the problem myself, I enabled FILAMENT_RUNOUT_SENSOR_DEBUG (originally absent from config files). Using pronterface, I was able to see whenever the sensor changes state and monitor the "Runout remaining mm" value.

So I was able to observe Marlin printing "Motion detected: 0" whenever I manually push filament through the sensor, getting prompt response on pronterface. However, it seems that the counter is inaccurate and/or slow to update. I can feel the extruder and filament moving but the value does not immediately correspond to the actual extruded length.

Here is the log from pronterface:
printlog.txt

Please note that I use SD card for printing and only use pronterface for serial monitoring.

Bug Timeline

No response

Expected behavior

• No false positive with proper runout-distance
• Runout remaining mm value to properly correspond to the actual length extruded
• Runout remaining mm value to immediately reset to 7mm (FILAMENT_RUNOUT_DISTANCE_MM) when Marlin detects movement of the sensor

Actual behavior

• I am getting false positives even when substantially increasing the runout-distance from the suggested value
• Runout remaining mm value is slow to respond or update value even if filament is obviously passing through the sensor consistently
• Runout remaining mm value does not immediately reset even when Marlin have detected movement of the sensor

Steps to Reproduce

1. Slice model using Cura and store to SD card
2. Connect pronterface for serial monitoring
3. Print gcode from SD card
4. Wait for few minutes to hours
5. Printer initiated M600 (false positive)

Version of Marlin Firmware

bugfix-2.1.x

Printer model

Creality Ender 3 Pro

Electronics

Stock v1.1.4 (8-bit) utilizing extra pins for a 3DTOUCH and a filament mortion sensor

LCD/Controller

Stock LCD

Other add-ons

bowden 500mm, stock hotend, BTT Smart Filament Sensor v1, and 3DTOUCH

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

SD Card (headless)

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

The BTT Smart Filament Sensor v1 is immediately right before the extruder stepper.

I also checked the output of the BTT Smart Filament Sensor v1 on the oscilloscope and multimeter and it seems to be okay. I also tried with and without internal pullup, problem persists.

My Configuration.h and Configuration_adv.h:
Configurations.zip

RAM and Flash usage of the current configuration:

[PanosPetrou]

I would change #define FILAMENT_RUNOUT_DISTANCE_MM 7 to 25 and recheck.

[nikkoderic]

I would change #define FILAMENT_RUNOUT_DISTANCE_MM 7 to 25 and recheck.

Thanks for the suggestion.

I tried messing around with the runout .h and .cpp, adding serial echos to monitor at what point it would false trigger but thats when it just finished the print without any problem even at runout distance of only 7mm.

I am thinking if it was actually just momentarily slipping or was having hard time pushing material through.

Ill just post another issue if it persists and I am certain of why and how.

[PanosPetrou]

Sure you could increase FILAMENT_RUNOUT_THRESHOLD in runout.h, however some people also mentioned false positives when using runout distance of 7mm and the false positives stopped when used 25, that's why I suggested it.