Community
Fusion Manufacture
Talk shop with the Fusion (formerly Fusion 360) Manufacture Community. Share tool strategies, tips, get advice and solve problems together with the best minds in the industry.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CNC router has painfully slow travel from home to initial cut?

13 REPLIES 13
SOLVED
Reply
Message 1 of 14
tlumWWPF3
313 Views, 13 Replies

CNC router has painfully slow travel from home to initial cut?

I am a complete beginner when it comes to Fusion 360 and running a CNC router with it. I have a Denford Router 2600 Pro and I am making essentially two circular interior 2D contours in a square piece of foam. The actual cutting is going well but my issue is how slow the router moves from home to the start of the first cut. I did some exploring and trial and error and found the G1 command that is slowing it down and I can change it manually to speed up the travel but I was wondering what setting (if any?) can I change in my set-up to speed that movement up?

 

I will attach a text file of the whole program but this is the start of the program and the line in question is the 16th line:

(1001)
(T03 D=6.35 CR=0 - ZMIN=-3 - FLAT END MILL)
N1 G21
N2 G90 G94
N3 G17
[Billet X222.25 Y222.25 Z12.75
N4 [EDGEMOVE X-111.125 Y-111.125
N5 G28 G91 Z0
N6 G90
(2D CONTOUR2)
N7 [TOOLDEF  T0303 D6.35
N8 M5
N9 G90 M6 T0303
N10 M3 S18000
N11 G17 G94
N12 G1 X71.47 Y-3.635 F450

This last line is where it travels from home to line itself up to the first cut. I can change that F to speed it up and if fact deleted just the F450 part and the travel was fine. Is there a part of Fusion I can edit so it knows to let the machine travel at it's normal pace? Any help is appreciated.

 

I am using the Educational license if that matters. I am using the Denford post processor found in the Autodesk library.

Thanks in advance,

Tom

 

 

13 REPLIES 13
Message 2 of 14

at the top of your code it'll explain that education licenses post out G1 instead of G0's. 

you can google around for the github that can replace all certain g1s with g0's so it will rapid.

Also just increase your transition feedrate to that of your machines rapids. 

Please click "Accept Solution" if what I wrote solved your issue!
Message 3 of 14
Cave_Master
in reply to: tlumWWPF3

G1 = move at programmed F rate

G0 = move at machines max speed (rapid rate)

 

You need to add G0 lines where you want your machine to move at high speed.  Be careful to make sure that you are back to G1 where you want the machine running at programmed rates.

Message 4 of 14

When you say "at the top of your code it'll explain that education licenses post out G1 instead of G0's" , what are you referring to because what I posted was the top of my code.

Message 5 of 14
tlumWWPF3
in reply to: tlumWWPF3

I was able to find the setting that was creating the F450 command. There is an option when I Post Process where I can change my high feed rate.

tlumWWPF3_0-1702489086006.png

I am going to change it to 1000 and go from there.

Thanks for the help,

Tom

Message 6 of 14
DarthBane55
in reply to: tlumWWPF3

F450 -> I believe needs to be F450. (the "." is important, at least on our machines it is.  Otherwise the machine interprets that as 0.0450, big difference.

This may not be true of all machines tho, just relating to what I work with.

Message 7 of 14


@DarthBane55 wrote:

F450 -> I believe needs to be F450. (the "." is important, at least on our machines it is.  Otherwise the machine interprets that as 0.0450, big difference.

This may not be true of all machines tho, just relating to what I work with.


his tool D is 6.35(mm),and so his feeds will also be in mm. I don't believe these controllers requrire the decimal

 

 

On your machine, you can also change the setting to how it interprets "no decimal" numbers. It defaults to tenths because thats the safest one when someone changes a feedrate at the machine! 

Please click "Accept Solution" if what I wrote solved your issue!
Message 8 of 14

Thanks, don't want to change it tho.

Message 9 of 14


@programming2C78B wrote:

at the top of your code it'll explain that education licenses post out G1 instead of G0's. 

you can google around for the github that can replace all certain g1s with g0's so it will rapid.

Also just increase your transition feedrate to that of your machines rapids. 


This is not correct, it's only the Personal license that's restricted on feedrate. Educational and Startup have the same rapid behavior as commercial accounts.


Seth Madore
Customer Advocacy Manager - Manufacturing
Message 10 of 14
ktorokU233T
in reply to: tlumWWPF3

@tlumWWPF3 

 

Not sure what other options are available in this post property dropdown:

denford.JPG

Right now it is set to only use a rapid G00 for a single axis move. If it can be set for all or 2 axis moves, try that. It looked like your first move was in both X and Y, so would not fall under a single axis move and be posted out as a G01 high feedrate move.

 

Of course you will more then likely get "dogleg" rapid moves if this works, which for some reason, seems to scare the heck out of people now, and has caused post developers to jump through hoops to avoid them at all costs, even though this has been the behavior of most all CNC machines as far back as, well, the beginning of CNC machines.

Message 11 of 14
DarthBane55
in reply to: ktorokU233T


@ktorokU233T wrote:

@tlumWWPF3 

 

Of course you will more then likely get "dogleg" rapid moves if this works, which for some reason, seems to scare the heck out of people now, and has caused post developers to jump through hoops to avoid them at all costs, even though this has been the behavior of most all CNC machines as far back as, well, the beginning of CNC machines.


Dogleg has nothing to do with post developers, it's a parameter in the machine, you set it to do dogleg or not.  The  post has no control over dogleg motion.  The problem is the CAM do not do dogleg, but when the machine is set to do that, it can hit fixtures, bolts, and whatever is in the way, that appear to be avoided in the CAM system.  So for that, it is best to turn dogleg off in the machine parameter, to match the CAM behavior, and avoid bad surprises.  You can't change the rapid motion in CAM, so best match the machine to it!  On some machine it may not be possible to avoid dogleg, so need to be very aware of the actual motion vs CAM motion if that is the case.

 

EDIT: to clarify dogleg motion:  dogleg happens when the axis are at 100% rapid on G0.  So if you have 10" to go on X, but only 1" to go on Y, since they both go 100%, it reaches the Y destination way faster than the X, so you get the dogleg motion.  When not using dogleg, 1 axis is not going 100%, to arrive at destination at the same time in both axis (straight line move), this is what CAM shows on screen always.

Message 12 of 14
ktorokU233T
in reply to: DarthBane55


@DarthBane55 wrote:

@ktorokU233T wrote:

@tlumWWPF3 

 

Of course you will more then likely get "dogleg" rapid moves if this works, which for some reason, seems to scare the heck out of people now, and has caused post developers to jump through hoops to avoid them at all costs, even though this has been the behavior of most all CNC machines as far back as, well, the beginning of CNC machines.


Dogleg has nothing to do with post developers, it's a parameter in the machine, you set it to do dogleg or not.  The  post has no control over dogleg motion.  The problem is the CAM do not do dogleg, but when the machine is set to do that, it can hit fixtures, bolts, and whatever is in the way, that appear to be avoided in the CAM system.  So for that, it is best to turn dogleg off in the machine parameter, to match the CAM behavior, and avoid bad surprises.  You can't change the rapid motion in CAM, so best match the machine to it!  On some machine it may not be possible to avoid dogleg, so need to be very aware of the actual motion vs CAM motion if that is the case.

 

EDIT: to clarify dogleg motion:  dogleg happens when the axis are at 100% rapid on G0.  So if you have 10" to go on X, but only 1" to go on Y, since they both go 100%, it reaches the Y destination way faster than the X, so you get the dogleg motion.  When not using dogleg, 1 axis is not going 100%, to arrive at destination at the same time in both axis (straight line move), this is what CAM shows on screen always.


I know what dogleg moves are, they have been around since before there was a parameter to make all the axis' arrive at the final rapid point simultaneously, usable CAM systems, and affordable PCs. (FANUC Parameter #1401.1 =1 No dogleg rapid (LRP) if it's a FANUC 16, 18, 21, 30, 31, 32) Seems to me, with all the power of a CAM system, this could have been simulated. Dogleg moves have been around since the beginning of CNCs. If you ever worked with an older control (apparently before Fanuc 16 era), you learned to deal with them. Even our last 2 DMGs came in without the parameter set to eliminate the dogleg rapids, and the last one was delivered in June of this year. I can see how in 4 and especially 5 axis work, if the CAM system will not properly simulate a dogleg rapid move how this could cause lots of headaches, hence the use of high feedrate rapid moves. Back to on topic....

 

@tlumWWPF3 

DenfordRapid.JPG

Try setting the high feedrate mapping to this. Make sure you are clear of your part/fixture/clamps when rapiding around.

 

Message 13 of 14
DarthBane55
in reply to: ktorokU233T

Was just trying to clarify because you said post developers have been working to eliminate them, which is not true (post have nothing to do with dogleg), but I see now you know very well what they are, sorry for my reply.  My 1st CNC machine had a tape reader, but thanks for the history lesson anyway.

Message 14 of 14
ktorokU233T
in reply to: DarthBane55

@DarthBane55 

All good. I apologize if it sounds like I was cranky, but I was. Did not mean to sound like I was jumping on you, was just trying to clarify the explanation before it gets misconstrued and used inappropriately, while I was cranky about other things.

I did not mean to infer that post developers where responsible for causing dogleg moves. I was trying to say they are trying to avoid them by using a high feedrate mapping because they are not simulated correctly in most current CAM software. Probably not actually the post developers' fault for not simulating dogleg moves correctly, and more the CAM kernel developers. I believe I read somewhere that MasterCAM has in the last few years somewhere added support for simulating dogleg moves but cannot confirm or deny this (nor really care) as I have not used or seen close and upfront MasterCam since the X debacle.

 

Ah, paper tape. From the era when smartphones meant the dial was lit so you could call in the dark without turning on the lights.

 

Have a Great Day.

 

Ken

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums