This week’s project involves dealing with filament-delivery problems on my 3D printer. Out of the box, the filament runout detection never worked. Frankly, it was a terrible design to begin with from the manufacturer and I’m convinced that someone at the factory just turned off that behavior anyway.
As a result of this, I’ve lost a few print jobs over the last year. In only two cases, I simply ran out of filament for large parts. In all the remaining cases, a number of problems contributed to the loss of filament delivery to the printed part:
- simple end-of-roll loss of filament
- spool sticking to manufacturer’s poorly-designed spool holder
- cross-threading of the filament on the roll
- hot-spooling the filament at the factory which resulted in filament which sticks together
- filament like carbon fiber—infused which likes to stick to itself
- old filament which is now brittle and breaks as a result
- overall poor design of the spool (boxy) shape itself, resulting in cross-threading
- overall poor design of the filament delivery path itself, resulting in too much force needed to extrude
- filament thickness quality issues as combined with PTFE feed tubing, resulting in stuck filament in the tube
- too-flexible filament as combined with any of the conditions above, resulting in filament notching at the bowden gear
- z-offset too close to the bed, resulting in hotend jamming
- poor first-layer adhesion, leading to a build-up of filament and ultimate hotend jamming
Now granted, the bowden drive for this printer is one of the beefiest NEMA 17 style of stepper motors I’ve seen. And yet the number of filament delivery—related problems is just too high to continue to ignore. So I’ve decided to finally deal with the issue rather than working around it.
Ideas & inventions
Remove the stock holder, add bearings to its replacement
I designed, printed and assembled a very good dual-spool filament delivery system which worked much better than the stock filament holder. I sometimes still use it.
Dual runout switches
Perhaps six months ago, I designed, printed, sourced parts for and assembled a very good dual-spool filament runout detection block to replace the stock part. I have yet to install it since I’m not in love with the idea of the filament path beginning at the table level. Time has taught me that the spools need to be higher than the printer for this to be optimal. As designed, though, it works in principle to detect loss of filament from both spools.
And yet, this entire concept does not directly address the problems associated with cross-linked filament. It only addresses the loss of filament as seen in a switch.
Parabolic spool guides and re-purposed monitor stand
Additionally, I designed, printed and assembled parabolic spool guides to better deliver filament (especially for hot-spooled or otherwise sticky filaments like carbon fiber). This I combined with a designed/re-purposed dual-monitor stand to move the spools above the printer rather than below.
Remove the temperature gradient
First-layer adhesion was aided by adding a foam enclosure/door and a temperature-monitoring Raspberry Pi 3B to the inside (opposite the internal webcam). The latter helps to heat up the print volume area, keeping things from 90-100 degrees Fahrenheit.
Remove the PTFE tubing
Filament diameter inconsistencies resulted in filament getting stuck in the PTFE tubing. I now rarely route the filament through the tubing, having removed the awkward bottom-to-top filament delivery path from earlier.
And finally, a filament movement detection mechanism
This weeks work then revolves around fixing the underlying problem. The solution isn’t filament runout detection. The more accurate problem and better solution is actually loss of filament movement and its detection.
When I began to think of solutions, in my head I was adding black/white encoder rings to the sides of the spools themselves. I would need to add those to all spools of course. I’d also need to design something which reads those as ones and zeroes.
I decided that a roller/follower which is turned by the spool is also a solution. I then envisioned writing drivers and creating a small circuit board for all this so that it could talk to Raspbian, the operating system which OctoPrint runs on.
Mouse to the rescue
Finally, it hit me that a standard computer mouse does this naturally. The older style of ball mouse has a follower which detects when the ball is moving. Even the newer style of mice still have a scroll wheel which is covered in rubber and would do nicely. In my imagination, the first iteration of this had the filament trapped against that rubber wheel. In today’s version, the wheel merely comes in contact with the side of the spool itself for the win.
As a bonus, the computer mouse already has the serial communication and Linux driver built-in. It was trivial to write a small Python script to detect scrolling events.
no mice will be harmed … in the making of this gadget.
The mouse should fit nicely and without any modifications to a 3D-printed holder. The serial connection goes to the Raspberry Pi and is then detected in an OctoPrint plugin. During a print job the scrolling events will be monitored; any loss of scrolling over the sampling period will then pause the job and alert the operator with a sound event.