Toast falls face down. Your car always breaks after the warranty period. A 3D print only fails after it is has been printing for 12 hours. Those things might not always be true, but they are true often enough. Another pessimistic adage is “no good deed goes unpunished.” [Shippey123] did a good deed. He agreed to make a 3D printed mask for his friend to give as a gift. It was his first print he attempted for someone else after about four months’ experience printing at all. After 20 hours of printing, he noticed the head was moving around in the air doing nothing — a feeling most of us are all too familiar with. But he decided not to give up, but to recover the print.
Luckily, he’s a CNC machinist and is perfectly capable of reading G-code. The first thing he did was to shut everything down and clear the head. Then he rehomed the printer and used the head to determine what layer the printer had been working on when it failed. He did that by moving over a hidden part of the print and lowering the head by 100 microns. Then he’d move the head a few millimeters in the X direction to see if the head was touching.
Turns out the printer was probably on the 40mm layer when it froze, but to play it safe, he decided to resume printing at 33.8mm. For this kind of print, being off by 200 microns would hardly be noticeable.
In general, G-code produced by a slicer has a preamble that sets certain parameters like temperatures and speeds. Then it has a bunch of move codes like G1 and G0. Typically, there will only be one G0 line per layer that has a Z parameter. This is the line that changes the layer.
In this case, it was layer 168 that had the line:
G0 X143.779 Y205.684 Z33.8.
The only thing he had to do was delete from the top up to and including that line. Then he had to script a little preamble that would set everything up without crashing into the existing print. Essentially he did the normal startup script but moved the head higher than the print from the home position. Then he moved to the correct spot and lowered the head to 33.8 mm before resuming the script:
G0 F3000 Z35.8 G0 X143.779 Y205.684 G0 Z33.8
The thin layer height probably helped. If you were doing very thick layers, you could easily have part of the makeup layer droop. Then again, it might be worth a try.
As you might expect, though, the process did leave a little line around that layer. After the print completed, he used a hobby knife to trim the line and then sanded with fine sandpaper. The end result looks pretty good.
If you are too lazy to do all this work yourself, you can automate it. Of course, sometimes you need to save your 3D prints from yourself.
A very interesting article, thanks for firstly showing it can be done, and secondly a simple and clear description on how to do it. Good work Shippey123, I’ll definately bookmark this page for the next time I have an air-print.
First, congrats to Shippey123 for the effort and details in his post. I appreciate people sharing their efforts and solving challenges like this.
However, is this sort of fix really new to the world of 3D printing? I don’t own a 3D printer, nor have I ever used one, but knowing a bit about G code (I know more about RS274 gerber which is very similar), I wonder why this isn’t standard practice for 3D printer users for continuing failed prints. Is the level of Shippey123’s knowledge of G code uncommon in the realm of 3D printer users? If so, then another round of applause for Shippey123 for this solution.
I wouldn’t say it’s common practice by any stretch, but it has certainly been done before (I’ve done it myself as well). I think in many cases the time spent getting things set up to continue a print and the time doing post processing is offset a bit by the simplicity of just re-printing. For a large print taking several days it can certainly be worth it, but for smaller prints maybe not so much.
These were my thoughts to.
I remember in the pre-internet days when we had nothing more than DOS, there was the first PCB CADs like easytrax and autotrax.
The underlying .pcb files used a stringy protocol somewhat similar to internet protocols and G-Code we have today.
Many people wrote code to process and manipulate the .pcb protocol files to automate and enhance the result. Often in QBASIC. The same could be done for G-Code.
I guess not may people bother to look at the underlying protocols today because – if they have an issue then they can just google it.
I do the same now to. I will google first and if I am not satisfied with the results I will go and examine protocols.
Google is fast and easy and will often get quick results but it’s not always the best solution.
I think it would be of benefit for the purpose of increasing ones skill set to have a look at least one modern stringy protocol. Once you can handle one (which is not hard) then you will find that most of the modern stringy protocols have most aspects in common. Often it is little more than reserved keywords and line terminators that are different.
I did it too in a print roughly 2- 3 years ago; it also worked out in my case. Especially funny when printing for several hours and getting it screwed up thanks to a forced Windows update…
I’ve seen it used, and got to try it myself recently. Still, it’s nice to see a good write-up, and he avoids the mistake I made (starting too high) and cleanly explains all the important steps. Hopefully more people will now know that it’s possible :)
I have done this when the printer just disconnects from my computer, but I have found that editing all the gcode in repetier is a huge pain so I do control A and copy it all into an Excel file, then I can use find and replace and select or delete just what I want to in order to continue the print
Interesting fix. Most of the time with my printer the part will start to come loose first so I will have a perfect part up to some level, and it the part will wither move on the bed, or it will be a bit loose and the print head will knock it off by a bit, so than I have a bunch of printing that is offset to what is under it, until the next printhead collision, that one generally knocks the entire thing off the bed, and than I just get nests of filament all tangled up. I don’t think I have ever had a recoverable error. Still an interesting concept.
3D printing should be a process in a closed control loop. Computer should be aware when things go wrong and do corrections or abort and provide aid to recovery. Perhaps three cameras could be added to monitor the progress and compare it with expected partial result at each point of the process.
How about a custom firmware modification that writes the current gcode line number to a non-volitile external memory at every step. If the print stops, then on reboot, the printer can see where it left off, heat the nozzle a little so it won’t break on separation from the print, raise the head up, home x and y, heat everything back to operating temperature, lower by the same number of steps as it was raised, and resume printing from that line number. It’s not perfect, but maybe good enough.
there are printers with this function already, not sure if it’s now a feature in Marlin or not.
That would help for things point power failure. But in this case, the printer kept running, but was not extruding. So it was likely either some sort of clog/jam, or he ran out of filament.
I believe the latest Prusa has a low filament detector. I’m not sure how it works though.
That would only work if the fail is because of a power loss and not if the nozzle clogged like in this case. But it’s a good idea and it has been implemented in the Prusa i3 MK3. Only problem is that writing to EEPROM on every step would kill it in no time so instead they use some large capacitors to hold enough charge for the printer to detect the outage and write all the necessary info to EEPROM so it can resume after power comes back.
Much the same with common FLASH chips. Even they need some wear leveling. Perhaps SRAM as in Serial RAM with battery backup like a CR2032 would do the job. Maybe even a LIR2032 might hold enough charge.
That would help for things point power failure. But in this case, the printer kept running, but was not extruding. So it was likely either some sort of clog/jam, or he ran out of filament.
I believe the latest Prusa has a low filament detector. I’m not sure how it works though.
It’s an optical sensor, but it doesn’t work reliably with certain colors. Most other printers just use a mechanical switch.
” Another pessimistic adage is “no good deed goes unpunished.””
The optimist would say, “no bad deed goes unrewarded”.
Looks like writing some software to take care of the Gcode resuming shoudln’t be too much of a problem here (if you can code worth a damn at least)…
That’s what I thought. This sounds like something that could and should be automated. Prints failing after a great deal of printing time (and filament) are common enough that a script to do this would be very useful. This would take a gcode script and a Z value, replace the existing setup code with code that won’t crash into the part, skip over everything below the specified Z value, and copy everything from that point until the end. I’m not going to write that script myself, unless and until it happens to me, but that’s something I would certainly try rather than manually editing the file, just to avoid having to do the same work again later.
my printer is on a UPS for this reason. of course, my 2y old pushing buttons is still a problem… :)