# My 3D printer checks axes home during print, often wrecking the print

My Tevo Tornado has picked up this habit along the way of checking axes during a print.

(I say picked up because it didn't exhibit any problems when I got it. As far as I can tell the problem presented on their own. The first thing I did to it was flashing the firmware after posting this question as per one of the comments suggestions)

It is mostly fine when it happens on the X or Y-axis, as the only resulting issue is a string on the outside of the print, but it's a problem on the Z-axis as you can imagine. I just had a print wrecked as the nozzle unit got lowered into it and started pushing against it. I used to slice with Cura but have since moved to Slic3r, the issue remains. I don't think it's a G-code problem as it doesn't happen at the same points during prints.

While X and Y-axis checks are relatively common (1 every 15-20 minutes or so) the Z-axis checks have happened only twice on longer prints with devastating results.

I'm assuming this is a software/firmware/settings issue. What am I missing?

• Another thing that I've not mentioned but I think it's related: with the same randomness as the axes homing, the extruder from time to time will pull back a good 5 to 8 cm of filament and then pull it back in, stopping momentarily the print and causing blotches and melts.

• I've re-flashed the firmware, the issues are still present and I can confirm that the weird movements still occur. So far it exhibits X and Y homing on a shorter print (2hrs). By the way, I say it's homing because that's what I'm assuming it's doing as I can't explain it in any other way, to be honest.

• In the file I'm currently printing there are four G28 commands, but they are not in the movement bits of the file. There's one at the start, one after filament END code and two in what I'm assuming are references for defined parameters denoted by ';' after the END filament code as well.

• This is what the G28 I was referring to is at the end

M107 ; Filament-specific end gcode
;END gcode for filament
M104 S0 ; turn off temperature
G28 X0 ; home X axis
M84 ; disable motors


It just homes the X axis

• The printer also randomly turns itself off and on again during printing causing half-finished prints.

• I'm using pretty much the default settings off of Cura and Slic3r, so no fancy editing. The G-code that it spits out is probably as standard as it gets.

• There is nothing else connected to the printer (like Octoprint), that could be sending commands. The printer is pretty much how it came out of the factory.

• Here's a video of the printer exhibiting the bad behaviour. There is what I thought was the homing of the axes but upon further inspection sometimes it doesn't touch the sensor at the end. The clips where it seemingly almost stops and proceeds to produce a grinding noise are the ones where the extruder is retracting and pulling back in the filament. There are a couple of clips where the printer slows down randomly to a very slow pace. Fortunately no negative Z-axis movements on this print so far. There were many more of these episodes but I didn't catch them on video.

• Here are two G-code files a shorter one and a longer one.

• Switching the SD card to a different and reliable one has not fixed the problem.

• Completely anecdotal piece of info: it seems that the number of errors increases as the printer advances. It seems that at the beginning of a new day, the printer is less error prone, as if it needed a rest. Just turning it off and on does not yield the same results. This piece of info might help to narrow it down maybe?

• Switching outlets does not fix the problem.

• Because of the seemingly increasing nature of the number of errors reported before, I've opened up the housing of the main board to check for any issues relating to cooling. Apart for some dust (now removed), everything seems fine.

• I've connected the printer via USB to my laptop and tried to run it through Cura and Pronterface. In both cases any command I send through the software does not get executed. In particular when I run a basic home command or axis movement through Pronterface it spits out the following in an endless loop without actually doing anything:

echo:busy: processing


The drivers are installed on the computer. I can see the printer appear on a COM and it seemingly connects fine. If when connected to PC I send a home command from the printer itself, it won't work but appear as processing in the software as well.

• You can't have G28 in filament end G-code. It might be inserted at places during the print. You also can't have it in the job end G-code unless you want to collide with the object after printing finishes, likely destroying it. (In theory you can do auto ejection this way, but it requires a good deal of care for how you do it and it's risky.) Jul 25, 2021 at 15:11
• Normally, homing of X and Y is standard practice when the printer has lost steps in case trinamic stepper drivers are used and if correctly set up. I've never heard about Z homing however, that is very strange behavior. Is there any way we could device a strategy to troubleshoot this problem. E.g. is is actually homing, or is the gantry lowering because of the weight pushing it down due to a loss of power (unlikely, just a long shot).
– 0scar
Jul 26, 2021 at 7:36
• Thanks for the suggestions. I was thinking about filming the printer in action and share with the community the video of the moments it messes up. I've had this printer for a while but I'm in no way an expert so there might be things I'm missing. Jul 26, 2021 at 9:59
• Does this answer your question? Printer randomly moves to home during printing, then resumes as normal Aug 6, 2021 at 8:06
• No. As I've stated in the updates and the comments to this thread the SD card is not at fault. Aug 6, 2021 at 12:43