I’ve put together an MPCNC as a stepping stone to a lowrider, got carried away a little so its a 1.6mx1.6m work surface.
Currently though I’m having a reoccurring issue with the RAMPs resetting itself partway through carving sessions. Have rerun the same project several times and the restart is occurring at same place each time. This is making me think something in the gcode is triggering it rather than heat/power issues or the like. Cant capture exactly which line though, when it resets a yellow light blinks briefly on the ramps board then the display reset showing XYZ as 0,0,0 and waiting for me to do something.
Am working in ESTLCAM, and have recompiled in there several times as well so doesn’t appear to be a once off. I’m using what I believe are pretty conservative travel speeds for everything, am still in process of dialling in, and I’m pretty sure I’ve followed the ESTLCAM setup tutorial, although some of the screens in the program do differ from the screenshots.
Going through the forums the closest match I can find is the z-axis speed issue, I’ve attached my gcode, the fastest rate of travel I can find in there is F2100 but that’s for an x-y fast travel I believe. The Z movements on their own seem to be at F480, although I have noticed the combination movements in XYZ appear to be at 600.
That said as I typed that I noticed this:
G00 X211.1080 Y90.6715 Z2.0000 F2100 S24000
G01 X211.1080 Y90.6715 Z-12.0000 F600 S24000
Which the second line seems (I’m not super adept at reading gcode) to indicate it was a long z movement at an F600 feed rate. Would this be my problem, and if it is, can anyone give insight as to why ESTLCAM is writing it like this? Have attached screenshot of all relevant feed rates I think, My rapid on Z is 480 as per tutorial, plunge is a sedate 3mm/s but for some reason that Z movement is happening at what I think is the XY speed of F600…
Apologies for long post, first time posting about the build and asking a CNC type question so trying to make sure there’s a enough info for a diagnosis.
Thanks Guys, apologies for delay, am in a +8 timezone and had to call it a night.
With repeat I ticked it for everything under the co-ordinates tab, wasn’t quite sure which to repeat when reading about it in another post, should it be just for Y? Edit Sorry should also mention that first was running the project with just the defaults ticked, then while troubleshooting I ticked then all, the Ramps restarted at the same place in the program in both scenarios.*
With ESTLCAM I’m running 10.039, and marlin firmware I believe is the latest, installed only a month or so ago.
Dumb question, are you sure all the gcode made it to the store card? I’ve had some stupid file issues that have caused an incomplete file to make it to the SD and it looks a lot like this.
Ah good idea. Just did the check and it looks like the line counts are the same and all of the gcodes are ending with an M05 command so I think they’re complete.
I’m going to try dropping the xy tool speeds and rerunning it, have this half baked notion that ESTLCAM is treating a z axis plunge as an xyz movement. The part of the cut where its stopping at is after it is cutting about 30mm deep, picks up the bit, traverses the work, and then drops the bit back down again. Thinking that if for whatever reason ESTLCAM is running that z drop at the XY speed it could be what’s resetting the board as per the z axis issue that’s appeared elsewhere on forum.
Have noticed while combing through the ESTLCAM that there’s a note in the tool list quick help for the f(z) variable that it does not have any effect on linear 3d strategies in the X and Y direction. If I’m reading the gcode right, for whatever reason the software is treating the vertical plunge below from Z2 to Z-12 as an XYZ movement and trying to do it at a feedrate of F600, when I should be trying to limit it at F480.
That is odd, normally you only see that in a travel in the xy as well, meaning it is going to take so long to get to the xy coordinates there the z will actually be moving slowly anyway (hard to explain). Kind of a shot in the dark but maybe try unchecking repeat box in the feed rate panel for the XY axes. Might be a bug. Then look for the same line and see if it works.
Yep I think I’m with you, on an XYZ the bit should be travelling along the hypotenuse, so the actual feed on the Z is being slowed down as its also travelling the XY. Just removed the repeat on X and Y and rerun, here’s the same line I’ve been quoting above, full gcode attached. It’s still giving me an F600 even on an exclusively Z movement which I cant figure out, F(z) is definitely set to 3mm/s
Have been having the program running in the background with the XY travel limited to 7mm/s and can confirm it has now passed the point where it was previously stalling. Looks like this might be the right track… but not sure what setting it is in ESLTCAM that causing the high Z feeds. Am contemplating putting together a quick script to sanity check gcode for the mpcnc. Calculate the z travel for each line of code and tweak the feed speeds to keep vertical movement under 480. Would allow me to bump up the xy travels again without worrying about the board resetting if a carve needs a very steep Z movement with only a little XY in it
All your z movements are set at 10mm/s, what the heck. You’re rapids even seem to be right but the plunge is off. Double check the correct tool is selected for that path. Your very first z plunge is wrong so check to make sure all the paths have the correct tool (speeds ) selected. If it is, uninstall and reinstall. I have been making cuts and edits all week and mine has been running perfectly.
Just double checking tooling and that all looks correct, but just reminded me of a bit of weirdness I had with the software when first setting up where it kept wiping the tools I’d entered in. Just double checked through the tools and have noticed two have been given the same number which can’t be helping. Will go for a wipe and fresh install. Thanks very much for help with this, looks like it’s estlcam and not the mpcnc setup that’s causing the issue.