Comms Failure & Recovering a print afterwards

I've had a few prints fail due to a comms issue between the Pi and my Ender 3 Pro which I would like to resolve, but at the moment I do not have access to the log files (I am at work and my Octoprint is only accessible locally) So for now I would like to know if there are any common issues with the Ender 3 and lost comms? I will post more details this evening to help diagnose my specific issue.

Last night I had a comms failure about 10 hours in to a 14 hour print job, it was my second attempt at the same part so I was keen to recover it, I started out by looking in the terminal screen for the last command sent to the printer, I then searched this out in the .gcode file and set about removing everything before this point.
On my first attempt I forgot to remove the prime line code from the beginning and on starting my print head crashed in to the part, fortunately nothing was moved or damaged so after removing the prime line code I tried again, this time with more success, the head moved towards where it had stopped and began printing, but it missed around 3-4 lines of extrusion, lucky for me this was a top layer of a large flat which was going to be "ironed" on a second pass and the ironing filled in the missing area without leaving a trace.
The next and all remaining layer to go down is entirely walling so I let a few layers go down, before realising that the fan was not running (I had deleted the line of code that started the fan) I manually started the fan it was getting late so i went to bed leaving the print job to run its course. This morning I found that the job had run to completion but there was a weak layer where the fan had not been running.

Overall i was pleased with my attempt at recovering the print job, had i not messed up with the fan i'm sure it would have been saved. Can anyone tell me the Gcode used to control the fan?
if i know this i can ensure that i add the code to start the fan.

Also how big is the buffer on the Ender3 Pro? is it a set number of lines or a certain size of data, is there an easy way of working out how many lines of code the printer is lagging behind the data sent out by Octoprint so that I can resume on the same line as where it cut off?

Wouldn't that be M106 and M107? I always refer to this page when I'm wondering what's-what.

get to dah choppa

Yeah, you definitely need to remove the priming line gcode as well as the G29 autoleveling command. You likely will want to convert your Cura-sliced files to use relative extrusion and to manually level your print bed.

For recoveries, I always use a caliper to measure the height of the printed part and then deduce the layer from this.

Thanks for that, I had another comms failure yesterday and successfully recovered the job from the exact place that it stopped which I'm pleased to have achieved. However it seems that the comms failure is happening quite frequently what info is needed to diagnose the issue?

Edit: I set a job printing whilst I started sanding down one of my previous prints on the bench opposite the printer. I heard the freezer start up, then a few seconds later the print stopped. Thinking back I had several successful prints before I changed to a different USB cable, the last one I used had ferrite cores at each end, but was about 3 metres long so I changed it for an Amazon Essentials branded cable (I've found them to be good in the past) however it does not have the ferrite cores. I've just switched back to the other cable to see if it is more resistant to RF noise.
A more long term solution will be to have a good tidy up in the garage and clear some bench space away from the freezer and on a different outlet all together.

Serial.log (trimmed) & Octoprint.log are attached below

serial.log (1013 Bytes)

octoprint.log (575.7 KB)

This was going to be my next suggestion: replace the serial cable or add a ferrite core. You're looking for one with internal metallic shielding, preferably and as short as possible.

Since swapping back to the other USB cable the connection has been solid, its been printing continuously since and no problems so far.

I think its safe to call this case solved, I will mark it as such.

1 Like