<p>Beides a corrupt SD card that stores worng bits, leading to absurd commands, it's also possible that ithers parts in the Creatin of the file are compromised:</p>

<p>This can for example happen if the card is removed during writing - but in this case it should be mostly an incomplete file on importing into an interpreter.</p>

<p>More a random distribution of bad commands would appear if the writing process in itself is faulty, for example if the SD Port is defect or the adapter hast a error. Another way that writing can fail is if the drivers for the SD card adapter/port are corrupted. </p>

<p>To detect a bad file or corrupted card is possible by re-importing the G-Code into a slicer (for example CURA allows this) and look at the tool paths. If any port does this with any card, software is to blame: See if it persists after a driver update (rare!) and a reinstall of the slicer. If it fails in one port but works in a different the port or adapter might bei at fault and might need replacement. If it is endemic to one card, this one is corrupt and to be thrown out. If it is endemic to a single file, overwrite it with a new one - sometimes writing fails for reasons that are almost impossible to understand.</p>

<p>If the file&amp;card are fine but read wrongly at the printer, then the card reader in the printer or the board are to blame.</p>

CC BY-SA 4.0
2018-08-19T08:41:28.657Z
2018-08-19T08:52:48.047Z
2018-08-19T08:52:48.047Z
Trish
<p>The issue was due to a corrupt SD-card, which was occasionally having some garbage read from it. It turns out that Marlin will try interpret a corrupt move command like <code>G0 X1q3.54</code> and still read as many numbers as it can. In this example, it would be interpreted as <code>G0 X1</code> rather than (as might have been intended) <code>G0 X103.54</code>.</p>

<p>This explains my symptoms perfectly:</p>

<ul>
<li><p>X and Y always moved to (approximately) their home positions, but it was always only one of them (it's quite unlikely that both moves are corrupted).</p></li>
<li><p>Z was not affected because Z moves are much rarer in the G-code (only on layer change) and thus it was very unlikely that a Z move would be affected.</p></li>
<li><p>E was not affected since a request to move E to near 0 would be prevented by Marlin's long extrusion prevention.</p></li>
</ul>

CC BY-SA 3.0
2016-04-13T02:15:33.597Z
Eurgh! I don't like that Marlin does that. Interesting find, though. Would love to know how you figured that out.
PostEpoch
CC BY-SA 3.0
2018-02-26T20:33:29.883Z
What is corrupt in ``G0 X1y3.54``?
Wirewrap
CC BY-SA 3.0
2018-02-26T21:08:32.497Z
@Wirewrap My intention was that the "uncorrupted" G-code would have been something like `G0 X103.54` and I replaced the 0 by a random character. Unfortunately I picked a really confusing random character. Thank you for pointing that out.
Tom van der Zanden
CC BY-SA 3.0
2016-04-10T20:50:21.837Z
2018-02-26T21:09:15.713Z
2018-02-26T21:09:15.713Z
Tom van der Zanden
<p>During printing, my printer occasionally makes some mystery moves: it will very slowly move either the X or Y axis all the way to the left/front, before very slowly moving back to its original position and resuming the print as normal. I've checked my G-code files, and the moves are definitely not part of the G-code. What could be causing this?</p>

<p>I'm printing from an SD card on a Cartesian printer.</p>

CC BY-SA 4.0
2018-08-18T18:28:45.550Z
Just had the same issue. I could print fine from the computer but load the same file to disk and get the random traveling to the 0 points on x and y at completely at random.
Tad McDole
CC BY-SA 3.0
2016-04-10T14:19:41.073Z
Which Firmware(Marlin,..)? Which printer(Cartesian, delta,..)? Extensions(Out of Filament sensor,..) ? Source of G-Codes (Printing from SD Card or from Serial interface)? Sounds like the printer is pausing the print. Causes might be no G-Codes (Slow serial connection) or some other signal(Out of filament sensor triggering)
Lars Pötter
CC BY-SA 3.0
2016-04-10T14:45:19.953Z
The question is tagged marlin. I've edited the question to include where I'm printing from. I don't have a filament sensor.
Tom van der Zanden
<g-code><marlin>
Printer randomly moves to home during printing, then resumes as normal
Tom van der Zanden
# Printer randomly moves to home during printing, then resumes as normal

(Asked by: username_0 on 2016-04-10)

During printing, my printer occasionally makes some mystery moves: it will very slowly move either the X or Y axis all the way to the left/front, before very slowly moving back to its original position and resuming the print as normal. I've checked my G-code files, and the moves are definitely not part of the G-code. What could be causing this?

I'm printing from an SD card on a Cartesian printer.

**Tags:** g-code, marlin
> **Comments:**
> **username_2**: Which Firmware(Marlin,..)? Which printer(Cartesian, delta,..)? Extensions(Out of Filament sensor,..) ? Source of G-Codes (Printing from SD Card or from Serial interface)? Sounds like the printer is pausing the print. Causes might be no G-Codes (Slow serial connection) or some other signal(Out of filament sensor triggering)  
> **username_0**: The question is tagged marlin. I've edited the question to include where I'm printing from. I don't have a filament sensor.  
> **username_1**: Just had the same issue. I could print fine from the computer but load the same file to disk and get the random traveling to the 0 points on x and y at completely at random.  

---

## 2 answers

### Answer by username_0 on 2016-04-10. Score: 6 | Accepted answer

The issue was due to a corrupt SD-card, which was occasionally having some garbage read from it. It turns out that Marlin will try interpret a corrupt move command like `G0 X1q3.54` and still read as many numbers as it can. In this example, it would be interpreted as `G0 X1` rather than (as might have been intended) `G0 X103.54`.

This explains my symptoms perfectly:

* X and Y always moved to (approximately) their home positions, but it was always only one of them (it's quite unlikely that both moves are corrupted).
* Z was not affected because Z moves are much rarer in the G-code (only on layer change) and thus it was very unlikely that a Z move would be affected.
* E was not affected since a request to move E to near 0 would be prevented by Marlin's long extrusion prevention.

> **Comments:**
> **username_4**: Eurgh! I don't like that Marlin does that. Interesting find, though. Would love to know how you figured that out.  
> **username_5**: What is corrupt in ``G0 X1y3.54``?  
> **username_0**: @Wirewrap My intention was that the "uncorrupted" G-code would have been something like `G0 X103.54` and I replaced the 0 by a random character. Unfortunately I picked a really confusing random character. Thank you for pointing that out.  

---

### Answer by username_3 on 2018-08-19. Score: 1

Beides a corrupt SD card that stores worng bits, leading to absurd commands, it's also possible that ithers parts in the Creatin of the file are compromised:

This can for example happen if the card is removed during writing - but in this case it should be mostly an incomplete file on importing into an interpreter.

More a random distribution of bad commands would appear if the writing process in itself is faulty, for example if the SD Port is defect or the adapter hast a error. Another way that writing can fail is if the drivers for the SD card adapter/port are corrupted.

To detect a bad file or corrupted card is possible by re-importing the G-Code into a slicer (for example CURA allows this) and look at the tool paths. If any port does this with any card, software is to blame: See if it persists after a driver update (rare!) and a reinstall of the slicer. If it fails in one port but works in a different the port or adapter might bei at fault and might need replacement. If it is endemic to one card, this one is corrupt and to be thrown out. If it is endemic to a single file, overwrite it with a new one - sometimes writing fails for reasons that are almost impossible to understand.

If the file&card are fine but read wrongly at the printer, then the card reader in the printer or the board are to blame.


---

