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)
Parts
- 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
Software
- a C-based program to detect mouse events and to make calls to the REST API
- a plugin I'm developing: OctoPrint-Mouser
Progress
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
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.
Thoughts
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.)
1 Like
In lieu of sending API calls to OctoPrint, what if you retrieve the API call from the OctoPrint side and handle all the bump logic local to the IoT device?
Thoughts? It's been done.
The main difference between this and @OutsourcedGuru's project is that it requires hard-wiring to the printer's control board, messing with firmware settings, etc. His solution is an attempt to provide something simpler I think that you could just install hardware, install plugin, all up and running.
I suppose... but it has to work.
Yeah... I'm thinking that all this mouse/cable/code has to move to the OctoPrint plugin to be honest. I just thought it was cooler as a separate device.
Or did you mean that the IoT device needs to send the pause command instead? But then, it would need to know if we're printing or not (or heating up or not) so I thought that might be a pain.
Do you want to create a service that writes to a unix socket which the API service can read; bypassing a lot of the http overhead?
I kind of just went through all this in another project, to be honest. The C program for the mouser client now uses sockets to POST to the REST API. It's possible that the plugin side of this isn't getting much "air" from OctoPrint so it's slow in responding, backing up the queue to the ridiculous level.
I could write a service on the OctoPrint Pi side of things but then I'd have to... actually, I could have that then just make the call to pause the job.
The problem is that something needs to know the state. It's printing or it's not. It's warming up for the print job or it's actively printing/extruding. That feels like the plugin since it's closest to that information. Trying to push the state management outside of the control of OctoPrint's umbrella means that I have to communicate state over to either the client or that service you're suggesting.
But if it runs too slow then, you got to.
you could use the BTT Filament break sensor connected to a GPIO pin on the Raspberry Pi watching for the pulses coming from the sensor. All the available plugins are for simple runout sensors which is just a micro switch sending either a high or low not a pulse. I'm sure your code could be modified to work with this.
Hi OutsourcedGuru! I'm working on a simpler solution - a magnet attached to the spool holder which triggers a reed switch at each revolution. If it stops triggering the reed switch for a certain amount of time, the print must pause or stop. What if anything is your current solution for filament movement monitoring?
I haven't pushed any of my code to github yet since it's not 100%. Half the code appears to be a plugin and the other half a C-based (or Python?) that talks to the mouse to get movement events.
Hard to know what that number might be unless you know what the printer is doing.
Obviously this is nothing new but I'm looking at a project that uses a 360 rotary encoder. Even if the printer for some reason is feeding then retracting it still won't trigger. Although you need to add electronics (a pic and perhaps a few discreats) you can create a simple trigger to mimic a filament runout detector. The obvious downside is inevitable extra load on the extruder.
Given that the accuracy of a $10 encoder isn't necessary I might just go with a 3d printed interrupter and whatever sensor is cheapest.
What I want to avoid is the printer printing nothing, either from a nozzle block or spool side filament jam, for many hours. So, if the timeout is quite long, say 5 minutes, the printer will be printing air for 5 minutes and then stop. Still a lot better than many hours.
From experience in testing my own plugin, there are times when the job will print a raft, say, and the assembly will have gone back/forth many times when tends to spool out a fair amount of filament. Next, if it's printing a small single part on a big raft it won't extrude much; the spool movement detection then won't really kick off for up to a minute in some cases. And I certainly don't wait for a full 360º revolution of the spool. That strikes me as being a good ten minutes in some cases.
Absolutely but isn't that what filament run out detector is for?
There are times when I'm sitting next to the printer, coding software and relatively oblivious to what's going on. I can hear movement and I can hear when there are certain suspicious sounds, for example I know the sound of filament snapping.
With relatively-immediate warning, I can just fix the problem without even a pause in the print job.
Trust the force, young Starwalker.
1 Like
After having a failure last night because of broken filament, I came across this thread. After thinking about it i guess it would be the best to additionally measure the extruders electrical signal or its rotation. Alternatively have a sensor before and after the extruder. If only one of the sensors detect movement, we can almost instantly detect a failure and report it to either octoprint or the printers mainboard. To cover some special cases it could be useful to do both and use all three sensors. (lack of extruder grip or if filament breaks at the extruder and then misses the ptfe Tube)
