Random fail on long print

[martin1951]

Have SFRS connected to Ender 3 Pro SKR Mini E3 V2 via Raspberry Pi using pins 1 (3.3V), 11 (GPIO17), and 9 (GND). Everything seems to work fine when tested by starting a print and cutting filament but several hours into a long print the pause/filament unload/reload cycle gets triggered that shortly after restarting the print is triggered again and can only be broken by turning off the printer. Have tried other pins with the same result. I do have an octoprint log of the print run that shows the point where the ‘Remaining distance’ parameter goes negative and the SFRS reports “no movement detected” followed by M600. This is a little strange since the log shows similar filament deltas earlier in the run that are large enough to be reported as detectable movement. I’d be happy to share the log with anyone with experience in understanding these reports. I think the SFRS has great potential but it’s a bit difficult to troubleshoot something that only seems to occur hours into a print.

[bulgaro80]

I have the same issue.... I'm using an Ender 3 V2 stock with RPi 4. Very often I need to disable the plugin to print... it's very sad...

[martin1951]

Good to know I’m not alone. I only enable the plug-in when it’s clear I’ll run out of filament within an hour or so.

[VRGhost]

I've looked into the code and I my main suspect is this line: https://github.com/maocypher/Octoprint-Smart-Filament-Sensor/blob/master/octoprint_smart_filament_sensor/__init__.py#L386

It appears that the plugin is parsing out the "E" (extrude command) out of the gcode octoprint sends to the printer and uses it as plain millimetre (mm) value to accumulate and compare against the mm reported by the sensor (7 mm per pulse).

Firstly, the gcode can have the default feedrate applying to commands without the "E" parameter as well as in-line feedrate changes ( check out the "Examples" section in the https://marlinfw.org/docs/gcode/G000-G001.html ).
Secondly, the sensor will always under-report the consumed distance as there will always be some slippage of the bearings in it, so each 7mm reported might be something like 7.1mm mm consumed.

I will try to confirm this, but the fix will require quite a bit of refactoring if my guesses are correct.

[VRGhost]

Alright, I have just managed to simulate the stall (attaching the logs and gcode)

CE4_Wall_Mount_Tool_Holder.aw.gcode.txt
octoprint(1).log
serial(1).log

There are quite a lot of feedrate change commands in the gcode, apparently. Might be due to me printing with PETG and hence having a very specific feed rates for walls/infill/etc.

[VRGhost]

Ok, so AFAICU, the way the code works is by allocating "Detection distance" mm after the sensors' pulse and subtracting any "extrude" lengths from that allocation on each gcode command sent. And it pauses the print when the allocation goes below zero.

This won't work reliably because a follow-up sensors' pulse may be delayed by a little bit of time either due to sensors' mechanics slippage or, say, by Python having a delay in processing the handler code for the pulse.

However, this will only be a problem if you've set the "Detection distance" value to the exact sensors' spec (7mm for BTT smart sensor). We should be fine if we set the "Detection distance" to something that is higher than that. This may explain why the default for the "detection distance" is 7*2 + 1 mm.

I'll try printing with the 15mm distance.

[cods69]

Everything seems to work fine when tested by starting a print and cutting filament but several hours into a long print the pause/filament unload/reload cycle gets triggered that shortly after restarting the print is triggered again and can only be broken by turning off the printer.

I still have issues using the sensor/plugin. Tried using the plugin since it came out but gave up on it as well as the sensor.
Posted a few times last year trying to find what was going on.
https://community.octoprint.org/t/need-plugin-for-smart-filament-runout-sensor/16512/35
Are there any suggestions on this random issue?
EDIT: Meant to be polite and say thanks for the work on the plugin so far, as well.