6
$\begingroup$

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.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ 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) $\endgroup$
    – Lars Pötter
    Apr 10, 2016 at 14:19
  • $\begingroup$ The question is tagged marlin. I've edited the question to include where I'm printing from. I don't have a filament sensor. $\endgroup$
    – Tom van der Zanden
    Apr 10, 2016 at 14:45
  • 1
    $\begingroup$ 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. $\endgroup$
    – Tad McDole
    Aug 18, 2018 at 18:28

2 Answers 2

Reset to default
6
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ Eurgh! I don't like that Marlin does that. Interesting find, though. Would love to know how you figured that out. $\endgroup$
    – PostEpoch
    Apr 13, 2016 at 2:15
  • $\begingroup$ What is corrupt in G0 X1y3.54? $\endgroup$
    – Wirewrap
    Feb 26, 2018 at 20:33
  • $\begingroup$ @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. $\endgroup$
    – Tom van der Zanden
    Feb 26, 2018 at 21:08
1
$\begingroup$

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.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .