Filament sensor, running out during a print
Pretty sure this works well printing from a USB stick. Does anyone know if this works using OctoPrint? I much prefer using OctoPrint than sneakernet. Since it's set up, I'd like to continue using it. I have 3 rolls of PETG that are nearly empty, and I'd like to reclaim the space they take up. Does anyone have personal experience that the print will actually pause for filament replacement when the Core1+ is connected to OctoPrint via USB?
Alternatively, (second choice) is there a way to fuse the filament together and just wind it onto a single spool?
Best Answer by Tow Truck:
SunLu makes a filament connector that works well. Its $45 on Amazon ( https://www.amazon.com/Filament-Connector-Splicer-Printer-Compatible/dp/B0DLBJB9MD/ref=sr_1_1?crid=1CN6IVROLYWBG&dib=eyJ2IjoiMSJ9.iMKMnO7j2ESpdf-xAtcc6EeOjlfZvSFOSwwrFXrWSq9u-1Vus_I75aTZrx_AxiuGMp3p7BGdfdlOwGOZokWbobYxla8pFXGT5tsifvnMq0XNcbEd_H4OxrouchVf2X1jIPC2Gq3LSdN_f7T0j0q3XpQ2OUjwrEuNyZA9Vrok_VhHHDR3Z7KRXoMqw9gesebYrnLgYO5h4OW5Uj7Qrvd-ZLVBz4Xhr9IRofUJQ-_9Hx0.ZHNVPxOSO1jQvP1qR6O08ztGOE-IGcQfLpK1afgzSno&dib_tag=se&keywords=filament%2Bconnector&qid=1770850103&sprefix=filament%2Bconnec%2Caps%2C141&sr=8-1&th=1)
RE: Filament sensor, running out during a print
SunLu makes a filament connector that works well. Its $45 on Amazon ( https://www.amazon.com/Filament-Connector-Splicer-Printer-Compatible/dp/B0DLBJB9MD/ref=sr_1_1?crid=1CN6IVROLYWBG&dib=eyJ2IjoiMSJ9.iMKMnO7j2ESpdf-xAtcc6EeOjlfZvSFOSwwrFXrWSq9u-1Vus_I75aTZrx_AxiuGMp3p7BGdfdlOwGOZokWbobYxla8pFXGT5tsifvnMq0XNcbEd_H4OxrouchVf2X1jIPC2Gq3LSdN_f7T0j0q3XpQ2OUjwrEuNyZA9Vrok_VhHHDR3Z7KRXoMqw9gesebYrnLgYO5h4OW5Uj7Qrvd-ZLVBz4Xhr9IRofUJQ-_9Hx0.ZHNVPxOSO1jQvP1qR6O08ztGOE-IGcQfLpK1afgzSno&dib_tag=se&keywords=filament%2Bconnector&qid=1770850103&sprefix=filament%2Bconnec%2Caps%2C141&sr=8-1&th=1)
RE: Filament sensor, running out during a print
This has nothing to do with how the g-code is sent to the printer. The side-sensor is a switch. When the filament runs out, the switch opens and the printer will then pause to change filament. OctoPrint simply acts a proxy. You upload the g-code to OctoPrint and OctoPrint sends it to the printer over the serial interface. It doesn't have access to any of the printer hardware.
Also, if you don't want to use PrusaConnect then another alternative is to use PrusaLink which is a direct connection to the printer.
RE: Filament sensor, running out during a print
This has nothing to do with how the g-code is sent to the printer. The side-sensor is a switch. When the filament runs out, the switch opens and the printer will then pause to change filament. OctoPrint simply acts a proxy. You upload the g-code to OctoPrint and OctoPrint sends it to the printer over the serial interface. It doesn't have access to any of the printer hardware.
Also, if you don't want to use PrusaConnect then another alternative is to use PrusaLink which is a direct connection to the printer.
Does this mean that Octoprint becomes aware of the filament is out? Or does Octoprint keep on sending commands/g-code to the printer? Does the Core1+ have a big enough buffer to absorb the full g-code? Or will it pause Octoprint by refusing to acknowledge a command?
I didn't use PrusaConnect initially because I read of all the teething pains, and wifi problems. Simply didn't want to be a beta tester. Octoprint, at least running off a small SSD is plenty fast.
RE: Filament sensor, running out during a print
I don't print thru Octoprint, but there's a Prusa Filament Runout plugin that seems to address this. The description mentions "NOTE: If Prusa updates their Buddy firmware to work correctly with Octoprint, this plugin will no longer be needed."
RE: Filament sensor, running out during a print
Actually it's pretty lame that Prusa hasn't taken OctoPrint seriously for the last 6 years. There's issues like this that date from 2020, that Prusa has failed to act on, insisting OctoPrint was dead, and devoting their resources to bypass them. So much for Open Source cooperation. A plugin has been created that sort of detects a filament run out, by detecting when the head is parked.
It's lame that Prusa doesn't send out information like this (filament out) on the serial port, and has essentially refused to cooperate much for over 5 years. I'm disappointed.
RE: Filament sensor, running out during a print
I don't print thru Octoprint, but there's a Prusa Filament Runout plugin that seems to address this. The description mentions "NOTE: If Prusa updates their Buddy firmware to work correctly with Octoprint, this plugin will no longer be needed."
Thanks. The author of that plugin let me know about it about 15 minutes ago. The requests into the buddy firmware github page show requests like this have been active for 6 years, and Prusa hasn't acted. I'll give it a try.
RE: Filament sensor, running out during a print
The PrusaLink.status(printer) API call will respond with a state value of 'ATTENTION' when the printer needs user intervention. That's not specific to filament runout but should catch it, and maybe more useful as there are other reasons one might want Octoprint to alert the user. Will leave the implementation as an exercise for the student. 😁
RE: Filament sensor, running out during a print
The PrusaLink.status(printer) API call will respond with a state value of 'ATTENTION' when the printer needs user intervention. That's not specific to filament runout but should catch it, and maybe more useful as there are other reasons one might want Octoprint to alert the user. Will leave the implementation as an exercise for the student. 😁
That's lovely, and not that helpful to someone that doesn't even know what PrusaLink really is, never mind it's API, or how to call it. All I know is it's a wifi or ethernet based connection. The articles in the knowledge base aren't all that helpful either, since they are incomplete. Short of crawling source code, I don't know where to find this information. Seems like another example of over complicating things for no good reason.
RE:
Does this mean that Octoprint becomes aware of the filament is out? Or does Octoprint keep on sending commands/g-code to the printer? Does the Core1+ have a big enough buffer to absorb the full g-code? Or will it pause Octoprint by refusing to acknowledge a command?
I didn't use PrusaConnect initially because I read of all the teething pains, and wifi problems. Simply didn't want to be a beta tester. Octoprint, at least running off a small SSD is plenty fast.
The Core One handles runout in firmware. The side sensor is just an input to the printer; when it opens, the printer firmware transitions into a "filament change" state and pauses the print. That behavior is the same regardless of whether the G-code came from USB storage or from a host like OctoPrint. (OctoPrint doesn’t "own" that hardware state.)
Serial printing is a line-by-line protocol with acknowledgements. The host sends a command, the firmware replies ok when it’s accepted/executed, and the host throttles accordingly. When the printer is paused for user intervention, it effectively stops progressing and the host (OctoPrint) stops advancing the stream (or the firmware reports it’s busy). So this isn’t a “huge buffer” problem.
The only real limitation is notification semantics (host awareness), not whether runout "works." Where plugins can help is making OctoPrint understand and surface the printer’s paused/attention state more cleanly, so you get a proper UI prompt/notification. That’s different from the printer not pausing. The plugin suggestion is about OctoPrint UX, not about the Core One failing to do runout.
Actually it's pretty lame that Prusa hasn't taken OctoPrint seriously for the last 6 years. There's issues like this that date from 2020, that Prusa has failed to act on, insisting OctoPrint was dead, and devoting their resources to bypass them. So much for Open Source cooperation. A plugin has been created that sort of detects a filament run out, by detecting when the head is parked.
It's lame that Prusa doesn't send out information like this (filament out) on the serial port, and has essentially refused to cooperate much for over 5 years. I'm disappointed.
On the “Prusa hasn’t taken OctoPrint seriously / refused to cooperate”: Prusa’s ecosystem emphasis (Connect/Link) is a strategic choice, but it doesn’t mean runout is “broken” on OctoPrint. If you want better integration, PrusaLink/Connect will obviously be smoother; if you want OctoPrint, it can still print fine, just don’t mix up “OctoPrint doesn’t get a perfect runout event UI” with “firmware can’t do runout.”
RE: Filament sensor, running out during a print
On the “Prusa hasn’t taken OctoPrint seriously / refused to cooperate”: Prusa’s ecosystem emphasis (Connect/Link) is a strategic choice, but it doesn’t mean runout is “broken” on OctoPrint. If you want better integration, PrusaLink/Connect will obviously be smoother; if you want OctoPrint, it can still print fine, just don’t mix up “OctoPrint doesn’t get a perfect runout event UI” with “firmware can’t do runout.”
Nowhere did I say that stand alone the printer doesn't handle filament runout. I was asking if Octoprint was aware of it, or the printer sent a message to Octoprint, and it seems that the printer does not inform OctoPrint of much of it's status. Seems a bit hostile, but hey what do I know, maybe it's sour grapes between the two parties. Guess I got the answer, although it's disappointing.
RE:
The printer can only communicate to OctoPrint what it echos over the serial port. When the runout sensor triggers, that runout logic is handled internally. There is nothing printed on the serial line to indicate that condition has occurred.
One way I can think of though is in the "Pause Print G-Code" section in PrusaSlicer is to add something like:
M118 A1 filament:runout
This will echo "filament:runout" on the serial port. Then in OctoPrint, configure a plugin to intercept this and do some action. However... I'm not sure that this will even trigger since filament runout is an internal state not tied to the g-code runtime. Or maybe you can create a plugin that communicates with the printer over PrusaLink to get the status. But then you might as well use PrusaLink.