Pocket Depths

[hdtheater]

I recently worked on a piece and as the pockets were cut there were differences in the Z depth as it carved it. I have included a couple photos for reference.







I thought by table might not be the same height across the length and width, but that particular path is the same depth throughout the piece and then it goes back to normal depth on the next pass. The differences happen on the same toolpath. The first and third pieces are a good example of this.

I used 1/4" downward spiral end mill for the larger bit and then a 1/16" single flute for the smaller bit. There are no differences in height from the 1/4" to 1/16" toolpaths.

Can this be remedied though maintenance on the Shark or should I set my software differently? This has happened on other pieces as well.

Thanks,

Eric

[jeb2cav]

Hi Eric,

I ran into this back in January. From you description, you are seeing this difference in height when the same, single, toolpath is being used (of course no tool change). So, after repeating this - having the same thoughts as you did for troubleshooting - the one thing I noticed is that the single tool path did really have 2 distinct cuts - ie at the start of the cut, it moved from 0,0,0 to the "first" start point, cut for a while - then the tool lifted up and moved to a "second" start point, and cut for a while. The difference in the pocket height was along the "edge" of the two cuts (each with a different start point).

A picture hopefully will help complete the explanation of what I'm describing:

One Tap file - 2 sections planned for cut

The result is very similar/the same as your pics.

One Tap File - 2 sections - Result

I sent this and the VCarve project off to Tim after some discussion. I figured out a way using the tool settings for the pocket tool that resulted in a single "pass" or cut across the same area. So, I told Tim - "Just let this go - if it is a problem with how I'm using the tool, I've found a work around. If it's a limitation of the tool, I've found a work around. Clearly not something other folks are running into."

At the time, I thought this was a weakness or limitation of the tool. Given your experience with what appears to be the same type of case, it looks like this opinion has some merit. In the end, as long as I know the condition and can work around it, I can live with it.

Assuming you're using the Pocket Toolpath for the cut in your post, try changing the settings in the Clear Pocket settings. The default is Offset, Climb. I was able to clear this with Offset, Conventional. On another project, I had to set Raster, Conventional. On yet another project, I had to fool with the actual shape before I could get the cut to be just a single pass.

Pocket Toolpath Settings

Now that this has been seen by more than one customer, perhaps Next Wave will give this a look. I'd email your project (zip it up and attach it) and send it to Tim. I'd also bang on Rockler to get them to actively follow this support case.

[hdtheater]

Hey Joe,

I posted on the other thread, but since this seems to be a different issue, I did not want to de-rail that discussion and figured we could continue over here.

I ended up getting it to work as expected using Raster/ Conventional. Oddly enough Offset/ Conventional did not work. Thanks for the suggestion for that.

Based on these results, does this line up with the issues you had as well? Should this be escalated up to Rockler/ Next Wave to get a fix or is switching to Raster/ Conventional the correct setting and I was doing it wrong?

Thanks,

Eric

[jeb2cav]

Hi Eric,

Well, I'd raise it up. The common thread in both of our experiences is that we have a single pocket - in essence - it may not be square, but it is a continuous pocket - VCarve came up with an optimal tool path that results in the tool cutting out a section of that, and then lifting up and starting at a second point - on the same pocket with the same depth - and completing the pocket. Yet on the shark, these two pockets don't have the same depth (even though no tool change, no reset of z0, and it is a single toolpath operation).

The difference I measured is ~0.048" - a little bit more than 3/64". This results in the ridge that you'd have to sand. I thought the advertised accuracy expectation is 0.01". So, this ridge is outside the expected tolerance.

What I think is happening is that when the tool moves to the second start point, it thinks it has reached the same depth as it had at the first start point. However, it hasn't - it is off by the amount I measured - as a result of getting beyond the capability of the machine.

When I first described this to support, there was a lot of focus on tool changes, square/flat table, etc. However, there is no tool change, or even opportunity to reset the z0. This is one tool path with the same tool cutting the same pocket. The difference again is that the tool path has more than one start point.

