Hey, I have the SKR mini e3 V2, it has it's own filament runout sensor port. So if I connect the printer to the mainboard, and enable host commands, this will work through octoprint?
It is certainly working for me at least. Just need to make sure everything is set up correctly in your firmware config. There are a couple small tweaks I had to make to the octoprint settings as well, I can post what that is when I get home to double check it.
I am having some trouble with M600 after pausing... The rest of the layer it paused on does not go down well at all... But I haven't been able to track down where the issue might lay with that just yet.
I got around to testing this out finally and I'm not sure if my BTT Smart Filament sensor is working or not.
I'm hooked up to GPIO24 (set to BCM) but I keep getting timeouts on distance mode, no matter if the sensor is rolling or not.
What is a good place/log to take a look at to see what's coming through the GPIO, if anything?
EDIT: OK found the debug log for the sensor and looks like things are logging (remaining distance etc.).
Will have to do more digging on this as it's not behaving as expected. Probably something I've done.
EDIT2: The pause event seems to be related to the "remaining distance" in the logs and as soon as that counts down to zero or negative values, the pause/change is triggered.
2020-11-28 13:43:04,041 - octoprint.plugins.smartfilamentsensor - DEBUG - Sensor enabled: True
2020-11-28 13:43:04,043 - octoprint.plugins.smartfilamentsensor - DEBUG - GPIO mode: BCM Mode
2020-11-28 13:43:04,055 - octoprint.plugins.smartfilamentsensor - DEBUG - GPIO pin: 24
2020-11-28 13:43:04,059 - octoprint.plugins.smartfilamentsensor - INFO - Motion sensor started: Distance detection
2020-11-28 13:43:04,062 - octoprint.plugins.smartfilamentsensor - DEBUG - Detection Mode: Distance detection
2020-11-28 13:43:04,067 - octoprint.plugins.smartfilamentsensor - DEBUG - Distance: 15
2020-11-28 13:43:04,083 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 15.0; CurrentE: 15.0
2020-11-28 13:43:04,099 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 22.0
2020-11-28 13:43:04,103 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.0
2020-11-28 13:43:04,106 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 15
2020-11-28 13:43:07,688 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 15.0; CurrentE: 30.0
...
2020-11-28 13:43:50,887 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.70269; CurrentE: 16.73332
2020-11-28 13:43:50,888 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.29731
2020-11-28 13:43:50,890 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.03063
2020-11-28 13:43:50,891 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.73332
2020-11-28 13:43:50,933 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.73332; CurrentE: 16.76394
2020-11-28 13:43:50,934 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.26668
2020-11-28 13:43:50,936 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.03062
2020-11-28 13:43:50,937 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.76394
2020-11-28 13:43:50,981 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.76394; CurrentE: 16.79455
2020-11-28 13:43:50,982 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.23606
2020-11-28 13:43:50,984 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.03061
2020-11-28 13:43:50,986 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.79455
2020-11-28 13:43:51,029 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.79455; CurrentE: 16.8252
2020-11-28 13:43:51,031 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.20545
2020-11-28 13:43:51,033 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.03065
2020-11-28 13:43:51,034 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.8252
2020-11-28 13:43:51,078 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.8252; CurrentE: 16.8558
2020-11-28 13:43:51,079 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.1748
2020-11-28 13:43:51,082 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.0306
2020-11-28 13:43:51,084 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.8558
2020-11-28 13:43:51,109 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.8558; CurrentE: 16.87482
2020-11-28 13:43:51,110 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.1442
2020-11-28 13:43:51,113 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.01902
2020-11-28 13:43:51,114 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.87482
2020-11-28 13:43:51,157 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.87482; CurrentE: 16.8859
2020-11-28 13:43:51,158 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.12518
2020-11-28 13:43:51,160 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.01108
2020-11-28 13:43:51,162 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.8859
2020-11-28 13:43:51,204 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.8859; CurrentE: 16.89541
2020-11-28 13:43:51,206 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.1141
2020-11-28 13:43:51,209 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 0.00951
2020-11-28 13:43:51,210 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 16.89541
2020-11-28 13:43:51,253 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 16.89541; CurrentE: 19.02829
2020-11-28 13:43:51,254 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: 0.10459
2020-11-28 13:43:51,256 - octoprint.plugins.smartfilamentsensor - DEBUG - Delta Distance: 2.13288
2020-11-28 13:43:51,258 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 19.02829
2020-11-28 13:43:51,301 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 19.02829; CurrentE: 19.05041
2020-11-28 13:43:51,302 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: -2.02829
2020-11-28 13:43:51,304 - octoprint.plugins.smartfilamentsensor - DEBUG - Motion sensor detected no movement
2020-11-28 13:43:51,306 - octoprint.plugins.smartfilamentsensor - INFO - Pause command: M600
2020-11-28 13:43:51,309 - octoprint.plugins.smartfilamentsensor - DEBUG - E: 19.05041
2020-11-28 13:43:51,349 - octoprint.plugins.smartfilamentsensor - DEBUG - LastE: 19.05041; CurrentE: 19.08106
2020-11-28 13:43:51,349 - octoprint.plugins.smartfilamentsensor - DEBUG - Remaining Distance: -2.02829
I'm not sure (considering all the way through the log to the point the M600 is sent there seems to be movement detected) why this is being triggered or how the 'remaining distance' is measured or if it should be refreshing considering the delta distance looks about right for what's going on.
Any clues appreciated! Thanks in advance.
Seem to have it under control with some different settings (detection at 25mm). The remaining distance seems to be resetting ok after changing, and the M600 was triggered when I snipped the filament.
On looking at the debug log, it's an interesting pattern on how the measurements are done, which is not to say I completely understand the triggering, but it looks as though 25mm will do the trick as the remaining distance is not getting below 20 most times, but on a few occasions does reach 7.
Thanks very much to the dev for the plugin.
EDIT - spoke too soon - got 2 thirds though a print and got the filament runout again, multiple times.
Still have debugging on if the author wants a copy.
Might increase to 35mm next time I can afford time to muck around with failed prints.
I was having some inconsistent behavior with mine too - I got frustrated and decided to take it apart. What I found was enlightening.
Basically there is a rubber ring around the encoder wheel that spins via contact with a metal (stainless?) wheel. My rubber wheel had accumulated a bit of dust on it, and created a dead zone where the metal wheel was much more likely to slip if the right kind of retractions occurred on it.
So I would suggest trying to disassemble and clean it!
Thanks for the tip. I've already disassembled and considering it's pretty much only printed 25m of filament through it it's spotless and everything seems to move ok when doing some drag tests.
When I get a chance I'm going to run that python script on the wiki to check readings and see what's happening, but I've turned the sensor off for the time being as the M600 is troublesome enough on the CR10S Pro V2 with Tinymachines 6.2 FW on Octopi, I need to get some models out before I go back to diagnosis again.
What you could possibly try (I was actually going to do this before I found the dust) is maybe put a small strip of electrical tape around the encoder wheel to try to increase the tension between the 2 wheels. Just an idea!
Will definitely keep that in mind. I do think it's spinning ok though (can see it through the window/hole) and the tension on the filament from the wheels is pretty tight.
What would be interesting is to know (from the debug log) where the LastE (assuming extrusion), CurrentE and E: are coming from. Is that a measurement from the BTT Smart Sensor directly, or a calculation from Octoprint on approximate extrusions?
I realize it's very subjective but how much friction is the BTT device imparting compared with the stock microswitch run out?
I ask because I've found that even the small resistance from my stock run out detector is enough to adversely effect print quality. Although I suspect increasing the tension of the idler in the extruder would overcome that, the machine runs so well at the moment that I'm loath to introduce yet another variable.
So I narrowed where my problem was, thanks to the filament_motion_sensor_connection_check.py program.
What I found was the movement was not being detected really at all. Checked connections, still nothing.
Unplugged the BTT sensor (while the code was still running) and saw all sorts of movement in the GPIO, which I can only attribute to 'noise' from my fingers bridging the block connector. That settled down after a few seconds.
Then I plugged the BTT back in and lo and behold, it started picking up movement. Nothing else had changed.
All I can put this down to was a bad connection or possible crosstalk from the wires being wrapped close to the Pi power cable.
This output would be INCREDIBLY helpful within the plugin interface to help diagnose, as I had to jump some hoops to get the RPi GPIO talking (https://raspberrypi.stackexchange.com/questions/60774/importerror-no-module-named-rpi) but at least I have an idea now what's going on and can see clear output.
Back in business - thanks all.
EDIT: Additionally, I've noticed I can't run the python script and the plugin activated at the same time, unfortunately. As soon as I activate the plugin the python script seems to stop picking up the GPIO and has to be unplugged/replugged in to start responding again.
This stops me from keeping a 'live' eye on the sensor as it is running during a print, so my faith in relying on it during a big print is not quite there, yet.
IMO, It causes less drag than the static spool holder that came with my CR10s Pro V2.
I printed a bearing version of the spool holder, but once the filament is through the BTT SFS, there's not much drag to be honest. Each setup would vary.
1 Like
What is the filament runout sensor connected to?
If it is the printer's control board (Marlin) you need to enable HOST_PROMPT_SUPPORT and HOST_ACTION_COMMAND for it to work. That means that the control board will tell OctoPrint to pause/restart properly.
Actually... you mention you have a popup in OctoPrint so maybe you already have that there. In which case either OctoPrint is not getting rid of the notification like it should, or the firmware is not telling it to get rid of it.
Sorry, charlie, I retracted my post in favor of one on Reddit before I saw your response. Thank you for you help.
Filament sensor is connected to octopi and using this plugin. Those settings are enabled in Marlin. Should I disable them and then I won't get anything on the TFT anymore? Yeah, it seems like hitting the button in octoprint should get rid of the one on the TFT but that isn't happening. Or, if I could configure it so I get the messages only one place and not both, that would be good too.
I thought that the TFT was connected to the printer - is it connected to OctoPrint instead?
No, the TFT is connected to the printer. I did have:
#define FILAMENT_LOAD_UNLOAD_GCODES // Add M701/M702 Load/Unload G-codes, plus Load/Unload in the LCD Prepare menu.
added in marlin though not sure if that is just a set of menu choices or if it would cause this popup on the TFT when the print pauses. Sounds like it only controls some menu choices though.
Something's wonky with the communication between the printer and OctoPrint, about when this dialog should get dismissed. I'm not sure there's a good solution, other than disabling the host prompt support which would make the popup not show up on OctoPrint - it might also affect the TFT, some of them run acting like a host too.
- Is there a more appropriate forum to post questions about this plugin? I couldn't find one.
- My M600 isn't acting very well so I am looking for another 'triggered' command to use. What would M226 be used for? Is that for if you had another pin on the octopi to trigger when you had filament/flow restored? How would that work?
I have this kind of working with an Ender 3 v2. I have both a BL Touch as well as the BTT Smart Filament Sensor both wired to the printer board, not the Pi. My board is a standard Creality version 4.2.2. I ended up using a pre compiled firmware from Smith3D downloaded from this page.
In my case I used the Smith3D-E3V2-2.0.x.16-5x5-Fast-BTTSmartSensor-Inverted-Octopi-040221.bin file. I don't know what settings they use as I can't find any documentation on the different versions and I was not able to get it to work by compiling several versions of my own.
When the filament is cut Octopi pops up a Filament Error and the printer parks the head in the far left back corner and starts beeping. I could not get the print to start again by pushing Continue on the Octopi pop ups though. I was able to get it to continue by fixing the filament and pressing the button on the printer. After that it went through a reheat and primed the extruder and then started printing again. At that point I closed all the pop ups in Octopi and the print finished without any issues. I have not tried a filament jam situation yet.
I will note that the printer screen display never changed at all. I'm guessing that Octopi could be updated to make this work better but I'm not sure. I'm pretty new at this but would be happy to gather more info for any coders who want to try to improve it.
Thanks for the information. I have exactly the same configuration as you, so I will test with the firmware you have chosen. If you can find a way to activate the printer screen when printing is initiated from octoprint, I would like you to let me know. I will do the same on my side. Thanks again for sharing!
Thanks for posting this. I just tested this with an SKR Mini E3 V1.2 and the BTT Smart Runout Sensor. I connected the Signal to PC15, GND to the GND below PC15 (those two into the E0-STOP port) and the V into the PT-DET +5V.
This seems to work, although I had a detection just when starting the print, including unload and load. On the positive side, Octoprint realized this and correctly paused the print until I reloaded (the wrongly unloaded) the filament again.
I have not installed any filament runout plugin in Octoprint.
Now just to figure out why it detected a wrong runout when starting the print.