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.
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.
No end stops
Mac (for Fusion 360) but all attempts to route have been routing from SD Card.
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 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.
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.
this is a tough one…
