Improving the OctoPrint and Prusa i3 MK3 User Experience
Given that the Einsey board so prominently promotes the use of Octoprint by using a Pi Zero W, I'd like to create a backlog of ideas for functionality that as a group we would like to see implemented to improve the experience of using OctoPrint with the MK3.
Idea List
Power Panic - In Progress
Power Panic should work just as it does while printing from the SD card, but instead retrieve the required line to resume printing from OctoPrint.
note: I've heard this is being worked on as a collaboration between the OctoPrint developer and Prusa (anyone have a link?)
Filament Sensor - Unknown
Filament sensor should work just as it does while printing from the SD card. Currently OctoPrint cancels the print when the printer triggers an error related to the filament sensor.
Display Updates
Currently the message on the MK3 display does not get updated by OctoPrint. There is an opportunity here to write an OctoPrint plugin which would send updates to the printer to display estimated print time, percentage completion, etc...
'Hybrid' SD Card Printing
It would be nice to be able to print from the SD Card, while still having OctoPrint in control of functionality like being able to pause, stop, load/unload filament, just like you can do from the printer itself.
Improved SD Card Upload Speed
It may be possible to introduce improvements to the upload speed of files to the SD card.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
I'd like to add:
[*] Fix faster upload speeds from octoprint to the printer SD card.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
I'd like to add:
Fix faster upload speeds from octoprint to the printer SD card.
Probably not going to happen, this is likely a hardware limitation of the Einsey.
Also, by uploading to the SD card rather than printing directly from OctoPrint you lose out on many of the advantages of using OctoPrint in the first place.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
I'd like to add:
Fix faster upload speeds from octoprint to the printer SD card.
Probably not going to happen, this is likely a hardware limitation of the Einsey.
People keep saying that, and I keep not believing them. I've looked at the SD card upload implementation in Marlin. It looks really suboptimal. I've also looked at the Prusa specific SD card upload in the prusa firmware - the one they use in their print farm - and it looks better. I have, however, not been able to get a reasonable answer from Prusa support regarding if that implementation actually works faster.
Regarding your second point, let's add
* Make sure there are G-code commands for all actions you can do with the lcd display, like pause, stop, load/unload filament etc. And that the printer responds to these commands despite being mid SD-card print.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
I'd like to add:
Fix faster upload speeds from octoprint to the printer SD card.
Probably not going to happen, this is likely a hardware limitation of the Einsey.
People keep saying that, and I keep not believing them. I've looked at the SD card upload implementation in Marlin. It looks really suboptimal. I've also looked at the Prusa specific SD card upload in the prusa firmware - the one they use in their print farm - and it looks better. I have, however, not been able to get a reasonable answer from Prusa support regarding if that implementation actually works faster.
Regarding your second point, let's add
* Make sure there are G-code commands for all actions you can do with the lcd display, like pause, stop, load/unload filament etc. And that the printer responds to these commands despite being mid SD-card print.
Added both!
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
Not frying the RPi is on top of my list.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
your list is great, but have you logged it to the git for octoprint? Foosel might see it here, but she will absolutely see it there. Currently there are 2 prusa issues/features logged, 1 by me for crash recovery and filament sensor recovery and one for an mk2 for inability(with the new firmware) to pause and resume.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
I think Power Panic to OctoPrint isn't easy to implement:
1. RPi will need a battery backup to stay powered. Cutting power on RPi can corrupt the file system and crash it completely. The actual print job needs to be active and being paused to resume.
2. The RPi need to know that power panic was triggered and when the power is back. The nAC_FAULT is on pin 5 of the J19 (RPi header) available, so from the hardware side it should kind of work. Having that you gonna need a feedback from the printer which lines were printed and which not, the printer needs to send the exact position to Octoprint as it does writing this data to EEPROM within the firmware. Question is: Is there enough power left to lift the nozzle and send the data back to Octoprint?
3. How does the serial port behaves on the EINSY when it powers on? Can OctoPrint auto-reconnect to the printer within the OctoPrint print job is waiting for printer-feedback?
If you send the gcode file via OctoPrint to the SD card of the printer and start a SD card print.
The build-in power panic function of the firmware should work. But as the firmware needs user interaction after a power failure when the temperature dropped to far, you cannot remotely resume the print. A firmware change would be needed for that. You still gonna need the RPi on battery backup or you have to wait (and hope) the RPi starting up.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
1. RPi will need a battery backup to stay powered. Cutting power on RPi can corrupt the file system and crash it completely. The actual print job needs to be active and being paused to resume.
2. The RPi need to know that power panic was triggered and when the power is back. The nAC_FAULT is on pin 5 of the J19 (RPi header) available, so from the hardware side it should kind of work. Having that you gonna need a feedback from the printer which lines were printed and which not, the printer needs to send the exact position to Octoprint as it does writing this data to EEPROM within the firmware. Question is: Is there enough power left to lift the nozzle and send the data back to Octoprint?
While it is certainly possible, I'm not convinced that filesystem corruption is something that would happen unless the power outage was particularly ill-timed. Creating a time-lapse would likely increase the likelihood of this happening, but generally speaking data should only be being written to the micro sd card at fairly infrequent intervals. It's also likely feasible to trigger a sync in time via the power panic header pin.
Based on the output I've seen on the console while testing Power Panic, it also seems that the printer is already capable of asking for a specific line of gcode when (trying) to resume. I've not investigated further than that.
3. How does the serial port behaves on the EINSY when it powers on? Can OctoPrint auto-reconnect to the printer within the OctoPrint print job is waiting for printer-feedback?
FWIW, I've had no issues so far with automatically reconnecting, at least not with the USB port.
your list is great, but have you logged it to the git for octoprint? Foosel might see it here, but she will absolutely see it there. Currently there are 2 prusa issues/features logged, 1 by me for crash recovery and filament sensor recovery and one for an mk2 for inability(with the new firmware) to pause and resume.
I may create issues for tracking specific features (ex: Power Panic functionality), but my hope is that some things may be able to be implemented in the form of plugins. I need to take some time to dig into the OctoPrint API to see what can be accomplished via plugins.
Re: Improving the OctoPrint and Prusa i3 MK3 User Experience
1. RPi will need a battery backup to stay powered. Cutting power on RPi can corrupt the file system and crash it completely. The actual print job needs to be active and being paused to resume.
2. The RPi need to know that power panic was triggered and when the power is back. The nAC_FAULT is on pin 5 of the J19 (RPi header) available, so from the hardware side it should kind of work. Having that you gonna need a feedback from the printer which lines were printed and which not, the printer needs to send the exact position to Octoprint as it does writing this data to EEPROM within the firmware. Question is: Is there enough power left to lift the nozzle and send the data back to Octoprint?
While it is certainly possible, I'm not convinced that filesystem corruption is something that would happen unless the power outage was particularly ill-timed. Creating a time-lapse would likely increase the likelihood of this happening, but generally speaking data should only be being written to the micro sd card at fairly infrequent intervals. It's also likely feasible to trigger a sync in time via the power panic header pin.
Based on the output I've seen on the console while testing Power Panic, it also seems that the printer is already capable of asking for a specific line of gcode when (trying) to resume. I've not investigated further than that.
3. How does the serial port behaves on the EINSY when it powers on? Can OctoPrint auto-reconnect to the printer within the OctoPrint print job is waiting for printer-feedback?
FWIW, I've had no issues so far with automatically reconnecting, at least not with the USB port.