Fusion 360 Hobbyist Rapids

I’m a very content Fusion 360 hobbyist user most of the time, and appreciate the access to the advanced features Fusion gives us on hobbyist license. Occasionally though, I get annoyed that we lack rapids. Especially during a slow toolpath, when the cutter is safely above the workpiece and its just crawling to a new position to start cutting again. Since G-Code is just a text file after all, I wrote a small tool to recover the rapid movements that Fusion omits from us. I thought I would share it with the group in case it’s useful for anyone else. https://rapidsrecovery.com

How it works: While you’re setting up your CAM, make note of your Retract Height for your toolpath. When you process your G-Code through the tool, it will look for times the cutter hits this height and then add back a rapid movement to the next line. If you probe from the top of your workpiece, the height you’re looking for is the same as the Fusion value, but if you probe from the bottom, then it’ll be the Fusion height + the workpiece thickness.

I only have a Onefinity Woodworker with the original black controller so that’s the only machine I can test with. Like I said before, I’m a hobbyist, so I’m far from a G-code expert. If you have some G-Code files that you find aren’t working, post them if you can and I’d be happy to take a look. All processing happens locally in your browser, no information is collected through the website.

6 Likes

Hi Jordan – welcome to the forums. I have pondered the same thing! Even came up with a similar solution. In the end though, the time savings for me was marginal - like seconds rather than minutes or hourss, so I abandoned the concept. I suppose if you are doing a long cut with a lot of repositioning or a lot of 3D motion it might pay off, but I’m not sure it really matters to much for the one-off cuts.

For other reasons I had to purchase a commercial license so it’s no longer a problem for me.

Anyway, great minds!

-Tom

2 Likes

I agree. It’s not a life changing amount of time gained. Typically, I won’t even bother using it on tool paths that don’t have many retractions on them. But on other tool paths, I’ll upload both the original g-code and the new rapids g-code to the controller, and it’s nice to see that rapids will save ~5 minutes or so. Not a game changer, but kind of nice. I wish I had a reason to purchase a commercial Fusion license because I like Fusion so much, but I just can’t justify it when I’m some one who only CNCs once a month if I’m lucky.

2 Likes

I haven’t tried that add-on. Personally, I like to have a separate file per tool path because I don’t have a tool changer or anything. I appreciate the moment between tool paths to pause and inspect that everything cut how I expected it to. That way I can even make changes if I need to. If I were doing large batches of things, then maybe I would try it, but I mostly make one offs, so I don’t have much need for that add-on.

1 Like

Hi Jordan, I like your tool to restore fast movements. I wonder if it is possible to use it offline, where I have my machine I don’t have internet access.

Thanks, Regards.

I’ve been playing around with a platform that would make it easy to convert this to a standalone app. What operating system are you using without internet access, Windows or MacOS?

1 Like

On that PC I use Windows and Linux

Awesome.

Since fast transits still occur between operations, another work-around is to create multiple operations for similar tasks. For example, say you have 8 holes to bore but 4 of them are on one end of a long part and 4 are on the other. Instead of creating one boring operation for 8 holes, create one for only the 4 holes at one end and then duplicate it for only the 4 holes at the other. The tool will will move at the fast transit speed to the second set of holes.

1 Like

@jordan-steele I wrote to you almost 3 weeks ago but I don’t think you can see my message because the system doesn’t allow me to send private messages.

Thanks for the nudge! I found the message. I’m working on a new version and I’ll update here when I get it published. Should be this week.

2 Likes

I just published an update with a handful of new features and improvements. Here’s a list of everything that’s changed:

  • Added desktop app - Available on the downloads page for macOS, Windows, and Linux. If you want to run it on a computer without internet or just prefer apps instead of websites…
  • Added Lathe Mode - Changes logic so that rapid movement is the Z-axis movement instead of the XY movement after Z-axis safe retract height.
  • Added ability to specify multiple safe retracts heights and convert them all to rapids at once.
  • Added ability to reject changes in the file preview pane for either misidentified rapids or ones you wish to skip.
  • Added .ngc as acceptable g-code file types.

