As a replacement for the generic run-out sensor + plugin approach, I'm developing a new method which works with the idea that...
"if the filament itself isn't moving during a print job, that's bad".
So it should in theory cover problems which a run-out sensor wouldn't detect:
- jammed nozzle
- wrong temperature for filament
- broken filament past the run-out switch (from being too dry)
- filament stuck in the PTFE and/or notched filament at the feed gear
- cross-threaded filament on the spool (from hot-spooling at the manufacture or infused filaments)
- Raspberry Pi 3A+, power adapter and microSD (Raspbian Buster Lite)
- old-school Dell USB mouse
- printed parts to enclose the mouse
- a checkerboard pattern printed/pasted onto a ring of cardstock
- a C-based program to detect mouse events and to make calls to the REST API
- a plugin I'm developing: OctoPrint-Mouser
So I've got everything sort of working. The C program running on the client will forward the bump event to the plugin's Simple API interface if the interval is one second or more. The typical span between bumps is five seconds in my test rig here.
The plugin receives these calls. Each time it receives a bump while it's printing, it will set a 20-second timer and make the determination that the spool isn't moving if the timer has expired without another bump. All that seems to be working. If I snip the filament it promptly pauses the print job as expected. Otherwise it will just allow the print job to do its thing.
The problem appears to be that the sheer volume of messages on the REST API are too much. The job finishes, the print is done and the log just keeps logging those outstanding bump events...
...for at least an hour. I note that OctoPrint is running on a Raspberry Pi 3B.
So I'm thinking that the REST API really isn't the way to go for this. I probably shouldn't increase the low-end threshold for sending messages (say, to ten seconds or a minute) because that seems to defeat the purpose of early detection.
It feels to me as if the round-trip all to the API is too slow. It's possibly two to three seconds (when it starts to get busy). I could optimize the code but I don't think it will necessarily speed things up enough.
I could move the sensor and code then locally to the OctoPrint Raspberry Pi itself and then change out the inter-process communication, I guess. I just really liked the idea of creating a discreet IoT thing which could be added to an existing printer. (Bah, humbug.)