OK this may be a long one… I have tried a lot…
The short synopsis is: things start milling fine, then it goes on a detour, then gets right back on track. If it was losing stepper motor steps it would get back on track but shifted. This gets RIGHT back on track for a while then takes another detour. Then gets back on track.
Setup is MPCNC with RAMPS board and dual endstops and a touch plat for Z axis homing.
GCODE created by ESTLCAM. Was using repetier host but switched to using SD card to eliminate the PC (more on that later)
Did some wood milling when I first built the MPCNC and all seemed fine.
My first attempt at milling aluminum was nearly a success then things went pear shaped fast. 3/5 of the way through the mill just went the wrong way…
I thought I had figured out the issue to be a DRV8825 overheat issue and the Y axis drivers stopped and it just kept moving in the X direction. Lowered the drive reference and reran the same GCODE off the same SD card and no issues. The job finished and the part looked as expected.
Here was my first attempt. Since it was my very first attempt I was babysitting it and as soon as it went for the little detour I hit reset fast.
After lowering the DRV8825 drive current here is the rerun
Exactly what I was expecting, a hexagon not all the way through. It was literally the same GCODE from the same file on the same SD card. Had not been changed. Worked… I was on cloud 9. Feeling pretty confident.
So I moved on to the task at hand, two parts for a boat bracket.
Created in TinkerCAD, exported as SVG and imported into ESTLCAM and saved as a project. It is still a pretty simple part. 6.5mm cutout with holding tabs. That’s it. Running at a slow feed and only .1mm per pass depth of cut. Pretty conservative. Here is what the toolpath looks like in ESTLCAM
I think this image actually contains pretty much the whole part story… not a complex part
I watched the ESTLCAM simulation. Nothing looked odd there.
So I set up my aluminum stock and started the job. After a few laps around things went pear shaped for no reason I could think of. Kind of messed up the stock so I decided to simply rerun the same job on the same stock. This time it didn’t plow into the work where it did the last time. kept going properly. Somewhere about 3mm depth of cut it stopped moving in the Z direction. Just kept doing the path but no Z change. Hmmm… Once I figured out Z had stopped moving, I reran AGAIN. Same GCODE. Same SD card. I know, insanity is doing the same thing and expecting a different result… but I GOT a different result… Since 3mm down is like 30 laps, I used the speed knob on the LCD to crank it up to 500% to do fast laps to get down to where the last fail was, then slowed it to like 50% to see if that was the issue. It went quite a ways then at some point went the wrong way.
I was running out of things to try so I decided maybe this was a hardware issue with the mega2560/RAMPS boards. I have spares of both. Wrote the exact same firmware that was on the original to the spare. The only things I did not have spares of were the DRV8825 driver boards. I swapped them from old to new. (spares of those are on their way…). I could have used the A4988 driver boards I had but I wanted to use the EXACT same firmware as the original. So new mega3560 board. New RAMPS board. Old DRV8825. Old LCD/SD card reader.
Got that up and running and ran it and things again went pear shaped. Second run and pear shaped in a different spot. When I am milling aluminum and things go bad I hit the reset pretty quick so I cannot tell what would have happened if I had let it go…
So I decided time for a piece of wood.
Mounted a scrap board and ran the job. When things went bad I let it run… THAT was interesting. The two round holes in the wood in the lower area were there already, scrap wood, the CNC did not do those…
You can see the part outline and the little “detour” it took on one pass. But in wood I just let it go and lo and behold it went back on track and carried on. Since this was wood, the slow feed rate was going to be killer long so I had used the LCD speed control to go 200% which is what it was running at when it failed.
I had this theory that playing with the speed may have CAUSED the issue… so I left it as was (didn’t touch it again, still at 200%) and let it run. It messed up a while later, plowed through some thick stock BUT GOT BACK ON PATH.
The way it kept getting back on path told me its not the steppers losing steps… its losing GCODE commands then getting the next few and its back on track.
It messed up a few more times and eventually I had to hit reset because it messed up in the Z direction finally and plowed through the stock and was heading for the floor but ran out of cutting edge on the end mill and started smoking the wood and the steppers were unhappy trying to push a smooth rotating shaft through 19mm of particleboard.
So… same GCODE file every time.
Full change of controller hardware (mega2560 and RAMPS board)
Same firmware on both.
Random drops of GCODE it feels like.
Sort of running out of ideas…
Things I am pondering…
Marlin Firmware: Am I having trouble reading SD card?
In the firmware I have enabled the following in the SD Card support section of configuration.h:
#define SPI_SPEED SPI_HALF_SPEED
I have the SD card set at half speed (because that’s the way its set on my 3D printer so I decided maybe that was conservative so I did the same. maybe I should try slower? Maybe I should enable CRC as in uncomment //#define SD_CHECK_AND_RETRY? I am not seeing any errors but not sure how they might appear.
Other than those I have zero thoughts and I am hoping the vast experience of this forum can shed some light and make me wiser.
Here are my Marlin config files if anybody cares.
Marlin_Configs.zip (75.5 KB)
