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.
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 
. 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:
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
Ouch, that looks like a F360 bug. Interesting that with lead-in off (example 2) it is still generating them.
I would assume there should always be a rapid at the start to position the cut. Unless this is some “feature” of a linking operation?
Good question for AutoCAD forums or their support. Let me know what you find out.
Post processor can’t fix a bad toolpath unfortunately.
1 Like