2d contour - transition moves at cutting feed rate

[chris]

Hi

Has this been resolved yet, or forgotten?

I have the following problem I love to get answered.

The lead in, cut & lead out are ok, but then the transition to the next lead in point is running at the cutting feed-rate!

The whole job will take at least twice as long as it should to mill.  Am I doing something wrong?  To get the job done I'm having to revert to my old, clunky proprietary software to perform this simple procedure.

Am I missing something?

I found this post referring to the same issue

Solved: 2D Contour - Transition moves perform with Cutting Feedrate

Marked as solved, although it wasn't solved, it was just answered with a reply saying it wasn't possible.

In the thread I found this reply ..

‎12-04-2017 07:49 AM

@cj.abraham wrote:

Added CAM-9094 to allow use of non-engagement feedrate when using keep tool down.

Is cam-9094 a possible fix in the pipeline? This was over 2 years ago...  I'm wondering if it's been ignored due to the post marked as solved?  hence part of the reason for this new post.

Otherwise, can anyone offer a solution / workaround?

I'm trying desperately to move over to Fusion 360 from my outdated proprietary software, but for the moment the old software is doing the job and fusion is lacking in a number of areas for me.

Copy of the f3d file attached below.

Thanks

[daniel_lyall]

Right-click on the toolpath and select view toolpath this shows the feeds for all the moves if you can work out what setting it is in the post it could be changed there. 

[chris]

Ooooo... I didn't know you could right click the toolpath for extra information. Thanks for that little insite..  I'm not sure how I could adjust the post to address my issue, I have had a little dig around but couldn't see anything that would identify only the transition moves?   That leaves me with just editing the gcode in a text editor after the post.  Not very productive - come on Autodesk sort it out..

[Anonymous]

hello, uncheck keep tool down in link tab

maybe rapid moves make your work faster in this case

[chris]

Hi

Thanks, I tried that but the tool then retracts fully to the left every pass which is again really in efficient.

Milling this way actually takes longer according to the simulation - 29 minutes, opposed to 18 minutes with keep tool down selected.  Part of the problem is the red line, which Fusion considers a plunge cut, (when its not in this case) it's technically plunging outside of the stock.  The lead in is the plunge cut in this case.  I can increase the plunge feed rate to 5000 mm/min which helps, this gets me down to 17 minutes, but with the same applied to my original approach gets me down to 15 minutes.

This procedure should perform in around 9 minutes with the correct rapids in place.  6 Minutes per piece is time I cannot afford to loose.  Obvs. I can adjust the G-Code Manually, but....  A proper solution would be preferable.

[chris]

FYI a clip of the [manually adjusted G-code in action] for those who're interested.

[seth.madore]

I'm going to raise this with the developers, see if we can get some eyes on this use case. There have been many times I've wanted a "fast feed" on transition moves. I think the best solution would be for a new dialog box on the "linking" tab that allows us to define feedrate of transition moves. Adaptive has that option already.

[chris]

That would be awesome, Thanks.

[Dubbie]

sigh... 3 years later still looking for this feature.

[Anonymous]

Yes please include this simple option

[kyleNMBTR]

I'll throw in my vote. The lack of a true rapid is tripling the time required for some jobs if I want to use 2D contour for an open-ended toolpath contour.

[jeff_forum]

I was able to deal with this in the post processor for my Bridgeport.  The movements are "MOVEMENT_LINK_TRANSITION" values so I check for those and added user defined option to multiply the speed of the moves.  I only do it on linear moves but it can be added to the others if there is any reason to.

In the post file (*.cps) there is a function called onLinear that outputs the machine language for making a linear move.  You can test the movement variable to see if it equals MOVEMENT_LINK_TRANSITION and add in an if/else section that increases the rate if it does, else leave the feed alone (the black code is the original post code to make a move, the blue is what I added):

if (movement == MOVEMENT_LINK_TRANSITION) {
writeBlock("LINE ABS", xOutput.format(x), yOutput.format(y), zOutput.format(z), feedOutput.format(Math.floor(feed * properties.transitionMult)));
} else {
writeBlock("LINE ABS", xOutput.format(x), yOutput.format(y), zOutput.format(z), feedOutput.format(feed));
}

The value of properties.transitionMult is the user variable I created in the post options window by adding

"transitionMult: 1, // Multiplies the current feedrate for Transition moves"

to the properties = { } list in the post, and

"transitionMult: {title:"Transition feedrate multiplier", description:"During a Transition move the feedrate will be multiplied by the transitionMult value.", type:"number"}"

to the propertyDefinitions = { } list in the post.

Obviously this is do at your own risk and would be way easier if the tool made the movement distinction before sending it to the post, but I didn't want to wait.  And not all posts are the same so you'll have to feel your way around it.  If you're nervous about hacking it into the post you can just have the post put out comments that show up in the machine code to show you where the changes would go into it so you can double check the output.

[programming2C78B]

I've asked you about this before. Please add it as well for any horizontal/pocket toolpaths as well. No need to move @Anonymous rate when not engaged! 

[engineeringQCQFN]

It is possible to disable feed height to fix that issue, but almost every toolpath will have a warning singal, super annoying

[PG.Eng2]

this function is still not available in 2dContour?
Would youi know if there is a way to upvote planned work on this feature somewhere?

[seth.madore]

@PG.Eng2 no, it's still not available in 2D Contour, unfortunately. Also, there is no longer a mechanism to "upvote" ideas on future work. We do have tickets open on improving this behavior, but I think they've fallen lower in the priority list. I've poked one of the developers to see if we can get some improvement on this issue

[PG.Eng2]

That would be much appreciated. Thank you for your reply.

[reynolds087RH7ST]

Adding another vote for this. I think anyone who actually used this toolpath could run it once and realize that this is a critical feature which was overlooked. These types of inefficiencies are just extremely frustrating. It's a completely unnecessary limitation.

[reinigrauer]

The same limitation is on the Deburr toolpath (as well as others I'm sure)
https://forums.autodesk.com/t5/fusion-360-manufacture/deburr-toolpath-smooth-retraction-at-transitio...

You end up with what is essentially a linking move that moves at the cutting feedrate.  Every toolpath should have the same "Non Contact Feedrate" option you have on the adaptive toolpaths.  It's silly that any non-cutting move happens at cutting feedrate.