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.