OctoPi sloooooow printing; not your average slow

What is the problem?
OctoPi was working great until yesterday. I spent a good part of the day tuning retraction settings and sending gcode generated here and finally found settings I liked. All subsequent prints have had jerky print head movement and have taken six times the estimated time to print.
I've seen other threads which point to serial connections as the culprit; it's possible, but this seems extreme. And there have been zero hardware changes and only minor Cura profile changes in the last 24 hours. Here's a video of the print head movement.
What did you already try to solve it?
I printed from the SD card through OctoPi interface and had the same results. The terminal shows all messages getting through, from what I can tell. I powered down Pi and printed from the SD card and all was well. This one is weird to me.
Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
Octoprint and Serial logs from this morning...
logs.zip (798.3 KB)

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
OctoPrint 1.3.12, OctoPi 0.17.0, running on Raspberry Pi 3 Model B Rev 1.2, Ender 3 printer, Chrome browser, Win 10

1 Like

Ok, the serial.log is not activated...
And in the octoprint.log there is a huge amount of :

2020-02-06 10:09:30,538 - octoprint.plugins.psucontrol - INFO - Auto-On - Turning PSU On (Triggered by M140)
2020-02-06 10:09:30,539 - octoprint.plugins.psucontrol - INFO - Switching PSU On

Try again in safemode and then in normal mode without the psu control plugin.
Normally, the plugin should get in action the first time it dedects a "power on" gcode, but it does it all the time.
That is this printing step by step.

1 Like

That explains the tiny file size. Sorry, I have a handful of things going on at the same time and I just dumped it and zipped it.

Thanks--that's a good tip. I'll try printing again in safe mode. I can disable that plugin, too, as I don't have it connected yet. I was shooting for this weekend to do the wiring.

EDIT: I, erm, didn't follow your advice. Instead of safe mode, I just deselected the "Automatically turn PSU on" checkbox and also disabled the Temperature Failsafe plugin. The first test print is whipping along at its original satisfactory pace.

THANKS a bunch. I'll have to come back later and see why the PSU Control plugin is acting that way. In the "Trigger commands" field are the following:

G0,G1,G2,G3,G10,G11,G28,G29,G32,M104,M106,M109,M140,M190
1 Like

I will also throw in here that there's a units difference between Marlin and OctoPrint.

In OctoPrint -> Printer Profiles -> edit yours -> Axes tab, the units seem to be mm/min for the maximum speed/feedrate settings. I seem to recall that the firmware logistics store this as mm/sec for Marlin.

As a result of this, I ended up mis-configuring these values in OctoPrint and the jog buttons then moved SUPERSLOOOOOOOOOOOW (1/60th the expected speed). I finally got an "aha" moment and fixed that.

I would leave away the Power On Options and just put the command M80 into the gcode start code of the slicer. So the printer is just powered on at the beginning of a print.

I just found out the reason for it, the PSU Control Plugin shits it's pants when the power socket isn't reachable.
I was wondering why my prints slow down a huge amount when i update my wireless APs or restart the network switch.