Hey everyone,
Sorry if I missed a previous thread and am reposting a previously solved issue but I couldn’t find an answer.
My set up is rigid r 22002
Default frame.
Current versions of Arduino and ground control.
I use onshape and an application called Kiri:moto.
My problem is everything will be going great. Then for no apparent reason the gcode will call for a z axis movement but it is ignored. Sometimes in the raised position other times when the bit is down. From that point forward in the program it ignores all z axis commands, until a stop command is give. And I manually move the z axis to home or other coordinate.
I am at a loss right now. Thinking it might be the way Kiri:moto writes the codes as there are other quirks I don’t u sweat and completely. My next step is to switch to fusion360 and see if I get better results. Just tired of throwing boards away due to a line being cut through the middle of a piece.
Any insight would be appreciated.
Thanks
does it always fail at the same point in the cut?
If so, then just providing a g-code file that fails is probably enough, if not,
we would need to see the groundcontrol.log file as well (clear it out before
starting a run so it only contains that run to make it easier to see what’s
happening)
David Lang
It isn’t at the same point. I will clear the log in the morning and do another run. Thanks for the quick reply.
Started a cut today and 50% through the file it started to do it. i was watching it so i stopped it before it wrecked the piece. log and .nc file attached
NoChangeinZ.txt (12.8 KB)
cnc-006.nc (25.2 KB)
So, out of curiousity, did you stop it right when it sent the G0 Z2.0 command? Did it not move when that command was sent?
It was a little tricky to line the code up to the log file, but this is what I’m seeing:
Where line 423 in the nc file lines up with line 370 in the log file. According to the log, the Z command was sent, and then the program was stopped.
From this, it looks like the code is okay. From the log, I would guess that this is a mechanical issue. And based on the intermittent nature of the problem, it sounds like it could likely be the issue.
A couple things to check:
- Make sure that the depth adjustment sub-assembly is locked into the slot in the router body. The tab is notorious for popping out while the machine is running.
- Is the Z-axis binding? You may be able to fix that by checking if the clasp on the base is adjusted right. If it’s too loose, the router may be twisting in the base, and the motor won’t be able to move it. If it’s too tight, the base will clamp down on the router and the motor won’t be able to move it. You can tighten or loosen the clasp until the router is just able to move in the base without any slop.
- Is the signal cable coming loose during operation?
2 and 3 sound possible I will check those and try it again. Thanks.
Appears the z motor is binding up and causing my issues. Time to upgrade to the meticulous z axis. Thanks all for your help.
After further looking at the problem, realized it is the small chunk being cut out are jamming at the rigid dust collection exit tube. Then when the router goes down it squishes into the wood causing the motor to bind. Lesson learned and I’m printing the upgraded one off the community site.
Yeah, those kinda problems were what lead me to designing that in the first place. The stock base is a great way to get started, but I’ve found it’s often more trouble than it’s worth.
If you need any assistance with the build let me know. I’m more than happy to help. 