I’m always open to suggestions if anyone has more ideas or improvements they’d like to add to make this more useful.

2 Likes

Hi Jordan, I just tried your new version and all the changes you’ve made are great.
I noticed that in lathe mode, it doesn’t accept decimals, for example, Z-14.915, so it doesn’t detect that retraction.

Thanks for the work!

1 Like

I’m not seeing where it won’t accept decimals. I did find an issue where it was skipping the first instance of the retract height that it found, so maybe that was the underlying condition. I just published a new release, so let me know if that solves the issue.

One thing to double check is that if your Z is -14.915, make sure you’re putting in the negative operator because if you just put in 14.915, it won’t treat those two numbers as the same number.

1 Like

I’ve been testing it and it works perfectly.
On the lathe side, the retractions it makes through the workpiece are a bit tedious to see in Fusion 360.

I stumbled across this post and tried Rapids Recovery. I don’t mean to be rude, but using this tool could potentially result in a broken bit (or more). I registered on this forum just to write to you.

Let’s analyze the problem.

For example the output of your tool:

Original file out of Fusion

N60 G1 Z5 F1920 ← Fake Rapid upwards to the safe clearance height Z5
N65 Z2.9 F1350.3 ← Controlled plunge into the material to Z2.9
N70 X16.969 Y15.786 Z2.75

File from Rapid Recovery:

N60 G1 Z5 F1920 ← ERROR 1: Was NOT optimized, still moves up slowly!
N65 G0 Z2.9 F1350.3 ← FATAL ERROR: Rapids Recovery turns the plunge into a rapid move!
N70 G1 X16.969 Y15.786 Z2.75

Rapids Recovery completely twisted the logic. It left the safe upward movement untouched. Instead, it converted the downward plunge movement (Z2.9) into a G0 (rapid) command! The G0 command completely ignores the trailing F1350.3feedrate.

In other words: This is a G1, but one that has no effect.

This means the machine would hammer straight down into the material at maximum rapid speed. If your stock material is clamped even a millimeter higher than calculated in your CAM software, the end mill will crash into the workpiece at full throttle.

I have also programmed such a tool (it’s called “Speedy”). I won’t mention the link here so as not to advertise it or give the impression that Rapids Recovery is bad. Not at all.

This is what my tool does:

N60 G0 Z5 ← Speedy turns the upward movement into safe air into a rapid move.
N65 G1 Z2.9 F1350.3 ← Speedy saves the downward plunge by injecting a hard G1 command.
N70 X16.969 Y15.786 Z2.75

The logic:

  1. Is the line as fast as the maximum feedrate (F1920)? → Yes.

  2. Is the end mill currently above the safe height (e.g., Z2.0)? → Yes (Z5).

  3. Only then does it become a rapid move (G0).

  4. And as soon as the feedrate drops again for cutting (F1350.3), the saving G1 is immediately injected.

The problem, in my opinion, is that Rapid Recovery searches for a rigid text pattern for Z . You should make the algorithm more flexible.

I know what I’m talking about because I ran into the same problem with Speedy and changed it to be more flexible. :slightly_smiling_face:

I hope you don’t take this post the wrong way and see it as helpful. That’s how it’s meant.

2 Likes

I really appreciate your post and all the detail you put into it. I absolutely agree with you that that’s a risk I overlooked in my original implementation, so I appreciate you pointing it out. I definitely don’t want anyone breaking bits or doing damage to their machine.

I just published an updated version (1.1.3) of the site/app that includes a safety check to make sure the bit will end above the safe retract height before implementing the rapid move. If it doesn’t stay above the safe height the whole time, we now just leave that move alone. I did decide to do one thing differently than you however which is to not make the retraction to the safe height a rapid move. I feel like in some cases, in deep pockets or if the lead out isn’t set correctly, I’d be risking nicking the edges of the workpiece on a rapid move upwards.

Thanks again for pointing for this out! One of my favorite things about the CNC community is everyone being so helpful and sharing tips. I wish you all the best on your own tool - Speedy!

2 Likes