BUG: Pocket operations cutting as slots

To prevent slotting, the usual advise is to cut a slightly oversize pocket instead.

I have found a condition where the pocket is being cut as a slot - one path full depth, then the other, rather than alternating. It appears to be an interaction between a pocket cut followed by a contour cut.

I first cut a pocket down to 1/8" off the wasteboard. Then I run a contour, with tabs, down to the wasteboard.
Turtle Rock.c2d (596 KB)
I think this CC file, with these two paths enabled, shows the problem.

CC Version 743, CM 575, OS Win 10 fully updated, Shapeoko 3 XL.

Not seeing that in 743 (corrected from 752):

Please update:

Download page has version 743. Beta not available.

Version 743 is the only version available, there is nothing to update.

My apologies I meant 743.

743 is what I’m running. If you are not seeing this behaviour I’ll see if I can reliably replicate it.

Here is the C2D file that had the problem:
Turtle Rock.c2d (596 KB)
If you extract the GCode and load into NC Viewer (attached below), you can see starting at line 1745 that the machine is just finishing a contour. After that, it drops and continues cutting on the same contour, i.e. a slot. It finishes the first contour at 6930, then moves to the second contour that completes the pocket.

Instead, it should move over to the other contour and cut that before dropping.
Turtle Rock.nc (231.4 KB)

Here is a screenshot from NC viewer. You can see from the Rapid movements (red) that the cut plan is cutting to full depth before moving to the other cut path.

All the paths needed to clear the pocket are being generated, but they are being run in the wrong order.

The pocket requires two paths to clear. Lets call the outermost path of the pocket P1, the other P2. D1 through D4 are the different depths.

EXPECTED: P1D1->P2D1->P1D2->P2D2->P1D3->P2D3->P1D4->P2D4,
followed by the contour-with-tabs operation that completes cutting out the object. Cutting should run both paths at a given depth before proceeding to the next depth.

ACTUAL: P1D1->P1D2->P1D3->P1D4->P2D1->P2D2->P2D3->P2D4, followed by the contour-with-tabs cut.

From the NC file, you can see there is exactly ONE horizontal movement between the two paths, at line 6933. There should be 4, one for each depth.

Once the pocket is wider than twice the width of the bit, the problem goes away. In that case, the pocket is correctly cut width-first rather than depth-first.

I can reproduce what @mhotchin is seeing on build 743.

I have 2 machines, one with build 729 and the other I just downloaded an installed build 743. When I output the gcode from 729 I see 2 passes at each Z height as expected. When I use 743 I see 1 pass at each Z height followed by a second pass at each Z height.

@WillAdams - if you aren’t able to reproduce it, could it be an OS difference? I’m using Windows on both machines, are you by any chance a Mac user?

Here are the Z heights in the 743 generated file:

$ grep G1Z ~/users/Downloads/Turtle\ Rock.nc
G1Z-0.2500F50.0
G1Z-0.3750F50.0
G1Z-0.5000F50.0
G1Z-0.6000F50.0
G1Z-0.2500F50.0
G1Z-0.3750F50.0
G1Z-0.5000F50.0
G1Z-0.6000F50.0
G1Z-0.7350F50.0

and in the 729 file

$ grep G1Z c:/temp/test.nc
G1Z-0.2500F50.0
G1Z-0.2500F50.0
G1Z-0.3750F50.0
G1Z-0.3750F50.0
G1Z-0.5000F50.0
G1Z-0.5000F50.0
G1Z-0.6000F50.0
G1Z-0.6000F50.0
G1Z-0.7350F50.0

1 Like

I was able to repro using a simpler shape - 4 inch square with a .350 offset had the same problem.

Thanks.

I was finally able to figure out how to make a file which shows the problem so obviously that I was able to see it.

Filing a bug report now.

1 Like