Marlin: Printer wanders off in the middle of a print

[tcm0116]

Running RCBugFix and trying to print a gcode file of 6 fossil fish off the SD card and the printer will randomly wander in one axis, and then go back to where it was and resume. Here's a video showing the issue:

https://www.youtube.com/watch?v=y_-7lykyG14

The gcode file is a little over 15MB. Could this issue be related to the large file size? Also, after I cancel the print, the LCD goes blank, but I can press the encoder button to get the screen back. However, when I go into the Control menu, none of the options are displayed. It seems like it could be memory issue. Maybe a buffer overflow?

[ghost]

Try copying the file onto the SD card again.

Also, does it do the same thing if you print it from a serial connection?

[tcm0116]

I printed it via Repetier Host last night, and I think it worked better. One of the fish got messed up, but I'm not sure if it was due to the printer wandering off or not. Guess I need a camera.

[tcm0116]

Just tried to print another 15MB code file from the SD card (EnderDragon) and this time Marlin reset part way through the first layer. Prior to loading the gcode file to the SC card, I formatted the card just to be sure. Printing via Repeater Host again, and so far so good. I need to get another SD card to see if that makes a difference.

[Roxy-3D]

Printing via Repeater Host again, and so far so good. I need to get another SD card to see if that makes a difference.

If happens again... Probably it will do the same thing at the same place. If so... We need to see the actual GCode that causing it. You could turn on the 'Debug Communications' in PronterFace and see what line number it is at when it happens. And see what is there in the file.

I've seen problems where the GCode that is produced by the Slicer is really the fault. The GCode is telling the extruder to move off the bed.

[tcm0116]

It's only happening when printing from the SD card. Printing the exact same
gcode with Repeiter Host (or probably PronterFace) results in a successful
print with no wandering. That also doesn't explain the issues I was having with the menus or why Marlin reset on the second gcode.

[ghost]

Bad reader?

It's possible the file is getting corrupt when reading it. But, is it always the same spot during the print? Same layer, same move, etc...?

Can you post a link to the .gcode file that is failing on you? I can try it on mine.

[tcm0116]

I successfully printed a herringbone hear using the same SD card and reader using RC7. I'll see if I can revert back to RC7 and see what happens.

[twstdpear]

If you see it again, try printing some known troublesome jobs via USB to see if it continues or goes away..

I've seen this problem happen (never in the same place) when printing from an SD card but printing via USB always succeeded without a hitch. In both cases (two Prusa i3 style kit machines with RepRapDiscount LCD readers and RAMBo controllers, but that probably doesn't matter), it turned out to be interference picked up by the LCD/SD ribbon cables. Once the cables were well separated from the motor cables, the undesired behavior went away. Presumably the g-code being read from the SD card was being altered by the interference such that lines like "G1 X100 Y100 E1.2456" were being truncated to something like "G1 X1" or "G1 X100 Y1" When the next line came in, it went right back to where it was supposed to be, more or less. In one case, one of the builders did an wonderful job making his wiring look neat and clean, but unfortunately had tightly bundled his LCD/SD ribbon cables with his motor wiring, not realizing the potential problem.

[Jinxycob]

https://www.youtube.com/watch?v=ofvfxJFt4fA this happen to me lately with win10 and slicer some where between moving the SD from the PC to the RAMPS the gcode get corrupted,, files appears fine while in the PC read back using word pad but once in the ramps things go tits up.
its fine with cura but every time with slicer it failed.

[tcm0116]

@twstdpear if the data is getting garbled during reading from the SD card, I'm thinking that enabling SD_CHECK_AND_RETRY in the Configuration.h should resolve the issue. Do you agree?

[ghost]

Maybe check/re-seat/replace the LCD cables?

[MattWhelan]

I have this problem as well, but only if my display, with the card reader, is mounted on the chassis of the printer.

My working assumption has been vibration from print head movement rattling the card in the slot, and making it read poorly. I can't disprove the electrical interference hypothesis either though.

Either way, if I take the display assembly and set it on the desk next to the printer (cables still attached) it works just fine, so that's how I've been operating for a while. I may even design myself a nice little stand-alone stand for the display.

[Roxy-3D]

Moving the LCD also moves the ribbon cables. It might be worth while to zip tie the ribbon cables to the high current wires (like the nozzle heater and stepper motor wires) to see if it makes the problem worse. It is very possible you are fighting an electrical noise problem.

[ghost]

