Connection Timeouts on Raspberry Pi 4 & Prusa Mini
Hardware:
Original Prusa Mini (2x)
Raspberry Pi 4 model B (regularly updated with apt-get dist-upgrade)
Gearbest cooling enclosure
SanDisk Ultra 16 GB micro SD HC 1 speedclass 10
Apple iPad 12 W USB power brick
Anker USB cables
I recently switched from OctoPrint to your excellent Repetier-Server Pro (paid) and am getting frustrating halts after an hour or so of printing on both Prusa Minis connected. Here's a video:
https://youtu.be/21IcR88fYQw
Here are the logs of both print jobs:
Bottom Mini Log
Top Mini Log
The disconnects happen with one Prusa Mini connected also, usually well into the print, sometimes immediately, leaving nasty blobs on surface.
The relevant connection settings for both printers are as follows:
Baud Rate: 115200
RTS: Low to High
DTR: Low to High
Input Buffer Size: 127 bytes
Continue print after fast reconnect: YES
USB Reconnect on Timeout: Never
Ping-Pong Mode: NO
Communication Timeout: 3 s
I checked your FAQ's, perused this forum for similar problems, tried all sorts of settings to no avail. Tried changing USB ports, changed cables. Burned a load of PLA. I even tried another Raspberry 4 with same disk image, no help.
I have *no* overheating or undervoltage issues with the Pi, as demonstrated with this screenshot I took immediately after shooting above video:
Pi Hardware Report Screenshot
Are there any settings I can tweak? The problem (and the solution) surely lies with software and/or settings, as I never, never, never, never, never had this problem running Octoprint on the *same hardware* for a year and a half.
I also run Repetier-Server Pro on two other Raspberry 4 machines, they drive one Original Prusa MK3S each with no issues as far as I can tell. But I am only running shorter jobs (6 layers) on those two since switching to Repetier (printing mask holders for Slovenian medical staff). As far as I can tell, they could be suffering from the same problem.
Please help.
Thanks in advance, I would *hate* to switch back to OctoPrint as your 3D printing solution is clearly superior.
-Jonas
Original Prusa Mini (2x)
Raspberry Pi 4 model B (regularly updated with apt-get dist-upgrade)
Gearbest cooling enclosure
SanDisk Ultra 16 GB micro SD HC 1 speedclass 10
Apple iPad 12 W USB power brick
Anker USB cables
I recently switched from OctoPrint to your excellent Repetier-Server Pro (paid) and am getting frustrating halts after an hour or so of printing on both Prusa Minis connected. Here's a video:
https://youtu.be/21IcR88fYQw
Here are the logs of both print jobs:
Bottom Mini Log
Top Mini Log
The disconnects happen with one Prusa Mini connected also, usually well into the print, sometimes immediately, leaving nasty blobs on surface.
The relevant connection settings for both printers are as follows:
Baud Rate: 115200
RTS: Low to High
DTR: Low to High
Input Buffer Size: 127 bytes
Continue print after fast reconnect: YES
USB Reconnect on Timeout: Never
Ping-Pong Mode: NO
Communication Timeout: 3 s
I checked your FAQ's, perused this forum for similar problems, tried all sorts of settings to no avail. Tried changing USB ports, changed cables. Burned a load of PLA. I even tried another Raspberry 4 with same disk image, no help.
I have *no* overheating or undervoltage issues with the Pi, as demonstrated with this screenshot I took immediately after shooting above video:
Pi Hardware Report Screenshot
Are there any settings I can tweak? The problem (and the solution) surely lies with software and/or settings, as I never, never, never, never, never had this problem running Octoprint on the *same hardware* for a year and a half.
I also run Repetier-Server Pro on two other Raspberry 4 machines, they drive one Original Prusa MK3S each with no issues as far as I can tell. But I am only running shorter jobs (6 layers) on those two since switching to Repetier (printing mask holders for Slovenian medical staff). As far as I can tell, they could be suffering from the same problem.
Please help.
Thanks in advance, I would *hate* to switch back to OctoPrint as your 3D printing solution is clearly superior.
-Jonas
Comments
Hope for next release to have a solution so faster parallel sends will recover again.
THANK YOU!