Weird Pocket Bug

[ericschimel]

Hello everyone! I'm a reasonably experienced VCarve/Aspire user and I'm really stumped on this problem... I've got a file that I've imported into Aspire and it's got a bunch of pockets. Normally I'd just select all of the pockets and make a toolpath... For some reason however certain combinations of these pockets result in either no pockets, some pockets, or buggy pockets. I've done everything I know to clean up the vectors, export in different ways, etc. No matter what I do I cannot seem to get this to work correctly. To better explain here's a video:

https://goo.gl/photos/JWC19A8U9WMchaMr5

And here's the file:

https://www.dropbox.com/s/zkg9ranj8zs56 ... crv3d?dl=0

If anyone has any suggestions I'd greatly appreciate it!

[4DThinker]

I believe you've found a bug. I can get all the pockets to cut, but only by using more than one tool path. I tried deselecting all the vectors, then adding them one at a time before recalculating. After the first few any more that I added would be ignored.

The file does have a slew of layers in it. The compression bit chosen in my opinion isn't the best choice for pockets that don't go all the way through. I'd use a downcut spiral, and for the 1/4" wide slots change the pass depth to 1/8" or so.

4D

[4DThinker]

If you create 3 separate pockets you can use the merge pockets option to turn them into one toolpath file. Not the obvious way, but a "hack" that works.

[ericschimel]

Ok so I'm not missing something silly... Thanks for checking that out. The merged toolpath is a good idea, I didn't think of that one.

[mtylerfl]

Just an observation...if you offset the 0.25"-wide pocket vectors by 0.01" (making them 0.27" wide", then all the vectors can be calculated as one toolpath.

It does seem something is amiss alright.

EDIT: Just before shutting down your file I decided to play with the negative offset value. You had -0.1" offset. I changed that to -0.04" and recalculated. Lo! The 0.27"-wide pockets that I had made (via offset vectors) would NOT calculate. I changed the pocket offset to -0.06" and same thing...the 0.27"-wide pockets won't calculate. Perhaps it's the negative offset that is the culprit?

[IslaWW]

Eric...
Set your bit diameter to .248 and see what happens.

Common sense tells us that a quarter inch bit will cut inside a 1/4" rectangle. Unfortunately, somewhere in that rectangle it is a millionth of an inch narrower, telling the toolpath algorithm that the bit wont fit.

Besides that is much more likely the real diameter of that bit anyway, they seldom cut at the advertised diameter.

[mtylerfl]

Eric...
Set your bit diameter to .248 and see what happens.

Common sense tells us that a quarter inch bit will cut inside a 1/4" rectangle. Unfortunately, somewhere in that rectangle it is a millionth of an inch narrower, telling the toolpath algorithm that the bit wont fit.

Besides that is much more likely the real diameter of that bit anyway, they seldom cut at the advertised diameter.

Good suggestion. But, it didn't work, unfortunately. Try diameter of 0.247". It does work. (Pushin' the envelope of bit diameter reduction though, just to make it work as expected!)

[4DThinker]

If I use the profile tool to cut inside all those vectors it works on all unless part of them are minutely smaller than .25". I even went back and got rid of all the odd dogbone fillets and roundovers which helped the profile toolpath fill them out, but the pocket toolpath still ignores many when all are chosen.

[ericschimel]

Gary, I get what you're saying about pocketing a .25" wide slot, and one of the lines being a tiny bit off... I run into this from time to time and all I do to correct for that is to just give a tiny bit of pocket allowance in the toolpath and I'm good to go.

In this case, that doesn't work...

If you take that file and start in the top left corner and pick the first pocket it works, then you add to the selection the one right below it, it still works. Then add the one right below the second one and it doesn't work.

Now go back and do a pocket on each of those three vectors one at a time, it works.

Then if you give a huge offset to the pocket (say -.1) so that the pocket is cut way bigger than it's supposed to be, try selecting individually the little skinny ones just by themselves... You'll get a pocket, but NO offset. This to me tells me that there's a bug here.

[IslaWW]

Sorry I got confused. I am one of those "if I need a larger or smaller toolpath" I make a new vector. Over a lifetime of watching many of these nice little tricks work or not work on about a dozen different software packages for 2D or cabinet design, it has just been simpler to make what I need. I always assume my needs or use is not typical.

One exception: When cutting bearing pockets into aluminum I use a vector that is .001 smaller than the bearing and toolpath with a .01 last pass allowance. Works for a perfect press fit.

[mtylerfl]

Sorry I got confused.

I am certain you did NOT get confused. (You're just being nice!)

I am one of those "if I need a larger or smaller toolpath" I make a new vector. Over a lifetime of watching many of these nice little tricks work or not work on about a dozen different software packages for 2D or cabinet design, it has just been simpler to make what I need.

I'm with you, Gary. Whatever it takes to get the job done. A case where the end justifies the means.

One exception: When cutting bearing pockets into aluminum I use a vector that is .001 smaller than the bearing and toolpath with a .01 last pass allowance. Works for a perfect press fit.

That is a cool tip! Thanks!

[ericschimel]

So Gary, I'm with you in that the answer here is to just delete and redraw the slot. In the context of doing one sheet that absolutely makes sense. However, I'm bringing in these cabinet side panels from SketchUp (they're actually exported to AutoCAD format, and then brought into Aspire)

The problem is that this problem scales. If I have 15 sheets to cut with 75 of these little pockets, the time it would take to redraw them is a lot, and the chance of missing one is much higher. Also, I want to "idiot proof" this process as much as possible as I may not be the only one operating the machine using this workflow.

If the slots were just a hair under .25 in some cases that can be cured very easily with adding a tiny offset to the toolpath. That solution scales very well from one slot to 100 slots.

The problem I have here is that the solution that is supposed to work (offsets) doesn't, at all. It's like there's something borked with the way those slots are drawn. Despite checking, rechecking, re-importing, redrawing I get the same bug over and over. If this was just an inconvenient work flow thing, I'd figure a way around it, but here I do believe I've found a bug.

[Adrian]

Looks like a bug to me or there is some hidden info about the vectors that is causing it. As you say the toolpath calculates fine if the vectors are selected differently so it can't be an issue directly with vector size etc as the toolpath wouldn't calculate under any circumstances then.

I've attached a simplified version of the file which shows the issue. The first toolpath is both vectors but only the left one actually works but no errors are displayed. The other toolpath is for the right only and calculates fine.

[AdamJ]

Hi All,

We have got to the bottom of this. A fix should be included in the next patch. Thanks for your persistence in narrowing the problem down.

Adam

[ericschimel]

Thanks so much Adam! Really appreciate it. I'll keep an eye out for that patch!