RE: Prusa MK4 & Octoprint
Do you have "console=ttyS0,115200" specified on the Kernel command line?:
"dmesg |grep 'Kernel command line'"
That was used in an older setup.
I would recommend performing a backup and installing a new OctoPi image. During setup you can restore your config and OctoPrint works as before with all the plugins.
The setup process has changed a bit over the years. The new image works out of the box. I did that to update my two printers, an MK3S+ and an MK4 to the latest OctoPi and the new camera stack. After restoring my older backups both printers worked fine.
RE: Prusa MK4 & Octoprint
- Other than using a different cable, it should work the same as with the MK3S. I'm not home, but there should be some logs in OctoPrint that you can view to see what it doesn't like.
RE:
It could be the command line parameter I mentioned before.
The old version used: "console=ttyS0,115200"
The current version uses: "console=serial0,115200 console=tty1"
Perhaps that prevents the printer from being detected.
Could also be that this would not work on the kernel of the older version. That is why I recommend to use the latest version of the OctoPi image, because this creates a defined and known state of the OS and the OS related settings that will work with the latest OctoPrint that is already pre-installed on the image. And the backups restore the OctoPrint configuration from the previous version of OctoPrint. So you lose no settings or plugins inside OctoPrint.
If you have used the Pi for other things beside OctoPrint before, as some people do, the situtuation will be a bit more complicated of course and more troubleshooting steps will be needed to get going.
You could always just try a new install on another micro-sd card to see if it works at all and keep the old card for later debugging.
RE: Prusa MK4 & Octoprint
I thank you for your patience. A fresh install fixed it and communication has been achieved. I'll have a dig around in the start-up parameters to see what might have caused the problem - though it's academic now, it might help someone else.
RE: Prusa MK4 & Octoprint
Update: the main difference is that the original Octoprint Kernel command line parameter was console=ttyACM0,115200, while the fresh install uses console=ttyS0,115200. Good spot @walter-layher.
I thank you for your patience. A fresh install fixed it and communication has been achieved. I'll have a dig around in the start-up parameters to see what might have caused the problem - though it's academic now, it might help someone else.
RE: Prusa MK4 & Octoprint
That makes sense because an mk3 uses a different board/serial connection. You would have to have updated your settings in the connection panel to the appropriate info.
RE: Prusa MK4 & Octoprint
The value for the kernel parameter in /boot/cmdline.txt (console=serial0,115200) and the settings for the serial port in Octoprint are not the same on my system.
So perhaps the access is blocked if both settings use the same value.
RE: Prusa MK4 & Octoprint
After multiple restarts, I'm getting to the root of the problem. Octoprint connects in safe mode. It connects when all plugins except the native ones are disabled. and I'm currrently loading the ones I usually load - excluding those which are obsolete because the Mk4 doesn't need them - one by one to see which one hinders connection.
RE: Prusa MK4 & Octoprint
Sooo... I got my MK4 kit last week, took some time to assemble it, and went to the test phase.
Using Octoprint 1.9.3 on a Raspberry Pi, FW 5.1.3+13503 on the MK4 and PrusaSlicer 2.6.1 on another computer.
- The filament runout detection does not work at all ;
- A print will start even without any filament in the hotend ;
- Color change is okay.
It seems some people got the filament runout to work with Octoprint. How did you manage this feat ?
Sincerely,
RE: Prusa MK4 & Octoprint
Did you do the filament sensor test/calibration in the setup assistant for the printer? Was it successful?
As soon as the MK4 firmware supported the filament runout sensor reporting for OctoPrint it worked for me without any further configuration.
I have since finished some filament spools with leftovers and runout detection worked every time.
I am on OctoPrint 1.10.0rc2Python 3.9.2OctoPi* 1.0.0cam (build 2023.10.09.154319) and Firmware 5.1.2 for the MK4.
RE: Prusa MK4 & Octoprint
I remember now how this went. Look at the first post under this link:
https://forum.prusa3d.com/forum/english-forum-original-prusa-i3-mk4-general-discussion-announcements-and-releases/5-1-0-firmware-for-original-prusa-mk4-is-out/
Look for the heading "Improved Octoprint support". There it says:
To make sure everything works correctly, you need to update the Octoprint profile with the following G-codes (in the GCODE Scripts section):
- After print job is cancelled: M604
- After print job is paused: M601
- Before print job is resumed: M602
I had forgotten that this was necessary because I had copied my setup over from an MK3 where these commands were already included.
RE: Prusa MK4 & Octoprint
Hello,
Did you do the filament sensor test/calibration in the setup assistant for the printer? Was it successful?
Yes I did the calibration and it was successful. I even made a factory reset a few minutes ago, just to be sure the filament sensor calibration did succeed.
Filament runount works when printing from a USB key.
To make sure everything works correctly, you need to update the Octoprint profile with the following G-codes (in the GCODE Scripts section):
I did check, and those GCODE are indeed configured in Octoprint.
I also did a full reinstall of Octoprint, without any plugins. The results are very weird :
- The printer will happily starts printing without filament.
- But if the filament runs out during a print, the printer does stop (or, at least, it did it during my tests).
Could it come from the factory reset ? From a side effect of the calibration, since there is a step around the extruder where we play with the idler stuff and such ? Or from some plugin ?
If I remember well, I did a few tests with Octoprint in safe mode (before the factory reset and Octoprint reinstall), it did not change anything for the (non) detection of a filament runout.
I'm going to make a lot more tests in the near future, especially plugin-wise.
RE: Prusa MK4 & Octoprint
As I understand it... The filament runout handling during "serial printing" is done by the firmware. Octoprint sees "busy" responses, so it knows the printer is still working and doesn't disconnect, but Octoprint doesn't control the pause or loading/purging of new filament -- that is done by the firmware.
Once a serial print starts, if the firmware senses filament-out then it pauses, prompts you through loading more filament, then resumes accepting and processing commands from Octoprint. I am a little surprised the firmware will let a serial print be started when filament is not loaded, but preventing the start of a print isn't really the purpose -- rather, it is to stop an in-process print when filament is exhausted. Either way, Octoprint really doesn't have a role the way it is currently implemented, other than "standing by" until the firmware resumes taking commands.
RE:
Addendum, since I can't edit previous post...
Octoprint does not know the printer is "out of filament". The printer firmware just tells Octoprint "I'm still here, but I'm busy" so Octoprint doesn't keep sending commands or terminate the connection. That "busy" signal is sent every 4 seconds (M105 temperature reporting continues as well) until you finish the unload/load process using the printer's LCD control.
When you make the final knob-click on the LCD control, the firmware moves back where it was before filament ran out, and sends an "ok" acknowledgement to Octoprint -- so Octoprint will resume sending Gcode lines to the printer.
So, Octoprint really has no role at all in the filament runout, other than "waiting" while it gets "busy" responses, and then continuing when it gets an "ok".
RE: Prusa MK4 & Octoprint
Hi,
Addendum, since I can't edit previous post...
Octoprint does not know the printer is "out of filament". The printer firmware just tells Octoprint "I'm still here, but I'm busy" so Octoprint doesn't keep sending commands or terminate the connection. That "busy" signal is sent every 4 seconds (M105 temperature reporting continues as well) until you finish the unload/load process using the printer's LCD control.
When you make the final knob-click on the LCD control, the firmware moves back where it was before filament ran out, and sends an "ok" acknowledgement to Octoprint -- so Octoprint will resume sending Gcode lines to the printer.
So, Octoprint really has no role at all in the filament runout, other than "waiting" while it gets "busy" responses, and then continuing when it gets an "ok".
I thought Octoprint had a more active role.
To sum it up, whatever I did on Octoprint's side had no impact whatsoever on the problem' sudden disappearance ? That's bad for my ego 😀
Since I'm not going to fiddle with the printer's extruder to test if it's the screw tightening or the idler door (the only two things that were effectly « changed » during the reset and calibration), maybe I will never now why the filament runout did not work previously and why it does now.
I just hope everything will keep working 😓 .
Thanks for your time.
RE: Prusa MK4 & Octoprint
I thought Octoprint had a more active role.
Octoprint (and various plugins) definitely *can* have a more active role with some printers, but not with the current MK4 firmware. The MK4 firmware does not expose the filament sensor status to a serial host. The M115 (capabilities) response doesn't list RUNOUT at all, and a M412 command just returns "unknown command". When filament runs out, Octoprint knows via the "busy" messages that the printer has not yet completed the previous GCODE command but gets no information as to why. (Note that early versions of the MK4 firmware didn't even do this -- the print simply continued and the firmware did not react in any way to the filament runout when a serial print was running.)
Octoprint (via plugins) can also support addon filament sensors for printers that don't have one built-in. For example, an external sensor can be added and wired to GPIO pins on a Raspberry Pi running Octoprint, and there are plugins that will see the GPIO status change and intervene in the print from the Octoprint side.
I am mostly fine with how it currently works on the MK4. I have to physically be at the printer to change the filament anyway, and the firmware has the LCD display and knob so I can interact with it to change the filament. Some kind of notification from the firmware to the serial host (i.e., Octoprint) would be nice, so the host (or a plugin) could send me a mobile notification that intervention is needed. But I am usually aware when filament *might* runout, so I'm usually there when it happens.
RE:
My guess is that since this was about 7 months ago, you probably got your Octoprint working with the MK4. I just converted My MK3S+ to a MK4. I already used a Raspberry Pi 4B with Octoprint installed on it, same one I've been using for a few years and all I did was to connect a USB-C cable to the MK4, then turned on the MK4, once it was fully on, I turned on the Pi and it worked! The camera works just like it did before. It works for me with the same pi I used on the MK3S and MK3S+.
That said, the only thing I don't like about it is that the MK4 screen does not indicate any kind of progress of the print, with Octoprint. You just have the little green octopus on the printer screen, letting you know the printer is in its control... You can see the hotend temp and the bed temp, but that's it... Pretty sure this is a something not programmed on the buddy board...
RE: Prusa MK4 & Octoprint
Prusa has already confirmed that they will improve OctoPrint Support (especially the information on the screen) in future firmware versions.
RE: Prusa MK4 & Octoprint
Thank you! That is great news!
RE: Prusa MK4 & Octoprint
I've noticed a difference in behaviour recently with manual filament colour changes mid-print but I'm not sure whether this was introduced with the latest software updates for the MK4 or whether this is unique to Octoprint (not had a chance to test yet).
Previously my manual colour changes worked flawlessly when printing from USB stick. Remove old filament, load new, purge, confirm colour is correct, resume printing from place it left off - all good.
What I'm experiencing now is exactly the same as above, but immediately after confirming the colour is correct (after purging), the nozzle zooms to the place it left off, but it also purges out filament as it starts printing. Thankfully I've managed to save it the last couple of times by swiping at the extra poop but is this unique behaviour to Octoprint/printing via serial or has this crept in with the latest Prusa software updates?
Is there any way around this? I followed the official Prusa Octoprint instructions for adding custom g-code elements, so no idea where to look next.
Thanks
Pete