I’ve read all the way down to May '22 and have yet to find an answer to this.
It seems that CC v7 (maybe all versions) prioritizes like-Z operations in a sequence of moves. This results in unnecessary rapids when there are more than two sets of pockets and, especially in the case of arrays, the rapids are chaotic. Here’s the set up:
If I do two pockets, one shallow–one deep on the same center, and then select the next shallow path, duplicate shallow toolpath to it, then select the next deep path and duplicate to it I get the desired single rapid between them.
Two pockets > rapid > two pockets.
If I repeat to a third pair, the first two remain as before, the third shallow is ok, but by adding the next deep pocket there are then three rapids between locations two and three. What I desire is:
Two pockets > rapid > two pockets > rapid > two pockets > rapid > two pockets > rapid > two pockets
until I get to the end of the row however long that happens to be. I’ve tried grouping paths and although the rapids are different between grouped and ungrouped, there are still more than one rapid between the sets.
I’ll deal with additional rows later, once this gets figured out.
This is a problem for most CAD programs. Will Adams calls it the “Traveling Salesman”. This refers to the random order the rapids move to do tool paths. Your breaking up the tool paths is the only solution for the random order of tool paths and rapid movements. Sorry but true.
And how would we go about achieving the intended goal in CC?
IOW, not only reduce rapids but perform two pockets first and then rapid to the next set of two pockets?
IOW(2) Is there a way of setting operation priority by grouping/nesting/whatever?
The only user control for toolpaths is that they are executed in the order specified. So, if I am understanding your problem correctly, each pair of shallow / deep pockets would have to be a separate toolpath.
Yes, that is hideously ugly if you need to change the parameters of the paths.
What Michael said. If your pockets are different depths, then they must be separate operations/toolpaths.
Just put them in the order you want.
If you’re talking about multiple vectors in a single operation, (you mentioned arrays),
In a previous post I was able to get pretty decent results by controlling the order of creation.
so, say for a 12 x 12 array of something, I created the lower left object first, then made an array of 1 row, 12 columns. Then I selected that array & made an array of 12 rows, 1 column. Then I selected every other row (2, 4, 6…) and mirrored them so the first object is now on the right in those rows.
Especially when there are 256 of them. With the toolpath group list not remaining collapsed nor re-sizeable, this makes for a seriously tedious task.
Had read a post similar to this but it left out this operation. Gets me closer. Thanks.
This got me thinking, however. That the first two operations that yielded the desired result:
Two pockets > one rapid > two pockets.
Perhaps copy/pasting these two into a longer row might work? Get to the desired row length and do as you suggest.
The thing that puzzles me is why do these first two instances do what I desire, and the others do not?
This is the thing that puzzles me. You can’t do 2 pockets of different depths in the same toolpath. And you can order toolpaths however you want. ??? Can you share the file?
It isn’t “the same toolpath”.
(2 Pockets = 2 Toolpaths) > 1 Rapid > (2 Pockets = 2 Toolpaths)
This first sequence works. Add one more set: (2 Pockets = 2 Toolpaths) and the rapids go multiple between set 2 and set 3.
So I tried this placing the shapes on different layers: Shallow on one layer and deep bores on another. Deep bores layer worked fine with orderly rapids between each. Shallow on the second layer; the rapids are chaotic. Same method used on both layers. Tried it twice and each instance returned a different type of chaos — the second more chaotic than the first. WTF?
If they are all separate toolpaths, then you can order them any way you want. And there are really no “sets”. It’s Shallow - Rapid - Deep - Rapid - shallow - rapid… etc…
I must really be misunderstanding the problem. You want the paths cut in this order, right?
So you put them in this order
And you get one rapid between each set
Nice. I’m speculating that these toolpath shallow/deep sets were each done manually? With 256 sets and a non-collapseable/resizeable toolpath list, this becomes a bit (no pun intended) more tedious. That’s why I was trying to use arrays. If there is a way to accomplish both, I’m all eyes!