Just set up a Raspberry Pi 3B+ with OctoPi and OctoPrint to run my Taz 6 - very cool!
…unfortunately, during my first print, I had many random pauses/hangs lasting from a few moments to several seconds, during which a small amount of filament would ooze out requiring some “post- processing” of my part to clean up. It was very similar (if not identical) to when I’d first had my printer connected straight to my computer via USB/serial. When I switched to printing from the SD card in the printer, that problem went away. I was also using the built-in time lapse capability of OctoPrint - is it possible it was utilizing so much of the Pi’s processing capability that it was slowing down the gcode communication? Has anyone else experienced this problem?
To be fair, I haven’t tried another print from OctoPrint without the camera to see if things improve, nor have I investigated if the “lag” is due to a delay on OctoPrint’s side in transmitting the next command, or on the printer’s side in transmitting the “OK” confirmations.
Are you only noticing the pauses through the streamed video? If so, it could be lag from the network. If you’ve seen the lag first hand, it could be the usb cable.
There are also some serial settings that could help with communication issues, but I haven’t had to utilize those in recent builds of printer firmware or octoprint builds.
I don’t think it’s the cable… If there were communication problems (messages getting corrupted one way or the other), I would expect the printer to just stop completely. I don’t believe OctoPrint re-issues commands that it doesn’t receive an “OK” to.
I’ll have to dig into adjusting the serial settings on the printer… I believe the baud rate is cranked to max (250,000) by default, but if it is a communications-corrupting connection over the USB cable, perhaps lowering the baud rate will help.
Trying a few experiments to correct this issue based on what I’ve come up with from the wider interwebs…
Later versions of Cura had a “problem” when creating Z movement commands without a Max Z travel speed defined. They’d issue the command with some absurdly high speed, which Marlin would have a little bit of a eye-cross over and hang for a second before just processing the command at the max Z speed set in firmware. The solution is to actually set a Max Z speed in Cura, but that hasn’t fixed my problem, so moving on…
My next guess is that the auto-reported temps are getting in the way of Marlin processing/responding to movement commands. My proposed fixes are to set a longer auto-report interval, or to drop auto-report for a long"ish" “manual” reporting interval. I haven’t given this a shot yet, but I’ll report back with my results…