2D pockets are incredibly inefficient

[brent]

I have a 2D pocket that I'm tying to cut on a CNC. The 2d Pocket feature is incredibly inefficient. 

Firstly it routinely ignores my entry positions meaning it starts in the middle then it cuts all the way left then has to return all the way to the middle before cutting the right.

Secondly it ignores keep tool down and keeps lifting the tool up to make horizontal movements through stock that has been removed already. I estimate its adding 10-15% onto the machining time.

I have keep tool down checked, the distance is longer than the entire pocket

I have selected entry positions, it flatly ignores them 

fusion lifts.png shows the entry position as well as the repeated lifts

Fusion 2 shows where my entry position has been selected 

Fusion 3 shows whole part

Any ideas on how to resolve this???

[seth.madore]

Would you be able to share your Fusion file here?
File > Export > Save to local folder, return to thread and attach the .f3d/.f3z file in your reply.

[brent]

here is the fusion file

[seth.madore]

I don't think there's going to be any way around this, sorry. You could try 3D Pocket Clearing, and while it does a better job of linking and Stay-down, the cycle time is actually slower..

[brent]

tx so much for the fast replies. I do have a couple of questions:

Why is the pocket ignoring the lead in location. I tried an adaptive clearing and the same issue, I cannot see why it should insist on starting in the middle other than that was the original shape that was then extended to the elft and the right in the sketch. 

why is the pocket ignoring the keep tool down, again I cannot see it why it should not keep the tool down? 

It just does not seem optimized and efficient, and I cannot see any reason why it should not be able to do it

[seth.madore]

I don't have any good answers for you, as I'm not sure what the kernel is doing or how it decides which way to go. I can raise this with the appropriate development team on Monday and see what their thoughts are

[brent]

tx. there is definitely something buggy in the background. I've tried several variations and it stubbornly refuses to accept any lead in entry points. And it's even worse if I try adaptive clearing. At points it ignores optimal load and does full width cuts through long sections of the stock. I don't know if something I've done in the background in drawing the part has created the problems or what, but it certainly results in severely inefficient toolpaths

[matty.fuller]

You can make this more efficient by changing your programming approach... see attached file where I duplicated your setup.

Avoid using the weird profile until you need to... machine down to the step using the open slot profile:

mattyfuller_1-1695605437968.png

Then do the weird profile using the step as your Top height:

mattyfuller_2-1695605507089.png

[brent]

Hi, thanks. that is what I have done in the interim as it has created more efficient code. However there are still some remaining issues: it ignores my preselected lead in points. And it has repeated lifts and lowers when they are not needed making the gcode somewhat inefficient, obviously this does not make a massive difference in this particular situation, but still seems strange that it should be doing it. 

[brent]

Hi, thanks for that. I did set it up like that after I posted and it's made some difference. However it has still got remaining issues of ignoring lead in points and repeated lifts even in the second of the operations to clean the shaped bottom of the pocket

[seth.madore]

Lead-in points will be reached if the toolpath calculation decides it can do that. This is why it's called "Preferred Lead-In" and not "absolute" lead-in.

We've opened a ticket to investigate the lifts; CAM-48500

[DarthBane55]

Reduce your stepover, that way the middle passes will be linked between them as part of the actual toolpath.  But, Fusion does what it wants for a lot of stuff, get used to that, it thinks it knows better than you.

[brent]

I hear you regarding the engine inside doing what it wants. I guess much software works like that.

The lead in points on one of the pockets are being ignored and it is a simple pocket operation and there is no reason I can determine why it would not work properly 

[brent]

thanks for opening the ticket, I'd be interested to see how it resolves.

As for preferred entry points, sure. But I did a setup as suggested by one of the other users that is a rectangular pocket nearly 3 times wider than the tool and it does the entry point in the exact correct position, but on the far side of the pocket. wtf?  I want the entry near the origin to minimize tool movement, however if I move the origin then the entry point remains on the far end, but now right where I would want it to be. And this is on a symmetrical rectangular pocket.  

[programming2C78B]

As optimal as you WANT to be, sometimes you just have to accept fusion is going to do something in a "wrong" way. Say you're chamfering 3 walls that are colinear. It will often do wall 2, 3, then go all the way back to 1. Im sure if you did the math, the total distance travelled is the same as doing it 1-2-3 but looks "dumb" to humans who want it to just go left to right.

