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.
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.
Thanks.
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.
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.
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.
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.
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.
anything which controls GPIO pins needs to be the root user 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 wiring should 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.