Random movement and reset when running G_code

Hi All - I’ve just finished my MPCNC which was a fun build - thank you Ryan!

I’m have an intermittent fault though (about 95% of attempts to rung code will fail). Runs G-gode for a while, then might do a few random 100mm or so traverses in X or Y, occasionally gets back to running the code, but then ultimately then resets. It does this at different points when attempting to run Gcode (which looks good in code view). Same behavior on the site provided sample crown.gcode file.

  1. I did not by parts from V1, but I’m running Ramps 1.4 from V1 download link. I modified the steps per mm in firmware on Arduino Mega clone since I have 20 tooth pulley (X, Y) and 16 micro steps on X,Y,Z (instead of 32 micro steps) since I have A4988 stepper drivers. Running from SD card on LCD 12864.

  2. No end stops

  3. Mac (for Fusion 360) but all attempts to route have been routing from SD Card.

  4. Pictures attached of 4 attempts to run the same g-gode showing different cuts each time (inconsistent error points), and failure to complete without a reset.

[attachment file=50427]
Picture of my setup.

[attachment file=50426]

Things I have tried so far to resolve the errors;

A) Swapper power supply (tried a 12v 2A and 12v 5A)

B) Tried several G-Gode samples including crown from V1

C) Reformatted SD card and tried multiple (3) SD cards

D) Dissasembled Arduino / Ramps Shiled / Stepper drivers to look for damage, bent pins etc. All looks OK

E) Uploaded blink arduino sample to check flashing works, then reflashed with Ramps 1.4 firmware

F) Checked 12v supply with multimeter.

Any other suggestions for me to try for trouble shooting ? I was think about buying another Arduino Mega incase its damaged somehow, but thought I’d try here in case anyone else has already solved these symptoms. I could also swap out A4988 drivers as I have 2 un-used, but seems like a long shot…

Thanks for reading!




My crown gcode fails? If that fails you have something wrong for sure.

Tape your motor connections if they come loose, boom goes the driver.

Try flipping the lcd cables so they are not sitting on top of the hot and electrically noisy drivers.

:grimacing: this is a tough one…

When it takes off, is it smooth or choppy? If it’s choppy, then maybe it’s something like it can only move in one direction.

Can you try with a different sender (repetier)? Maybe the LCD is somehow bad?

I can’t imagine why it would be making such good cuts and then it just jumps away like that.

The only other thing I can think of is that you fed a mogwai after midnight and it turned into a gremlin.

I’ll think about it some more.

Thanks for the suggestions gents. Further things I have tried;

G) I have moved the display wires out of the way as suggested.

H) Taped up my connections to prevent disconnection as suggested

I) Tried running from Octoprint to bypass the SD Card - may need some further attempts with this as I could traverse around, but stuggled to get gcode running

J) Swapper out motor drives with 2 spares to see if this helped, did not.


One further observation (not sure if it will help diagnose the issue). When it does the random movements it is always heading over to a zero point either X=0, Y=0 or Z=0 or some combination of these eg Y=o and X=0. Its like its getting a bogus home command that’s not in the gcode. The blue X in the photo attached shows the origin for the prints to illustrate how the long miss-cuts are heading to home.

[attachment file=50466]

I have ordered a whole new electronics set-up so will start with a clean slate, but please keep any suggestions coming of what else I should be looking at.


What about my crown gcode? It is a know good code verified many times.

Chances are really good you have bad gcode, like not having a “f” command on every line, usually missing during a G0 rapid command and over driving the electronics.

A long time ago, there was problems with one type of comment in octoprint (it didn’t like the parenthesis, or the semicolon, but I don’t remember which).

You said earlier you saw the problem with Ryan’s gcode. For your own sanity, I hope you are still testing with that. That has been ran on dozens of machines without issue (well, the issues were with the machines).

My gut is still thinking there is a problem transmitting the gcode to Marlin. Something isn’t being read right, and it’s putting in a 0. Something like:

G01 X42.5 Y45.67

is getting cutoff, or something, and it’s going to zero. IDK what would happen if it just didn’t have the number (like G01 X42.5 Y).

If you have a raspberry pi, and you don’t want to figure out the octopi thing (or can’t) you can send gcode with the pronsole from pronterface. You should be able to do that all from the command line, but I’m very comfortable with Linux, so I think all that stuff is easier than it is.

Problem has been solved !

I found that moving the wires for the stepper motors away from the cables for the display/SD reader fixed the issue. I ran a test; used a pen to draw the crown.gcode 8 times with runs 1, 3, 5, 7 having wires clear from each other

[attachment file=50519]

, and runs 2, 4, 6, 8 having the wires all lying on top of each other. [attachment file=50520]

Wires clear was successful 100% of the time (Left side of photo)

Wires overlapping was successful 25% of the time. (right side of photo)

[attachment file=50521]

Since then all of my routing efforts have worked without issue.

[attachment file=50522]

Lesson learned : Keep noisy stepper motor wires away from SD Card and Display cables

Thanks for all the input / discussion that helped solve this.

1 Like

Are you sure it’s not a gremlin trick?

Seriously, that’s great. If you twist the stepper wires together, they will create a lot less noise.

You can twist them easily by clamping one side to a table and putting the other side in the chick of a drill.

Wire management for the win!

This may have solved my problem. I love this forum.