After the last couple of Octoprint updates, I've noticed that my printer seems to sits longer than it use to after bed leveling has completed and even after the bed and hot-end have achieved their set temperatures. Has anyone else noticed this?
Not noticed anything here (not that it should have changed anything) - pay attention to the terminal tab, to see when the printer sends back an ok response, to say it is done with the actions.
Seeing a lot of "Recv: echo:busy: processing", then finally Recv: ok
It's not that large or complex of a model that would take so much time to process I wouldn't think.
echo:busy processing is sent by your firmware. It's how it tells OctoPrint it's currently busy doing something, usually waiting for a heat up or bed leveling to complete. OctoPrint will and just not send stuff to your printer while it is signalling that it is busy. So if that busy period takes longer now, is probably been caused by either a firmware update our you might need a pid autotune to get your heat up back into whack. In any case you need to look at your printer and your firmware to solve this, OctoPrint is doing everything right here and listening to your printer.
I have seen the same issue here, though it rarely actually happens (luckily).
I checked the terminal and that was just filled with one:
Recv: echo:busy: proceok
and then plenty of:
Recv: T:190.00 /190.00 B:60.07 /60.00 @:64 B@:25
Recv: T:190.00 /190.00 B:60.07 /60.00 @:64 B@:25
Recv: T:190.00 /190.00 B:60.07 /60.00 @:64 B@:23
Recv: T:190.00 /190.00 B:60.08 /60.00 @:64 B@:17
not sure if the proceok is the correct state to expect from the printer, but I eventually just killed it and restarted.
You're right, it's not. It's a cross between echo:busy: processing and the ok. There's been some sort of communication hiccup in your case. OctoPrint should show a 'communication timeout' and try and trigger another response from the printer, but it will take a few seconds.
Microsoft seconds or regular ones? 
I waited for >2 minutes and then just restarted the printer.
To be honest; I do not yet have a clue what a PID tune is... 
Check what's set in your timeouts in the serial settings in case it has changed from the defaults, and enable the serial.log, reproduce the issue and share.
Your issue sounds different to the OP (their print started, just after a short delay), and this post is nearly 3 years old, so it might be easier for you to open your own 'get help' topic.
1 Like