If you're running SO many parts, it's worth it to seperate the walls into its own toolpath and arrange how you want (or do tangential extension of wall 1 and accept some "air" cutting), or just accept it! Too often do people spend 15+ minutes trying to force fusion to do something that turns into a 8 second reduction in cycle time. 

Obviously I don't mean this when it wants to just plunge through material. I mean the minutia of people wanting 100% efficiency on a part they only will run one time.

[seth.madore]

@programming2C78B very well said, thank you 🙂

[DarthBane55]

I agree also, except for production parts, your 15 minutes will repay itself countless times for the 8 seconds savings.  In some scenarios, 1 or 2 seconds of cycle makes a big difference.  Say your part takes 5 minutes to make, but you do this part continually, add the 1-2 second for each part, and you'll be surprised that at the end of the month, you save a full day of production (I didn't do the math in this example lol, but I did for some other parts we did in the past and was shocked at how 1-2 seconds can save 1 day in even less than 1 month in some cases, it is not to be neglected!).  But this is where the Fusion roots come into play, when it was geared more to hobbyist.  Many aspects of Fusion, in the toolpath itself (useless retracts in 2d path when not on same Z level, chamfering order as mentioned in your reply, etc etc) are done for safety, not for efficiency.  This is what this software is about (simplicity), so by using it, we must accept this, or frustration grows exponentially with each day passing!    However, when the option to choose a start point is provided, Fusion should certainly ignore what it thinks is best and start where we say it should, that is why the option is there.  I can accept this inside path things it does for safety and stuff, but when I choose an option that is given to us, it must respect it! (in my opinion).

[programming2C78B]

I agree, a chosen lead in position should always be respected if you're going to give us the option. In our shop, an order of 10 is medium and 50 is LARGE. 3-5 is more normal to what we really do, every day. I often run 3-5 jobs a day in 8hrs, and some I see in 2 months and some come every 3 years. You just have to keep this all in mind when you're worried about an "unncessary" rapid move of 0.5" in your part.

I worry about a good part in decent time first, then if it becomes repeat you can try to really optimize EVERY aspect of it. Otherwise if it measures good, is below quote time, and the tools aren't glowing its a success in my books. 

[DarthBane55]

Agreed!  All I'm saying is that we must keep an opened mind when saying that 8 seconds is not worth the effort.  It really depends on what you do.  For some people it does not matter whatsoever, but for some it is extremely important.  I just tried not to generalize to "for me it works perfectly", we don't know what this other guy's need really are.

[edautodesk69XS4]

Can I hijack this thread: I've hit variations of this problem which I would like to raise a bug report on. I have not figure out how to do something like: drill a hole in the pocket, then have the roughing tool enter the hole and start roughing.

I forget all the specifics now, but something like: 3D adaptive will feed rate plunge into the hole, but I think it refuses to do it where you ask. 2D pocket I think insists on rapiding into the stock if you give it an entry point (I have a speedio, rapid is 50,000 mm/min, crashing into the stock left undrilled), plus it refuses to enter the stock exactly where you ask it and offsets it by some lead in radius or something similar. I've tried doing things like moving the drill by eye to where the entry point is, but the drill is only about the same size as the next tool and I really don't want a 50k rapid into the material, even if it's only taking off a sliver of material.

Just to head off any " but it only saves x seconds", the Speedio is a machine which warps time and space to move around the table, it exists to shave x seconds off manufacturing times. Most of my parts fit in the palm of your hand and will get roughed in 6-12 seconds.

I would like to second the OPs request for the ability to:

- set explicit plunge entry points for 2d pocket and 3d adaptive

- be able to control plunge speeds, ie not have them be rapid moves (this only affects one of them, I forget which?)

- be able to specify to start 3D adaptive machining from the inside pocket pocket first, finishing on the outside of the part. This is quite annoying to setup otherwise, involving needing to add extra sketches and negative exclusions for the machining area and multiple operations. My specific problem was that the default is to machine the outside first, this left my part held in a flimsy top hat in the vice and was then ripped out when it came time to machine the centre pocket. (busted tools, much excitement, etc)

Thanks if you can ask the developers to look into this. Will be a significant quality of life improvement!