Setting up Filament Runout Sensor


You are perfectly right with all you have type above. And Yes, I have replace the sensor with a normalswitch and it s behaving the same. I was so angy and I took a break. I have rebooted the rasp and try again. This time did not even wanted to trigger a runout filament when the switch was released. So it s behaving really weird.

I have allready talked with a friend to suggest me someone who can build up from ground a new plugin. I m down with my nerves someone else needs to step in. What king of programmer can build something like this? Couse I don t have expertise in this. Backend developer for linux ? Or what do I need to search for. Thanks.


Apologies... but my story:

Most of the first year that I had my Robo C2 printer, there were times when I would lose a job because 1) the filament simply ran out from the spool, 2) the filament was brittle and broke. The physical switch as provided by Robo 3D was horribly-designed. I honestly spent a lot of time designing and creating a completely new dual-filament runout block for the back of the printer. I must have put 20 or more hours into that process.

At some point, I got mad at Robo 3D and started buying different brands of filament. I found that the diameter control wasn't as good since the rolls of filament were less expensive. It took months for me to realize that the filament was sticking inside the PTFE tubing. I eventually decided to abandon the tubing so that meant the filament sensor block wasn't so necessary. In fact, by raising the height of the spools so that they were above the printer, I had much less "vampire biting" of the filament in the feeder and subsequent loss of a print job. So, no more filament sensor for me.

Personally, if I do try to solve my own problem it will be with spool-movement detection which I believe is a much better approach to problems. Also this.

Anyway, if you're certain that it's the plugin causing you difficulty and nothing else, you might try first reaching out to one of the existing plugin authors and asking for their expertise.


You can always use a JamSentry. It has a plugin for Octoprint and no hardware, firmware, or software mods are needed. As a plus, it also detects filament jams


That sounds like a good project for a geek like myself but the need to flash an ESP8266 sounds beyond the abilities of your average user, I'm guessing.


After all testing and all changes I have a conclusion:

After I install the plugin on raspberry all is ok because the pin is set to -1. The problem comes when I enable the PIN number in the plugin interface. So it's seems like the plugin is not affceting Octoprint until I enable the pin. That makes me think that is a problem of how Octoprint is interpreting signals from the endswitch.

I have putty installed and I can acces octopi trough SSH. What command should I type In order to see what's happening on the GPIO4? I want to connect the sensor to the board and then insert/remove filament so I can see if the pin state is changing.


Ok so I have entered with SSH and I have typed watch gpio redall. The GPIO4 state was 1 and as soon I have pushed the filament trough the sensor it became 0. So the sensor works great and the gpio pin respect the changings on the sensor.

Now, as I start the print, the processor was at about 30% and the IN and CS columns were at about 1314 and 470. Off course the printer was jittering but the values were normal. Then, as i have took off the filament, the state of GPIO changed to 1 but suddently the processor went to about 95% and IN and CS values to 80732 and 24391. The printer stopped printing after about 8 seconds but the values remained the same.

Then, I have inserted the filament into the sensor but the values remained the same. GPIO pin changed from 1 to 0. And when I pressed Resume button in octoprint interface, the processor stayed the same at about 98% and the values of IN and CS dropped to about 1114 122. Also the interface was showing attempt to reconnect and everything crashed.

When I typed STRACE-C on putty I have received only one syscall (read) and in about 10 seconds I have received about 30 syscall (read) witch is weird I think.

This makes me think that the octoprint is corrupt or the plugin itself is making octoprint to go crazy when it receive different states from the gpio pins.

Ah, btw everything I say is on octopi 0.16 and octoprint 1.3.10


This is the a way of seeing what the plugin sees. Try doing this when it's not printing. Insert the filament, check that URL. Pull the filament out, check that URL. If it's not a clear case of ON/OFF with these two states then I wouldn't even attempt printing yet. If you got a -1 from that page then you'd need to go into the Settings screen and do something there, then Save.

When you plug a switch into a pair of GPIO pins it could be in two different modes (to the best of my knowledge): with and without internal pull-up resistors. In your case where it's just a switch, I would guess that you wouldn't want an internal pull-up resistor. Hopefully the plugin is not asking for that.


now I have installed FIlament reloaded NG on my octoprint. The site you gave me is not good. it returns this site can't be reach


Oh, alright. That's weird. This plugin is based on the other one and yet they removed the API side of this. <_<

From a command line, you might be able to do:

cat /sys/class/gpio/gpio4/value

It should indicate zero or one if things are readable. If it says "No such file or directory", you could do...

echo 4 > /sys/class/gpio/export

In theory, that will set it up so that when the pin changes state, it writes to that file. You can then simply debug by reading it yourself like above.


I have allready did this. The pin state changes as it should. I think the problem is on the irmware. Something with comunication timeout or something. I have tested the same setup (raspberry pi zero W, octopi 0.16, octoprint 1.3.10 and filament sensor reloaded plugin installed) on a prusa mk2 with firmware 3.1.0 installed and everything is working perfectly. So it should be the firmware then. I'm using a modified version of marlin 1.1.9.


Okay, we know that putting filament in and removing it toggles the state of the GPIO pin. You feel confident that you've correctly configured your plugin for the pin in question.

I'm not sure what else to add to this. It's possible that it's the plugin's fault but I don't know.