Flyfisher604 Fusion 360 Post Processor (v1.beta1)

Software / Firmware Fusion360
1

Well I’ve continue to work on enhancing the Flyfisher604 post processor (PP) for F360.

A new beta is now available, release v1.beta1. This supersedes the v1 release that occurred a week ago.

Release History

----- Github tag: v1.beta1 -----

  • Select the firmware dialect as a property
  • Coolant bug resolved so coolant logic is no longer inverted
  • Coolant properties are unified to control either Marlin and Grbl firmware
  • Warnings if tool’s requested coolant is not configured on a channel
  • Single file reduces the complexity of installation
  • Installs without error via F360 standard Manage->Post Library install interface
  • Properties enabling features are list before feature control properties
  • Properties are listed in GCode for easy reference (more to come)
  • Updated documentation

----- Github tag: v1 -----

  • G0 Rapid move at the beginning of each cut is restored - resolves tool drag when Z is not retracted before horizontal travel occurs (F360 Hobby issue)
  • Recovers G0 Rapids that occur above a safe height or that are vertical only (F360 Hobby issue)
  • Feedrates can be scaled to ensure mpcnc Z axis cut rate is not exceeded. Fusion 360 kinematics do not respect an axes feedrate if different from the machine’s generalized feedrate.

Warnings:

  • The properties for v1.beta1 have been reorganized and in cases renamed, please review carefully and consult the documentation.
  • Defaults have been selected to generally disable features so they may be selectively enabled. Review properties carefully and enable what is needed. Feedrate scaling and GO Rapid recovery require properties to be enabled and are not enabled by default.
  • This code is considered beta and the user must review all GCode produced to ensure it is appropriate for their needs.

Documentation for the v1.beta1 can be located here.

Here is a copy of Flyfisher604 v1.beta1
MPCNC.zip (12.9 KB)

Once unzipped, mpcnc.cps can be installed using F360 Manage->Post Library. When running the PP use the Setup button to select Use Personal Post Library (will be remembered - required once).

Please report any issues to flyfisher604/mpcnc_post_processor Issues.

5 Likes
2

For some reason, the properties page is empty with this version. I rolled back to the previous beta, and everything is fine.

3

How did you install it?

Use the Manage->Post Library and import. Then in the Post Processor page when you run it use the Setup button and select Use Personal Post Library.

If you hover (don’t click) over the middle dropdown you should see this timestamp.

PP v1.beta1
PP v1.beta1615×547 62.2 KB

1 Like
4

Thanks. Missing step was selecting the library. It had been so long since I first installed guffy, I forgot that I even did it.

5

So it loads ok? Thanks you had me concerned.

Yes, no more having to side load by dropping in hidden folders. Look forward to hearing how it works for you.

6

Hey Don, just letting you know I did some more extensive testing with beta2, and it’s working wonderfully. I am getting correct feedrates and restored rapids with 3d adaptive, 2d contours, and 3d horizontal ops so far.

I did have some minutes of struggle over the default G0 replacement condition Retract:10. I read the docs to understand the format, and tried Retract:0 in attempts to get G0 for all moves at or above “Retract” as defined in f360 for each operation. I found this does not always work, since F360 sometimes doesn’t produce a “Retract” internally, and the PP misses the G0 replacements. For example, 3d adaptive gets g0 replacements because it produces a true “Retract”. Now, a 3d horizontal operation on multiple islands will not get g0 replacement, because it doesn’t not call out a “Retract” when moving between islands.

So I had to change the condition from Retract:10 to simply 1, which is what I set as retract height for all the operations. After doing this, all travel moves were properly replaced with G0. The problem with making 1 the default of course is, many newbs won’t fully understand WCS origin setup and how that plays into what number may need to go there. Since 99% of my milling jobs are done with zero on top of stock, 1 almost always works for me, and I know how/when to change it if I have to.

All that said, I think adding some info about this in the docs should improve new user experiences. I can imagine some short tempered folks giving up on f360 because they still have slow travels with the default MPCNC pp settings. Maybe just a quick explanation that starts with “Why do I still have slow travels?”.

Lastly, I am excited to see the changes in beta3 which will add forced cooling for lasers. You really didn’t have to do that… you are a very good man!

7

The number after the Height is a safeZ to use if the PP can’t get the Height for the tool operation - its basically a last resort fail safe.

If you do a simulate of the operation and it doesn’t go up to the Retract height then no safe change will occur. Is there a chance for that tool operation it was moving around inside the cut by just going up to Feed height. If so you could use Feed:1.

Bottom line is that the number after the “:” should be ignored if the Height exists in the tool operation.

I’ll look at the docs and see how I can improve them. That’s the problem with adding features the simple things get harder.

8

To illustrate what I’m seeing with the g0 replacement in milling…

Here is a snippet where 2d profile is moving between islands, with a condition of Retract:1, where a g0 replacement is missed (4th and 5th lines are safe, and should be G0):

