I am cutting a project for a present. It is a fairly Long program cute estimation is about (400 minutes)
I have tried the project 2 separate times now. It cuts the first depth of the pocket without any issues but after about an hour and it goes to start the 2nd depth of the pocket the machine lowers way past the limit and drags it straight through the piece of wood ruining it.
Any suggestions to what is wrong?
I have already re-calculated all my tool paths (I use V-Carve).
I use the Probe and the Bit-Setter every time.
Have you tried checking the generated G-code in a standalone viewer ? Just to rule out any issue in the design/g-code.
Do I understand correctly that this is all in one single file, with a single tool programmed to cut XXX depth per pass, and the problem happens when going to the second depth pass of the same initial pocket ?
If the g-code is fine, and the first pass is fine, then it’s likely a mechanical thing:
any chance the endmill might be slipping in the collet during the cut ?
what are your feeds and speeds, plunge rate, material and endmill ? Could they be too aggressive ? Did you hear any suspicious sound while plunging ? The Z axis may be losing steps (but usually this gives the opposite effect, cuts shallower than they should be)
I have assumed the retract height (versus clearance on top of the Z axis) is not a problem, since the first pass works fine / at the correct depth (right ?)
Yes all of your assumptions are correct. I do not think the end mill is loosening because the router lowers extremely down past the depth it should be at not just a little. I also have been having an issue that after a little while randomly the machine will lose serial connections with my computer but I am not sure why.
The Z stepper motor is not loosing steps as far as I can tell, I am always in my shop working while it runs to listen to the sounds to make sure nothing is going amiss
.25EM into 3/4" Plywood
SPEED 16K
FEED 40 IN/MIN
Update: I just re-squared/ leveled my machine as well as flatened my wasteboard. I am going to run the program again and watch closely to see if I can catch teh G-Code line it fails at
PLUNGE 10IN/MIN
This is the dreaded EMI-related disconnect problem. You’ll need to ground things, first your router body and vacuum hose, see here for a couple of usual tricks to minimize EMI effects.
Ideally, try and capture a video of the moment when this could happen ?
Your feeds and speeds are fine, what depth per pass are you using though ? (I would stick to 0.125" max to be on the safe side)
oh i didnt even know about that issue ill definitely do some more reading on it.
and I am re-running the program now, so far its doing good past the point that it failed on the other two. No idea where the issue was but its working now, guess ill figure out if its still good when to goes to pass #3
Well your example piqued my interest, because I remember a similar issue reported by another member a few months ago that remained a mystery, and now I wonder if EMI might induce just enough data corruption in the Gcode characters being sent, to alter one plunge command.
Properly grounding the router and hose goes a long way to avoid EMI issues, so that’s worth doing anyway.
I mean it makes sense. Considering i build a bombproof- enclosure for my machine and wired everything to its own switch that definitely sounds like a possibility. Thank you for your Help!
I think this is unlikely since USB has CRC error detection; unless GRBL ignores error detection and sends the ACK regardless of data integrity, but I can’t think of any reason for that.
Good point. But then I’m not sure how I could get that error a few months back, which seemed to indicate that corrupt data made its way to the controller somehow.
or, thinking about this a little more, the EMI/ESD event could cause an error in the controller ‘downstream’ of the USB error detection; that could look like a single bad instruction and if it occurred between USB packets would be unlikely to trigger error detection.
If we had something more powerful that an Arduino in the controller, I would have suggested that adding a CRC in the GRBL protocol itself would be great to prevent this. But we don’t, so I won’t
I hope @JR_Woodcrafts is not getting freaked out by us discussing obscure USB communication matters, that may not have anything to do with his issue
hahahaha yeah I consider myself pretty tech savey and what not, but totally lost me when you stated talking about USB comms… I am going to ground everything in the next day or so, Then ill try it out. I really hope its not a unit issue…
not to mention watching an automated machine like a hawk until it messes up it a huge waste of time and attention haha