Better yet, instead of creating an issue, eliminate it.

1. Get 2 wires about 2 or so feet long and strip them back as long as your LCD cables are.
2. Lay the stripped part of the wires along the length of the LCD cables.
3. Tightly wrap the entire length with aluminum foil a few wraps.
4. Use tape to affix the foil.
5. Ground the other end of the wires you just wrapped up.

Note: Use EARTH ground not arduino ground. (Power Supply ground is a good spot.)

Shield created. Interference is not an issue anymore.

Vibration is a big killer of cheap electronics also.

[token47]

I had the same problem yesterday.

• 1.1.0-RC8
• Don't think it's cable problems, display on the table and not moving/vibrating
• Slicer was Simplify3D
• Printing was via USB
• Was printing the "gCreate_Official_Rocket_Ship" from thingiverse

At the middle of the print the head just goes all the way to X0 and comes back and continues as if nothing happened. After about 3 or 4 times, it happened on Y axys, went to Y0 and came back (the other axis do not change position while moving).

Interesting note: I used this setup for about 2 years without this problem, including RC8 since the day it was out. About 3 days ago I moved it from my graber to my new corexy, changing just some configurations (COREXY kinectics, size of bed, endstops at MAX and some other things) and for the first time I got this problem, the very first print after that.

Could be the model/gcode or could be some configuration I changed. If it happens again I will try to track it down.

[apballard]

Not sure if it's related, I've had the exact same problem in the past. It was when I enabled Lin_advance and was printing too fast, running x and y both at 16u-steps (all of them contributed). At the time reducing speed only helped a bit unless it was painfully slow < 30mm per second or so. Found reducing an axis to 8 or 4usteps helped the most.
Ultimately turning off lin_advance resolved the issue.
Again not sure if same thing.
What I found is it wandered to the same location at the same point of the print repeatedly.

[token47]

And it happened again, ruining a print of many hours. Only this time, it was the Z axis that wanted to go to a ride... it tried to go to near-zero position as X and Y do, I guess, crashing the nozzle in the middle of the object. I was lucky to be close to the printer, the sound was frightening and I could turn if of quickly.

Just a little earlier (about 3 or 4 layers) it happened to Y, just once, than this.

[token47]

@apballard not sure if this is related to your case, but thanks for the insight, will do some research. This setup is not much different from weeks before without problems, I only sped things up a little after moving to a better frame. Could be that.

EDIT: I confirmed and I don't have Linear Advance enabled (never had). The only thing I can think of that is different now is that I used to print at 50-60mm/s and now I'm printing at 80-90mm/s with 100mm/s travel.

[token47]

Well, this thing is really starting to annoy me. Never had it before, now it won't stop happening. One thing I noticed: one of the real movements is consumed when it does that. Instead of doing the right thing it wanders off like if something corrupted the coordinates where it was supposed to go, and on the next move it only goes back because they are absolute coordinates. That lost / corrupted move leave a mark on the object, in the form of absence of plastic.

I'm trying to make it reproducible but the prints are long ones and it's hard to find the right point. Still trying.

[thinkyhead]

This issue is known to be caused by data corruption due to a poor connection. Printing from host is usually safer even with a flaky USB connection because if a line is garbled, it will fail the checksum test and get sent again.

Printing at faster speeds can potentially exacerbate the issue due to variances in the noise level, inductance, etc.

[token47]

I'm printing using Simplify3D and USB connection. Sorry but I did not understand if this is the problem or if this should be safer (and I'm still getting it). I also am not sure if I have to turn any option on to check for errors or if it's the default.

EDIT: ok, found on the firmware menu, inside communications tab, "send line numbers and checksum". Was disabled, now it's enabled. Let's see if it helps.

[thinkyhead]

Apart from that, I've just patched SD_CHECK_AND_RETRY to address CRC errors. https://github.com/MarlinFirmware/Marlin/commit/e1702816f6fc2c74e20c246faf900f1805c3fa7f

[Roxy-3D]

My personal opinion is that the serial communications should have a serious 16 bit CRC instead of an 8 bit checksum. I know the legacy history of GCode has an 8 bit checksum and that is why we still have that. But it makes sense to me for us to support a robust error detection on a line by line basis. And I bet the host programs would move quickly to detect and support that mode of operation.

[thinkyhead]

Sounds like a good plan for 1.2.

[token47]

Two long prints after enabling checksum and no problems. I will report back if it happens again but it seems to be fixed. Thanks!!