Prototyping with Raspberry Pi: Filament Runout Sensor

There is a specific kind of failure that only 3D printer owners understand. It’s the “Morning After” discovery. You wake up, walk into the workshop, and find that your twelve-hour print ended at 3 AM because you ran out of filament.

The result is always the same: a beautiful, useless, plastic spaghetti monster.

For a long time, I just lived with it. I tried to schedule all printing during ‘waking hours’, but that didn’t work for larger, more complex prints. Eventually, the frustration outweighed the effort of manually checking spools. I needed to prototype a system that didn’t rely on me being a printing ‘vampire’. I needed an automated, reliable solution using a Raspberry Pi.

The Hardware Stack: Stability Over “Quick Fixes”

I started with the BTT SFS V2.0 Sensor. Most basic sensors just use a mechanical switch. If the filament is no longer ‘sensed’, the switch clicks. The SFS V2.0 is “smarter.” It actually detects the presence and movement of the filament, which means it’s less prone to the random triggers that plague cheaper alternatives. Crucially, it can also identify filament jams and tangles, not just simple runouts.

But the real problem wasn’t the sensor; it was the connection between the sensor and my ‘Frankenstein’ printer. Years ago, I built a Printrbot Simple Metal from a kit. Ever since then, I’ve been ‘upgrading’ it. I’m pretty sure I bought all of the ‘official’ upgrades before Printrbot went out of business and then after that, I just built my own… and hacked on parts from other manufacturers.

OctoPi

For quite some time, the brains of my 3D printing operation has been OctoPi. OctoPrint is the industry standard for a reason. OctoPi takes everything built for OctoPrint and puts it on the Raspberry Pi. It has many features out of the box, but getting it to talk to other hardware is where the real “prototyping” happens.

Prototyping with Raspberry Pi

If you’ve ever built a Pi project, you know the “jumper wire jungle.” You plug a few wires into the GPIO pins, everything works for ten minutes, and then you accidentally bump the board and need to start all over. In a 3D printer environment, where everything is vibrating and moving, jumper wires are a liability.

That’s where the AdaFruit Pi Cobbler came in.

The Cobbler allows you to run a ribbon cable from the Raspberry Pi’s GPIO pins and breaks them out into a standard layout, making it much easier to prototype your solution on a breadboard. It’s significantly more user-friendly than wrestling with the Pi’s direct GPIO pinout. Plus, the board is nicely labeled, which eliminates the constant need to cross-reference documentation and prevents the confusion that often plagues prototyping. It’s the perfect tool for debugging and refining the layout before committing to a more permanent solution.

The Software Bridge: OctoPrint Plugins

Just plugging wires into the Pi doesn’t magically lead to a solution. To make the filament runout sensor actionable, I had to integrate the Octoprint-Filament-Motion-Sensor plugin. This plugin acts as a translator, taking the digital signal from the GPIO pins and turning it into a command that OctoPrint understands.

The logic is more complex than a simple binary switch. The BTT SFS V2.0 sensor provides two distinct outputs: a Switch Sensor signal to detect physical runout, and a Motion Sensor signal that pulses every 2.88mm of movement to detect jams or clogs. The plugin must be correctly configured to interpret these specific signal types and map them to the correct GPIO pins.

In practice, this involves some trial and error. You aren’t just mapping physical pins; you’re configuring the plugin to interpret the correct signal type, verifying the GPIO mapping is accurate and not using a pin with conflicts. Ultimately, you’re ensuring the software logic aligns with the hardware reality. There is a specific kind of rage that comes from realizing you’ve mapped the signal to the wrong pin, or that the plugin is looking for a signal that your hardware isn’t sending. Sometimes, the printer just keeps humming along while the spool is empty, others, it pauses after every few extruder moves. Debugging this is sometimes a hardware issue and other times it’s a single incorrect digit in a configuration file.

The Brutal Honesty: What I Got Wrong

Of course the basic prototype was just the beginning…

The biggest challenge wasn’t figuring out the hardware, or the code; it was in navigating the physics of the PrintBot Simple Metal Extended. Because my Raspberry Pi is mounted on the edge of the movable bed, it’s in constant motion. Every time the bed moves, the Pi moves. This turns cable management from a chore into a high-stakes engineering puzzle. If a cable is too tight or poorly routed, it’s not just an eyesore; it’s a potential point of failure in such a high-speed system.

Beyond this, there was the sensor mounting itself. I initially planned to mount the sensor in a static location near the filament origin point. After doing this, I quickly discovered that large movements in the X and Y axes caused false positives. The sensor is sensitive to the changing distance between it and the hot end. If the hot end makes a large move, it pulls the filament with it. If it then moves closer to the sensors mount point, the sensor triggers because it no longer sees the filament actively moving through it. I started by tweaking some of the software parameters, but this was just a bandaid that worked for some prints, but quickly failed for others. The filament runout sensor performs best (and conserves the most filament) when it is mounted closer to the (moving) hot end.

The temporary solution was far from pretty: I ended up using a handful of zip ties to “mount” the sensor as close to the hot end as possible, just to prove the concept worked. It wasn’t professional, but it was the only way to get the data I needed before I finally 3D-printed a permanent fixture to mount it on the printer’s Y gantry, allowing it to move in sync with the print head.

The Payoff

The first time it actually worked was a revelation. I intentionally let the filament run out on a test print. I heard the printer stop, saw the OctoPrint status change to “Paused,” and watched the print head glide safely back to the home position.

No spaghetti. No wasted filament. Just a paused print waiting for a fresh spool. Of course this first time, I couldn’t unload the filament to load a new spool because of a 3D printer firmware issue caused by OctoPrint issuing it the “Pause” command, but that’s a topic for a different blog post 🤣

Prototyping is rarely a straight line. It’s a series of failures, corrected assumptions, and a lot of “why is this not working?” moments. But that’s the point. I find that the journey is always worth it in the end.