I'm in the same boat.
Same boat as well! Followed this entire thread, same exact issues.
If you can't run that /status link from above both with and without filament inserted and see the appropriate response then something's wrong with your settings in the plugin (adjust/repeat). If you really can't get a solid ON/OFF response from that status link, having adjusted things in the plugin, then it could be the switch itself. I know my own printer's switch was absolutely stupid in its design.
I used your cmd line to verify the switch on gpio 24 was indeed working. When in octoprint it won’t recognize it! Driving me nuts
- Okay, so—having
cat'd the device tree itself, you see that the switch is opening/closing and can be felt on the corresponding GPIO pin. - Next, take this to the API for that plugin: http://octopi.local/plugin/filamentreload/status
If that one doesn't follow the filament state then it's something to do with the plugin's configuration, I'd guess. Not sure about how that author does things but verify that you've used the right pin in the configuration and you understand which pin-naming scheme is being used.
Thanks for that link, that was a great help!
I also am in this same boat. Cannot for the life of me get filament sensors to work. I've tried like 4 different plugins, even enclosure plugin, nothing seems to work. I'm monitoring the leads at the switch and they are going high / low as I expect (its not plugged into the filament sensor anymore, now I just have dangling leads that I short when I want to change the state). Some plugins don't even setup the pin as input correctly. Has anyone tried using a octopi filament sensor plugin in 2019 and got it to work? Seems like no one can on the entire internet in 2019
All these filament sensor repos have not been updated in 2 years + so I think the issue is with new versions of octopi? I'm going to stop trying to find a solution to this because it seems to be a waste of time and not possible with octopi in its current state. I think I will just try again next year some time and disable any updates and just use ublock origin to block the update notification window from showing at startup.
Alright...
- anything which controls GPIO pins needs to be the
rootuser by default - it's possible to add the Pi user, though, to a group to give it this access:
sudo adduser pi gpio - many of these Python scripts rely upon a library of some kind being installed to help facilitate conversations to the GPIO pins; so you might want to verify that this package is installed to the virtual environment as expected. for example, wiringpi was added to the OctoPi image at some point. activating the virtual environment and running
pip freeze|grep wiringshould show you whether or not you have it installed. and yet, there are more than one package which makes this friendly so it's hard to say if your plugin uses that or not.
I'm so frustrated. I am in the same boat as you, Ryan. I spent hours yesterday trying to get my filament sensor working, but neither Filament Sensor Reloaded nor Filament Sensor NG work. I have checked the wiring of the switch with a multimeter to ensure it is working properly and I have also confirmed the pin is being read correctly by the Raspberry Pi via SSH and the command 'gpio readall'. The pin does indeed go from low to high when filament runs out, but the filament sensor plugins do not pause the print even though they are set up "correctly" no matter what.
Is this an issue with new versions of OctoPrint? With the current state of things, is there no way to use a filament sensor with OctoPrint?
Does someone need to make a new filament sensor plugin?
Probably the original plugin authors were inundated by issues with people who'd purchased the many types of strange runout switches out there and wanted free support. It looks like nobody is actively developing nor maintaining these at the moment.
1 Like
I have a solution! @Ewald_Ikemann recommended I try "Enclosure Plugin" and it works great! It can be configured to with the filament sensor in order to pause the print!
Give this a shot, @Ryan_Avery
2 Likes
Already have, same issue, no luck
what settings did you use?
[sudo] password for pi:
The user pi' is already a member of gpio'.
pi@octopi:~ which wiringpi
pi@octopi:~ sudo apt-get install wiringpi
Reading package lists... Done
Building dependency tree
Reading state information... Done
wiringpi is already the newest version (2.46).
0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded.
Also, the filiment sensor is a switch... it is either closed or open. There is no more complex way needed to solve the runout problem, so idk what you mean about supporting switches.
If you believe that you've exhausted the troubleshooting steps then you might try the Enclosure plugin which appears to be maintained.
I'm going to fit a filliment sensor and occured to me that the sensor will be at the top of the printer ( i3plus)
Would be nice to let the filliment run for a little longer to minimize wastage at the end of a roll.
So my question is can I input a gcode to pause the print after a certain time rather than pausing instantly?
Sorry if it been asked before. Did a quick search but couldn't find anything.
Thanks.
In python, it's something like this to sleep for a number of seconds. But you don't want the main thread of OctoPrint just stopping for a while. So when you call your script, it's best to run it "in the background" with the ampersand like this...
/home/pi/scripts/myscript.py &
Then whatever magic you use in your script needs to incorporate your sleep command, include something called a shebang at the top to tell Raspbian that we're trying to use Python to run this and then it does something at the end. In theory, you'd run this from the Gcode Systems Commands plugin.
But a more straightforward way would be to create a plugin, I'm guessing.
I just got a run out sensor and after reading through these posts I understand i need to chop off my 3 pin plug and attach as the diagram above says
but in the plugin in octoprint what pin nr do you enter V, S or G?
I am not sure if this has been answered or not. But the problem seems like a power issue to the pi.