Beta new F360 Post Processor (enhanced Guffy)

Here is a enhanced version of Guffy’s post processor for testing.

Please do not considered it well tested. I have used it for the few small projects I have done but it should not be considered stable. Please review all GCode output to ensure it meets your needs before using the GCode.

Enhancements:

  1. Scaling of feedrate: By enabling the parameter [Feed: Scale Feedrate] the post processor will scale the feedrate specified to be less then the limits set by [Feed: Max cut speed X or Y], [Feed: Max cut speed Z] and [Feed: Max toolpath speed].

    Scaling is done by projecting the cut vector’s feedrate into the three axes. Each projected feedrate is evaluated to see if it exceeds that axis’s limit, if it does then all axis’s projected feedrates are scaled proportionally. Then the next axis is reviewed. After all projections have been scaled the new feedrate of the cut vector is calculated F = SQRT(X^2 + Y^2 +Z^2) and the result limited to be less then [Feed: Max toolpath speed]. Note: you don’t need to understand the math to use it.

  2. Map G1 to G0s when safe. By enabling [Map:G1->G0 Rapids] any G1 that occurs at/above [Map: Safe Z for Rapid] height will be converted to a G0 Rapid. [Map: Allow Rapid Z] indicates if Z moves will be included.

    Rules:

    • If the cut has no Z change and if >= to safeHeight then Safe (convert G1->G0)
    • If only Z is changing and going up and its target is >= safeHeight then Safe (convert G1->G0)
    • If only Z is changing and going down but start >= safeHeight and target >= safeHeight then Safe ( (convert G1->G0)
  3. Map Fix first move of cut. By enabling [Map:G1->G0 Rapids] will detect if the first move of a toolpath is a G1 cut and convert this to a G0 Rapid.

    F360 Personal changes all G0 Rapids to G1 cuts. This changes the first move that should be a positioning move, used to reach the start into a cut, into an incorrect cut move. G1 Cut moves can travel in X, Y, and Z at the same time. G0 Rapid moves travel first in Z and then in X, Y. This allows the tool to move safely away from the work prior to moving sideways. Using a G1 instead can result in the cutting tool being dragged sideways across the material on the way to the first cut. By detecting if the first move of a toolpath is a G1 cut and converting this to a G0 Rapid this problem is avoided.

All other functions of the Post Processor should work as before. Please reply to this thread if you find issues.

A Fork of the Guffy Post Processor with this change integrated with the rest of Guffy can be found in the Enh1 branch located at flyfisher604/mpcnc_posts_processor at enh1 (github.com). If you just want to try the mpccn version you can use the zip file below.

mpcnc_pp.zip (11.6 KB)

4 Likes

I am using the standard version of Guffey in a paid version of Fusion 360 for my Lowrider. Would your enhanced Guffey benefit me? If so, which of the two versions mentioned?

This one will scale federated to ensure mpcnc’s z limits are not violated. You can leave the G1->G0 mapping off if you are using a paid version.

Downloading the zip file would be the easiest way to try it.

A further enhanced F360 Post Processor is now available at flyfisher604/mpcnc_post_processor on GitHub.

Thanks to everyone who provided feedback.

1 Like

As someone that primarily used Fusion 360 for my CAM, I really appreciate the upgraded post processor. I’ve only run a couple of jobs since you did the initial release, so no feedback. But thanks.

1 Like

I’m trying to use your post processor to speed up a process, but it doesn’t seem to be doing anything.

The process is an adaptive cut that is 1" wide and 15" long. The adaptive cut makes an arc along the 1" axis, then moves back to the start of the arc for the next pass. I think the problem is that Fusion doesn’t fully lift up when moving from one side of the adaptive cut to the other, so your post processor doesn’t know that the move back to the front of the arc can be a rapid.

I have Fusion set to lift 2mm prior to going to the front of the arc. What should I put in the field for Map Safe Z so that it will rapid the next move? Right now it has Retract:2, but this doesn’t seem to be doing anything.

Which version are you using? Make sure you are using v2

Flyfisher604 Fusion 360 Post Processor (v2) is Available

By default, the options that enable G1s --> G0s are off by default. Make sure you look at the documentation to enable the G1 to G0 mappings. Also make sure your travel speeds are set.

Version 2 can use the layer height names defined in F360.

I’m using the one you linked to on Jan 30th at the github location:

If these are movements that are below a level that would be considered safe for the entire GCode file then a safe height can’t be set that low. If they are safe then set the safe z to that level.

Send some images of the tool setup and the pp settings you are using. I will review.

I’m pretty sure that’s the problem.

When doing the adaptive cut, the tool only raises a bit off of the lowest cutting surface. It doesn’t raise all the way back up above the height of the material. So I don’t think you’re algorithm knows to speed up the movement between the two ends.

I really dislike that F360 is slowing down the rapids for the ‘free’ version. This job/process would be a whole lot faster if the transits were quicker. Half the job time is moving from one side of the cut to the other for each pass.

I’ll try to get some screen shots for you later today. F360 is on a different laptop out in the shop.

Just wanted to let you know that I tried it out on a different project and it worked much better.

Thanks for making this PP for us to use.

2 Likes

Hi Don.

First of all thanks for your effort.
I have been using your post processor succesfully before, however with Fusions latest update there seems to be something weird going on. When tool change begins there is some special characters printed in gcode. I can’t even paste the gcode here because of those.
weirdstuff1

Line with weird stuff does not do anything in Marlin.

There is another thing, sometimes G0 -lines before first lead-in seems to disappear:
; — Tool Change End
; Trace1 - Milling - Tool: 1 - flat end mill
; COMMAND_START_SPINDLE
; COMMAND_SPINDLE_CLOCKWISE
; >>> Spindle Speed: Manual
M0 Turn ON 19000RPM
; COMMAND_COOLANT_ON
M117 Trace1
; MOVEMENT_LEAD_IN
G1 X-26.295 Y365.28 Z6.054 F300
G1 Z-1.95 F300
; MOVEMENT_CUTTING
G1 X-26.29 Y365.645 Z-2.031 F720

I have feedrate scaling turned on but G1->G0 mapping settings all turned off since I’m using paid version of Fusion. Post processor v2.

Hi, sorry to hear you are having issues. Regarding the tool change, do it do this on every tool change or only some, did this only change when f360 changed?

Have you tried defining Tool Change: X and Tool Change: Y properties. These should default to 0 but maybe somethings broken.

Are there any other strange characters in the file?

Regarding the missing G0 before the lead-in. Are they consistently missing such that if you generate the same GCode the same ones are missing? Is it only after a too change? If you export only that 1 operation is the G0 there?

Ok, I think I know the reason for the tool change weird code - I’m referencing an undefined variable.

Line 1748 should use the variable toolChange3_Z not toolChangeZ. If you want to edit the .cps file and make the change that will like fix that problem. Looks like this problem was there since I reorganized the order of the parameters. Because of the way the PP and F360 work I have the chance the variable names to get things ordered nicely. I missed the one reference to Z. Oops.

I haven’t tested this. Just reviewed the code while sitting on the deck :grin:. I will change the code this weekend and release a fix.

The second issue still has me stumped.

Thanks, first problem seems to be fixed with that line 1748 change!

About the second one, they are consistently missing and only when first cutting movement is trace (haven’t tried them all though). So it actually is beginning to look like Fusion bug to me. Also tried to export single operation, did not help.

Can you upload a GCode file that shows the issue.

Can you also try it with feedrate scaling off. Maybe I’ve got an issue causing that feedrate to go to 0 and I’m skipping the command.

Also, I’m a little confused as you said it happens when the first cutting movement is a trace but the snip-it of gcode you showed has the last line of a tool change at the beginning - what was it doing before the trace that required a tool change?

Can you do a View Toolpath on the Trace operation that doesn’t work. If you can post a screenshot of the start of it that may help. I’m on the free version so before the Lead-in I see 2 rapids in the toolpath but F360 sends them to PP as cutting movements.

Please also post a GCode file with the Job: Comment Level = Debug

v2.0.1 has been released to fix the bad Z height during a tool change. See more here:

Release V2.0.1 of the Flyfisher604 F360 post processor is available.

v2.1 has also been released with added support for custom gcode to enable / disable coolant channels if the predefined gcode is not appropriate. See more here:

Fusion 360 Post Processor (v2.1) is Available

I tried to recreate the problem with new project in Fusion but it didn’t appear there. In the original project it is there though. In view toolpath it seems that Fusion sometimes does not create Rapids if Lead-In is turned off in linking tab.


Trace1_2_w_Lead_in.gcode (19.2 KB)
(18.9 KB)
Trace1_2_wo_Lead_in.gcode