Transition between tool paths causes bit to travel through material

Hey guys so I created a two part job in Carbide create a pocket cut and then a contour cut. The pocket went fine I had two parts that needed to have a 12mm square cut in them and then a contour cut to full depth.
The Pocket worked in both cuts but once complete and it moved to the contour it failed to raise the tool head enough and just cut its way to the start point in the project. I am using the CC6 and GRBL post processor to a Duet board.
So I am not a GCode genius but I can see at the end of pocket is raises Z to 22.860 and the material was 17.5 mm or so but then still before it started the move to the start of the Contour it lowered the Z and cut the part.

Start of GCode file:

G90
G21
(Cut.out.P...)
M05

M03S30000
G0X28.598Y117.457Z22.860
G1Z17.010F381.0
X28.527Y117.514F1143.0
X28.472Y117.578
X28.430Y117.654

This is where the toolpath changed from a Pocket to a Contour:

X102.207Y28.762
G0Z22.860
(Cut.Extra...)
S30000
X7.722Y78.867
G1Z17.060F381.0
X7.838Y78.762F1143.0
X7.964Y78.669
X8.090Y78.593
X8.218Y78.531
X8.347Y78.482
X8.462Y78.449
X8.620Y78.418
X8.790Y78.403

End of Gcode File:

X113.334Y37.051
X113.271Y37.103
Z22.860
M05
M02

Check the “Safe” or “retract” height in the program.

Another possibility is if your retract height is too high and you run out of Z travel, causing the Z axis to hit at the top and skip steps.

2 Likes

The retract height was set to 5 mm and I watched the job it for sure didnt skip or max out the Z, its like it tried to drop the tool head on the way to the next operation instead of move to the next location and then drop the tool head.

1 Like

So i ran the file again with the same results, as it moved from one toolpath to another it cut into the material as it moved from the finish point of the first toolpath and the 2nd toolpath in the cut list.

Do I have to run the 2 toolpaths separately even if they use the same bit for each cut?

No. Can you upload your entire gcode?

yeah for sure. thanks
LightSaberHolder1.nc (360.5 KB)

All the rapids from section to section are happening at 24.1mm. It loos like you need to be looking for a mechanical issue.

From NCViewer:


1 Like

I agree that is what it looked like to me in Gcode as well. It not mechanical for example the two pockets were cut with one tool path and it had to life the tool head to move between the two pockets and there was no issue with it cutting into the material while travelling. But when transitioning from the pocket toolpath to the contour toolpath that is where the tool head cleared the material and then as it was moving to the start of the contour the tool head lowered and cut into the material.

if you can reproduce this behavior, I suggest you manually check Z zero right after it happens. If the Z zero is not spot on anymore, either your tool slipped or you lost steps somehow.

1 Like

Have you tried saving the file again and reloading it?
I have had this happen a few times and why it happen I have no clue. Why did saving the file again fix it? Again. I have no clue.

If you look at where the damage is on your part the path in the NC file does not transit thru that area without axes losing steps, pulleys slipping or belts jumping teeth. Are the pockets to correct depth? Are the contours cutting to the correct depth? Do you have any pictures after cutting before the pieces were removed from the machine? You are doing slotting operations which puts the most load on your machine and tooling. Consider adding offset geometry and pocketing a slot that is 110-125% the diameter of the tool. This will reduce the tool engagement helping with heat build up, chip clearance, deflection, etc. It takes a bit longer but is well worth while.

That is good advice and yes sorry I see the confusion I should have taken a picture of the operation while it was on the machine. The parts were opposite of how I have them pictured so the damage actually matches up to this movement.
Yes all other dimensions and depths came out correctly.

That motion would have caused damage from the dog bone corner not half way down the side of the pocket.

1 Like

Fair point now that I look at it again.
Let me run another test tonight and take a video of it as it seams to be pretty reproducible.

Okay so hopefully this shows in more details what I am seeing on all cuts when I have multiple toolpaths setup in one job.

GCode ran:
Bottle Opener Test GRBL (1).nc (145.8 KB)

Carbide Job:
Bottle Opener Dew Design.c2d (120.8 KB)

Video of job running:

X86.404Y49.060
X86.309Y49.141
G0Z-1.400
Z7.000
(Contour.O…)
S30000 <-------------------What happens if you take this out?
X36.349Y25.822
G1Z-1.500F380.0
X36.933Y25.252F1100.0
X37.574Y24.654

The G-code does not contain the rapid motions in the work piece that are shown in your video. The move from the end of the bottle cap insert pocket to the magnet pocket is at Z 7.00. There were a few other places where the bit did not retract in the video. It is looking like a rapid move is missed by the control or not being sent to the control. The other cuts are showing mechanical repeatability. I’d try a different com cable/port, make sure there are no other tasks running on the computer, and if possible try a different computer with the sender.

Out of curiosity what controller are you running? Which G-code sender are you using? Which post processor did you select in Carbide Create? Are the files local or coming from network storage?

So I am using a Duet3D controller with 3.5 firmware on it. I am loading the Gcode file directly to the controller with no PC in the mix. And using the GRBL post processor when I export.

If I create something similar in Fusion with multiple tool paths it’s able to cut without the problem so it’s something specific to Carbide Creates Gcode but I like the program and would like to see about getting this issue resolved so i can use it more reliably.

Thanks for taking a look guys.

Does the version of F360 you are using export G0 motions (I thought this was one of the missing feature in the free version)? If you replace the G0 motions in the CC file with G1 moves does it behave differently?

Let me check a similar file I made in Fusion to see. I will post it back shortly.