Incomplete / Incorrect Cuts

[jhndrx]

Workflow: Fusion 360 / UGS / GRBL Post / Magic Fairy Dust / XCarve 750mm (newer version) with X-Controller / Dewalt 611

I've been cutting out some Dice boxes and this is my third box. I've been doing a Save As on each box and modifying the initials and custom front design. The first two boxes went exactly as all simulations shown. However, this third box has deviated from the simulations on two separate operations and I cannot figure out why. One of which almost ruined the box. Heavy sanding saved it.

Since this is a double sided cut, I use a peg system for flipping. I drill holes placed equidistant from the center and its worked pretty well. Due to the depth of the cut (about 7/8") I cut a small pocket large enough for my Dewalt chuck to fit into as a precaution. On this cut, the machine decided to not cut the entire pocket out despite 3 different simulations showing it should. Two of the pockets it only did one spiral and the other two pockets it performed all but the last spiral.

 

Here is what happened next to a correct version. The bottom of the wood cutout picture corresponds to the left side of the above pictures.

Note the holes on the top right are smaller than the top left (by one spiral) and the bottom right holes only performed one spiral.

The next thing was a major issue as it damaged the box. When cutting out the box, I perform a contour cut with multiple depths including tabs. One one of the first passes, the machine seemed to go to the wrong point for one of the corners. It seemed to choose a point closer to the center causing it to slice out a section. Picture worth a thousand words:

 

I have not updated my GRBL controller or UGS between the different boxes I've cut. The only possible change is Fusion 360. But with the simulations showing exactly as I expect, i just don't know where the issue may lie. I've attached the NC files of the operations in question (untested by themselves, I grouped several operations for the actual cut), as well as the full box design. Any ideas would be greatly appreciated.

[GeorgeRoberts]

Hello,

Thanks for posting. Sorry to hear you are having issues.

I have taken a look at your files, as well as the Fusion file you uploaded. I have posted the file out with the generic GRBL post processor and the output code looks correct. All spirals seem to be included inside the file.

The move between contours should happen at the height specified inside of your operations, which in the code I posted, it seems to do.

Are you able to share the exact code which caused this issue?

Are you posting this as one large program, or a program separated into several files?

Finally, is there a way you can check if the axes were out of position after re-homing? A log of some sort? I'm wondering if the Z is losing steps and is not retracting to the full height

Cheers

[angelo.juras]

@jhndrx I am not sure what your tooling and holders look like, but another thing I would check is, make sure the tool isn't pulling out of the collet. On that picture where it looks like the tool dragged across the top of your part, I'm wondering if that's possible?

[jhndrx]

 @GeorgeRoberts @angelo.juras

Thank you for your quick responses.

---

@GeorgeRoberts wrote:

I have taken a look at your files, as well as the Fusion file you uploaded. I have posted the file out with the generic GRBL post processor and the output code looks correct. All spirals seem to be included inside the file.

The move between contours should happen at the height specified inside of your operations, which in the code I posted, it seems to do. 

---

This is what's confusing me the most. Everything "appears" fine.

---

GeorgeRoberts wrote: 

Are you able to share the exact code which caused this issue?

---

Over the weekend I'll try to reproduce the errors on some scrap with the smallest amount of operations to analyze.

---

GeorgeRoberts wrote: 

Are you posting this as one large program, or a program separated into several files?

---

I bundle operations based on bit so I'll post process all the operations in a row that share the same bit (roughing -> finishing -> detailing). I make sure to keep the ordering to prevent any collisions from "rest" machining. for this particular item, I have 7 different .NC files. I've been told there's a "manual bit change" I can include but changing bits can sometimes cause me to move the machine requiring a re-home and of course z probe. I use homing switches, G28, z-probe, and work home to keep everything reproducible.

---

@GeorgeRoberts wrote:

Finally, is there a way you can check if the axes were out of position after re-homing? A log of some sort? I'm wondering if the Z is losing steps and is not retracting to the full height

---

My controller is a GRBL based machine, I have not looked into any sort of logging for its positional data. I definitely will after these issues. I believe UGS displays the commands it Actually sends to the controller but I don't know anything about how to get what the controller is doing. I don't think any axis is losing steps physically with the machine, my only thoughts is some sort of float rounding errors but the simulations are fine. The operations that failed included other operations in the same NC file that continued to perform just fine after the mistakes. The entire cut through on the contour and the slice it took was all done during one run.

---

@angelo.juras wrote:

I am not sure what your tooling and holders look like, but another thing I would check is, make sure the tool isn't pulling out of the collet. On that picture where it looks like the tool dragged across the top of your part, I'm wondering if that's possible?

---

The bits in question have the plastic collet on them so I know the exact height they are in the collet. I use a Dewalt 611 router so its easy to get the bits nice and snug. The bit itself did not move out of the collet. If anything, I appeared to be cutting a little higher than my previous boxes but within an acceptable tolerance.

Here's what I surmise happened with the contour. I know the picture posted didn't really show both sides so here's a mockup:

The green path is what the machine should have done and is the path it followed for all paths except for one. One of the first paths decided to take the red path. I haven't done a ton of research into Gcode but I believe with straight lines it generates code saying "go to XYZ at speed SS" so perhaps for that one run it went to an incorrect point as illustrated by the red dot. This is where the .NC file would come in handy to verify. I will work on this tomorrow when I get home.

[angelo.juras]

Thanks for the feedback @jhndrx

With regard to the mock-up sketch and the red line and red dot. It should not do that. So would be great to analyze the code that ran that path.

Looking forward to hearing about your findings over the weekend. Feel free to share the code and we can look at it on our end.

Angelo

[jhndrx]

 @angelo.juras @GeorgeRoberts

---

angelo.juras wrote: 

With regard to the mock-up sketch and the red line and red dot. It should not do that. So would be great to analyze the code that ran that path.

---

Sadly, I couldn't get it to recreate the issue that cut the corner. However, I do have the pocket clearing issue. I shortened the code down to one pocket and ran it with UGS. The cut only performs one spiral after lead-inand then quits. I noticed in UGS that several "Error 33" were being thrown at the end. Quick googling of "GRBL Error 33" results in something about an issue with the arc calculations. Since the contour also has arcs in the corners, I wonder if it threw an error and continued on to other things resulting in cutting the corner short. Attaching the NC and the UGS outputs.

[daniel_lyall]

@jhndrx in you tool set up is the coolant settings set to disabled 

[jhndrx]

---

@daniel_lyall wrote:

in you tool set up is the coolant settings set to disabled 

---

@daniel_lyall No, I leave it at the default "Flood" setting. I saw where GRBL sends an error of 20 meaning unsupported command so it just skips it.

Would leaving this at the default setting have some other consequences?

[daniel_lyall]

some machines the posts can fail or the G code in the machine can fail if it does not support A coolant type call. 

M8 is a coolant call it may not be a problem at all. M7, M8 and M9 are the coolant calls,

If it's done properly in grbl the not supported G or M code should fail at the machine