OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible
One end or the other is causing the problem. Someone is holding a line too long in one position, or doing something unexpected for the USB interface on the MK4 to fail. The MK4 has a faster 32 bit processor, so it will respond a lot more quickly than older 8 bit micros.
However, it is my opinion that Octoprint should not cause a 3D printer to have a fatal watchdog timeout - since a watchdog timer is a necessary safety item for a responsibly made 3d printer. The only way to recover is to power cycle the MK4 printer.
I have not tried this running from an SD card. I am executing the libcamera image from SSD. (Downloaded about a week ago.). Maybe the RPI is too fast, or the timing and handshake is incorrect, or it's never been tested this way. (Things like that happen!). But I wanted to report this. This has happened about 6 times now, primarily when switching over a camera for testing. (Yes the pi was properly shutdown and power removed.). The MK4 dies on the Octopi server start up. Yes, a reboot is fine, but not a Watchdog timeout.
This is surprising behaviour from the printer! Even Creality have not managed to make this a feature of their firmware. I know that Prusa had a lot of 'teething' (if you could say that) issues with their MK4 & XL firmwares.....
I was going to suggest to please report it to Prusa, but it looks like it's a bit of a known issue since December, based on a quick search of their issues:
Within that thread there's also some more issues linked that have been created as duplicates.
And looking at the issue @Charlie_Powell posted it's not just OctoPrint, it's any usb serial device, so definitely seems like an issue with the firmware. Not sure if it will make a difference, but did you manually select the port and baudrate?
I was unaware of these settings. I made the slight change to the printer volume and the wiping area. I did not change the gcode settings per the second link, since I read the comments there which say some of the gcodes don't work!
I have noticed that Octopi is complaining that the print won't fit in the print area and it simply isn't true. The gcode setting is
M555 X107.825 Y31.3252 W34.35 H38.1496
which most certainly will fit. Maybe adding the wipe area will help, but I didn't change the bed dimensions from 250x210. The part, including it's brim is well in the print area, but Octopi was complaining. But this is not related to the WD failure.
Yeah, custom bounding box settings usually fix that don't fit error. There was also an issue from Cura printer profiles that would cause this error because of relative vs absolute movement, which might not be the case for you because I'm assuming you're using PrusaSlicer or variant.
The custom bounding box did fix that "won't fit" error, interestingly enough. I am using PrusaSlicer 2.71.
For the main WD fault - it seems that the MK4 is going through teething problems. In any case, something isn't right. Usually it takes two to tango, but it seems there's something about that USB port that is an issue when there are peripherals attached, even a Raspberry Pi.
