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

Question

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?

---

Additional information:

• 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.

Answer 1

After watching the video, I see three unwanted behaviors, all consistent with a hypothesis that the printer is reading corrupted data from the gcode file:

• Moves to low but nonzero X or Y coordinate then immediately back are not homing, but misreading of the X or Y value for a G1 move command - perhaps flipping a bit so that a leading 1 looks like a 0, or hitting a parse error causing it to be truncated after the first 1 or 2 characters (making it appear to be a value in the range 0-9 or 0-99). The very next command would then move the head back to the correct position since these are absolute coordinates not relative.

• Periods of extreme slow speed could be the exact same thing (bit flip or truncation parsing) for the feedrate (F) value in the G1 commands.

• Extruder motor clicking could be the exact same thing for extruder position (E) value in the G1 commands.

If this is the case, it's possible that the SD card itself is unreliable (try other cards if you have any), that the contacts in the SD card slot are dirty, that there's electrical noise on the bus (from poor grounding or shielding elsewhere), that the controller board is defective, etc. If the problem occurs in the exact same location each time you print, it's almost surely the card; if it's random it's more likely to be one of the other causes.