X109.246Y14.911I-3.799J13.5
( MOVEMENT_CUTTING)
G1X109.247Y14.907Z2.54
X24.777Y55.558
Z1
( MOVEMENT_PLUNGE)
Z0F508
( MOVEMENT_RAMP)
X24.742Y55.621Z-0.003F762

Here is the snippet of the same move between islands, but with a condition of 1, and g0 is properly substituted:

X109.246Y14.911I-3.799J13.5
( MOVEMENT_CUTTING)
G1X109.247Y14.907Z2.54
( Safe G1 --> G0)
G0X24.777Y55.558F7500
( Safe G1 --> G0)
Z1F2500
( MOVEMENT_PLUNGE)
G1Z0F508
( MOVEMENT_RAMP)
X24.742Y55.621Z-0.003F762

Here is a different snippet moving between islands using 3d horizontal, which has properly replaced G1 with regardless if the condition is Retract:1 or 1:

G1X85.395Y46.402Z2.54
( Safe G1 --> G0)
G0X131.239Y43.519F7500
( Safe G1 --> G0)
Z2.27F2500
( MOVEMENT_LEAD_IN)
( Safe G1 --> G0)
Z1.334
( MOVEMENT_RAMP_HELIX)
G1X131.331Y43.644Z1.328F333

It seems the conditional is not getting the proper retract height in some cases. I thought the PP would simply store retract height as a constant, and compare z to that. Also it seems the PP should be using the fallback value “1” in these cases, but it is not. Having the “Retract” conditional seems to be interfering with the “1” fallback value working.

[edit: In all the above cases, for all operations, retract z was set to 2.54mm, and feed height to 0mm, in f360.]

9

When you say Retract:1 you are asking the PP to look into the tool used for the operation as see if it can find the Retract height as defined on the tool’s height tab. Only if it can’t get this will it use the “1” following the “:”.

Well I was confused until I read your last line edit:

[edit: In all the above cases, for all operations, retract z was set to 2.54mm, and feed height to 0mm, in f360.]

If Retract in the tool was set to 2.54 then the PP was finding it (unless there was some other error) and never using the 1 after the “:”. So you were asking for:

  • XY G1 cuts above 2.54 ,
  • vertical retracts that end above 2.54,
  • vertical plunges that end above 2.54

to be changed to Rapid G0s. Everything else will be considered unsafe. By this I don’t mean impossible but as the PP is not the CAD program I’m working with limited data and making only safe substitutions.

At the beginning of the GCode there is a section that looks like the following. The forth line show what the PP read from the parameters. Can you show me your what you get.

; G1->G0 Mapping Properties:
; Map: First G1 → G0 Rapid = true
; Map: G1s → G0 Rapids = true
; Map: SafeZ Mode = Retract : default = 15
; Map: Allow Rapid Z = true

Next, at the beginning of each Section (a tool operation) it will show 1 of the following 3 lines, each followed by a number. The is the Safe Z that is being used for that tool operations.

SafeZ retract level:
SafeZ retract level not abs:
SafeZ retract level not defined:

The first line occurs when the PP finds a height that is not defined relatively to other things. F360 in the dialog does allow you to define heights relative to each other, this is not an issue as F360 seem to always convert these back to absolute values for me. This is what you want to see. The number appearing will be used as SafeZ.

The second line only appears if a field I read not says the value is not absolute but relative. I don’t know what it is relative to and so I don’t handle that case. In this case the number after the “:” is used. Note, I have also not seen this case actually appear but there is code there in case it does.

The third line only appears if when I ask F360 for the Height used F360 tells me it doesn’t exist on this tool operation. In this case the number after the “:” is used. Note, I have also not seen this case actually appear but again there is code there in case it does.

Please attach a .zip of your GCode and I can fully review.

10

I found a bug in v1.beta3 related to Z retracts and plunges not using a valid value to compare the current Z height to. Please try v1.beta4

See the forum post Flyfisher604 Fusion 360 Post Processor (v1.beta4) is Available

11

Don, I have attached 4 different gcode files if you need them for data. Here is a preview of what the zipfile contains (1b3 was recently used to cut purple heart wood successfully… and quickly):

1b3retract: Using 1b3 w/ “Retract:1”, Safe z = Retract: 2.54, 13x g0 replacements
1b3: Using 1b3 w/ “1”, Safe z = const: 1, 49@ g0 replacements
1b5retract: Using 1b5 w/ “Retract:1”, Safe z = Retract: 2.54, 37x g0 replacements
1b5: Using 1b5 w/ “1”, Safe z = const: 1, 49@ g0 replacements

These files I think show that now 1b5 is behaving 100% as expected WRT g0 replacements. :smiley: The files using const=1 do have 12 more g0 replacements vs 1b5 w/ retract, but this is expected. They are 12 very short downward travels, which reflect the difference between using 2.54 and 1. I think sticking with internal definitions is best, and makes the workflow easier. I would just set retract to 1 in f360 if I wanted to speed it up from what 2.54 does.

g0replacementTestOutput.zip (1.2 MB)

[edit: …and of course you were right, there was a bug earlier that is now fixed. 1b3retract does in fact have safe z retract = 2.54.]

1 Like