<p>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:</p>
<ul>
<li><p>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.</p>
</li>
<li><p>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.</p>
</li>
<li><p>Extruder motor clicking could be the exact same thing for extruder position (E) value in the G1 commands.</p>
</li>
</ul>
<p>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.</p>

CC BY-SA 4.0
2021-07-27T23:38:07.977Z
2021-07-27T23:38:07.977Z
R.. GitHub STOP HELPING ICE
<p>My Tevo Tornado has picked up this habit along the way of checking axes during a print.</p>
<p><em>(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)</em></p>
<p>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.</p>
<p>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.</p>
<p>I'm assuming this is a software/firmware/settings issue. What am I missing?</p>
<hr />
<p>Additional information:</p>
<ul>
<li><p>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.</p>
</li>
<li><p>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.</p>
</li>
<li><p>In the file I'm currently printing there are four <code>G28</code> 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.</p>
</li>
<li><p>This is what the <code>G28</code> I was referring to is at the end</p>
<pre><code>M107 ; Filament-specific end gcode 
;END gcode for filament 
M104 S0 ; turn off temperature 
G28 X0 ; home X axis 
M84 ; disable motors 
</code></pre>
<p>It just homes the X axis</p>
</li>
<li><p>The printer also randomly turns itself off and on again during printing causing half-finished prints.</p>
</li>
<li><p>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.</p>
</li>
<li><p>There is <em>nothing else</em> connected to the printer (like Octoprint), that could be sending commands. The printer is pretty much how it came out of the factory.</p>
</li>
<li><p>Here's a <a href="https://drive.google.com/file/d/1psfEsagBA6_0NKIJo1x4xoQ1zPE8vW6f/view?usp=sharing" rel="nofollow noreferrer">video</a> 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.</p>
</li>
<li><p>Here are two G-code files a <a href="https://drive.google.com/file/d/19LipZuNWKKeRSRA2wpfsaIWkhrZQPX7b/view?usp=sharing" rel="nofollow noreferrer">shorter</a> one and a <a href="https://drive.google.com/file/d/1jzMa7dre_kMeKZA6d0p5Tg63avEVBxsN/view?usp=sharing" rel="nofollow noreferrer">longer</a> one.</p>
</li>
<li><p>Switching the SD card to a different and reliable one has not fixed the problem.</p>
</li>
<li><p>Completely anecdotal piece of info: it <em><strong>seems</strong></em> 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 <em>if</em> 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?</p>
</li>
<li><p>Switching outlets does not fix the problem.</p>
</li>
<li><p>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.</p>
</li>
<li><p>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:</p>
<pre><code>echo:busy: processing
</code></pre>
<p>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.</p>
</li>
</ul>

CC BY-SA 4.0
2021-07-25T15:11:55.337Z
[You can't have G28 in filament end G-code](https://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29). 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.)
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2021-07-26T07:36:59.357Z
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
CC BY-SA 4.0
2021-07-26T09:59:19.673Z
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.
delghen
CC BY-SA 4.0
2021-07-26T10:02:23.427Z
@Greenonline, yes it didn't have any of these problems when I got it. As far as I can tell nothing changed as far as the printer is concerned with it, which is why I'm open to suggestions like Oscars' that it could be a mechanical problem, like skipping steps (?), and the computer has to correct for the inconsistencies by homing.
delghen
CC BY-SA 4.0
2021-07-29T07:52:25.370Z
The SD card is not the culprit I am afraid. It still exhibits the same problems after switching it. I will try with a different outlet to rule out any grounding problems. Will report back with what I find.
One thing I have noticed is, and it could just be completely anecdotal, that the number of errors seem to increase as the print advances.
delghen
CC BY-SA 4.0
2021-07-30T13:36:38.513Z
Ground problems would not be with mains ground, but with the signal lines from the controller (to stepper drivers, etc.) where high frequency noise might cause interference corrupting the data on the SPI bus to the SD card. Do you have somewhere you could try setting up OctoPrint to stream the print over USB instead of using the SD card to see if the problem goes away? Is the problem at the same point each time you print, or different points in the job?
R.. GitHub STOP HELPING ICE
CC BY-SA 4.0
2021-07-30T19:19:09.000Z
It's completely random. I have a raspberry pi and a couple arduinos. I'll look into it and see if they are compatible with this usecase. Couldn't I just stream it from my laptop as well?
I appreciate you following up with this quirky problem by the way, thank you.
delghen
CC BY-SA 4.0
2021-07-31T10:29:48.193Z
Updated in regards of printer connecting over USB
delghen
CC BY-SA 4.0
2021-08-06T08:06:25.067Z
Does this answer your question? [Printer randomly moves to home during printing, then resumes as normal](https://3dprinting.stackexchange.com/questions/962/printer-randomly-moves-to-home-during-printing-then-resumes-as-normal)
Tom van der Zanden
CC BY-SA 4.0
2021-08-06T12:43:21.063Z
No. As I've stated in the updates and the comments to this thread the SD card is not at fault.
delghen
<ultimaker-cura><g-code><z-axis><slic3r><tevo-tornado>
My 3D printer checks axes home during print, often wrecking the print
delghen
# My 3D printer checks axes home during print, often wrecking the print

(Asked by: username_0 on 2021-07-24)

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.

**Tags:** ultimaker-cura, g-code, z-axis, slic3r, tevo-tornado
> **Comments:**
> **username_1**: [You can't have G28 in filament end G-code](https://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29). 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.)  
> **username_2**: 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).  
> **username_0**: 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.  
> **username_0**: @Greenonline, yes it didn't have any of these problems when I got it. As far as I can tell nothing changed as far as the printer is concerned with it, which is why I'm open to suggestions like Oscars' that it could be a mechanical problem, like skipping steps (?), and the computer has to correct for the inconsistencies by homing.  
> **username_0**: The SD card is not the culprit I am afraid. It still exhibits the same problems after switching it. I will try with a different outlet to rule out any grounding problems. Will report back with what I find. One thing I have noticed is, and it could just be completely anecdotal, that the number of errors seem to increase as the print advances.  
> **username_1**: Ground problems would not be with mains ground, but with the signal lines from the controller (to stepper drivers, etc.) where high frequency noise might cause interference corrupting the data on the SPI bus to the SD card. Do you have somewhere you could try setting up OctoPrint to stream the print over USB instead of using the SD card to see if the problem goes away? Is the problem at the same point each time you print, or different points in the job?  
> **username_0**: It's completely random. I have a raspberry pi and a couple arduinos. I'll look into it and see if they are compatible with this usecase. Couldn't I just stream it from my laptop as well? I appreciate you following up with this quirky problem by the way, thank you.  
> **username_0**: Updated in regards of printer connecting over USB  
> **username_3**: Does this answer your question? [Printer randomly moves to home during printing, then resumes as normal](https://3dprinting.stackexchange.com/questions/962/printer-randomly-moves-to-home-during-printing-then-resumes-as-normal)  
> **username_0**: No. As I've stated in the updates and the comments to this thread the SD card is not at fault.  

---

## 1 answers

### Answer by username_1 on 2021-07-27. Score: 5

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.


---