By changing the settings in VCarve, we are getting a toolpath that only has one start point - the tool never picks up and moves, and then returns to cutting the same pocket. So, even though it might be off in depth by a few hundredths, the eyeball and customer don't notice it. And you really can't measure this accurately with your standard square - at least not with my eyes.

So, the lesson here is never use a toolpath for a pocket that results in more than one tool start point - you need one continuous cut. I would like to hear from Rockler/Next Wave if this meets their expectation though. To be fair, I did tell Tim to let it go as I'd found a work around. However, if this condition is outside the design expectations, then maybe they'll fix it and field the repair (might be software on the controller side, but I doubt it).

You can see if it is one start to finish toolpath, or more than one, by watching the preview. I agree it may not be recognizable initially for what it is, but once you see the outcome, and then look at the preview, you can see the second start point. In the picture I posted, it decided to cut the outer section first - like an outer ring. So, the first start point was long the outer edge of the cut. At some point, it had done enough of the outer ring, and moved to the very center of the cut, and started working center outward until the two edges met.

Lastly for those reading through this - this can happen with 3D cuts as well - not just the pocket toolpath. The same solution has worked so far for me - changing the toolpath strategy - conventional/raster, climb/offset.

[hdtheater]

I sent off a note to Rockler and Next Wave to get the ball rolling. When you did yours was the pocket a big pocket or relatively small?

The piece I am working is roughly 24 x 24 and had a lot of pocketing to do. I have cut this same shape in other material though not as large and this was not an issue.

As I type this I am wondering the size of the pocket is what is could be causing it, i.e. more of a need for different start points.

I'll post my results as I hear more.

Eric

[jeb2cav]

Hi Eric,

In my opinion the size of the work piece is not related to this poor outcome. This appears to only occur if a given cut has two or more start points in the tool path planning.

The piece I discovered this on had a working cutting diameter that did not exceed 7". In your case, your workpiece is covering most of the possible cutting area. But both cases have the same condition - 2 or more start points during the generation of the cut/feature it is working on.

In my case, when I worked with VCarve to get a single start point, I did not see this ridge in the final product. I suspect you'll get the same finding.

[hdtheater]

Did yours get deeper or shallower on the additional plunges?

[jeb2cav]

Shallower

[hdtheater]

I would need to go back and see the order of how the toolpath actually was carved to see if mine is getting shallower too.

Here is my theory. I'll need to test it to prove it.

I am wondering if we are losing Z depth because the plunge rate is too fast/ motor is too weak. I know when I take the router outside of the allowed travel distance it gives that grinding sound instead of binding up the screws. Maybe the same thing is happening when we plunge the router into the material?

For this job I used 3/4" MDF with a plunge rate of 30. On a previous job using the same drawing, I did it in red oak and slowed the plunge rate to 5. I did not experience this issue with that project. One difference is that the project was about 8" and this time it was 24".

Thinking if it loses 1/100th of an inch for each plunge and if you have four plunges then the total difference is 1/25th of an inch from the expected depth. That is a significant difference and be out of allowable tolerances.

Feel free to poke holes in my theory and make suggestions.

I won't get the chance to work on anything this weekend, but maybe Monday I can run a few tests.

Thanks,

Eric

[jeb2cav]

I agree that plunge rate could affect the outcome on the Shark. I gave up after running 3 tests, using pine (about as soft as you can get) and still getting a noticeable ridge. Right around that time I figured out how to manipulate VCarve to give me a toolpath that didn't have 2 or more start points, and frankly I let it go.

When I have a flat pocket like surface in a project, and I stick my high speed measuring device in it, the depth is within a few hundredths of what is expected. So, minor warpage in material, slant on table, plunge didn't get all the way there, it all is acceptable to me.

But when 2 or more start points are in the toolpath, the only thing in play is the ability for the Shark to accurately repeat the depth it is told to move to. As you point out, the error associated with the plunge is cumulative, so you could quickly get to a noticeable difference.

I think this is entirely different and not related to the situation where you've moved an axis of the Shark beyond the tolerance, and get the nice grinding and other noises. I think this is more about the stepper motor and measurement when even a little resistance is in play and the resulting accuracy - at least in z.