Everything posted by Kagoromo
-
[Support] Octoprint docker template - Spants
Hi, the problem went away for me after I moved the printer closer to the Unraid machine to avoid having to use a long USB extension cable. I also bought a new USB mini cable just in case, but it turned out to be unnecessary as the cable that came with the printer worked just fine as long as it's plugged straight into the Unraid machine. If you have been using a USB extension cable, that's where I'd take a look first.
-
[Support] Octoprint docker template - Spants
Hi, firstly thank you for maintaining this Docker! I need a few pointers to troubleshoot intermittent USB connection to the printer. System log when such disconnection happens: Jul 13 12:45:52 Tower kernel: usb 2-1.2: new full-speed USB device number 23 using ehci-pci Jul 13 12:45:52 Tower kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device Jul 13 13:20:03 Tower emhttpd: spinning down /dev/sde Jul 13 13:40:09 Tower emhttpd: spinning down /dev/sdb Jul 13 13:42:22 Tower emhttpd: read SMART /dev/sdb Jul 13 15:22:08 Tower kernel: usb 2-1.2: USB disconnect, device number 23 Jul 13 15:22:08 Tower kernel: usb 2-1.2: new full-speed USB device number 24 using ehci-pci Jul 13 15:22:08 Tower kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device And the error as shown on Octoprint: State: Offline after error SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?) Printer is Artillery Hornet. Octoprint generally works well except for these random disconnections which may happen anytime, during an auto bed leveling routine, mid-print, pre-heating. Diag zip is attached. Thanks in advance! tower-diagnostics-20220713-1535.zip
-
Guide on how to stop excessive writes destroying your cache SSD
Hi, big thanks to OP for figuring all these fixes out. I have a docker app that writes to a redis db (some 50 MB large) every few seconds and your ramdisk trick really helped taming the cache write. I just want to add a note that, if you do go ahead with the 'appramdisk' route, the container's appdata path also has to be modified to use that appramdisk on top of all the scripts that you created. It took me an embarrassingly long time to figure out why the cache was still constantly having ~10 MB/s written to despite the appramdisk script up and running. Hope that can help someone else!