Flyfisher604 Fusion 360 Post Processor (v1.beta3) is Available

Software / Firmware Fusion360
1

A new enhancement release (v1.beta3) is available for the Flyfisher604 F360 post processor.

This release supersedes the v1.beta2 and includes 2 enhancements.

Release History

----- Github tag: v1.beta3 -----

  • Coolant channels A and B can now both be enabled at the same time if they match the coolant type requested by the tool. This allows coolant modes like “Flood and Mist” that may need to be implemented with separate Flood and Mist hardware to use two channels for the one coolant type .
  • F360 doesn’t allow a coolant type to be defined for a laser. Now a coolant can be specified during a laser tool operation (for example air to blow smoke away) by using a new laser parameter in the post processor.

----- Github tag: v1.beta2 -----

  • SafeZ for conversion of G1s to G0s can now be set to reference the Heights defined in a tool’s operation. Valid references are Feed, Retract, and Clearance heights. Consult the documentation for defining the field correctly. Now defaults to Retract with a default of 15 if Retract height is not defined.
  • Comment level Debug now shows all F360 parameters.
  • Grbl laser fix: M3/M4 Laser On speed parameter was incorrectly scaled from 0 to 255, now scaled 0 to 1000. All other firmware remains 0 to 255.

----- 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.

Warning:

  • This code is considered beta and the user must review all GCode produced to ensure it is appropriate for their needs.

Documentation for v1.beta3 may be found here .

Here is a copy of Flyfisher604 v1.beta3
MPCNC.zip (14.6 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

3 Likes
2

Tested beta3… the PP now can properly add M8/M9 with laser cutting mode in f360. Everything else also works as expected (haven’t done everything of course, but does work with the handful of ops I’ve tested including 3d adaptive, 3d horizontal, 2d profile, pencil, and a few others). You are a good man Don!

I mentioned in the other thread advice on g0 replacement documentation, and explaining how the default settings will skip many desired g0 replacements. I also got g0 replacement to work with cutting operations. Normally when cutting, you don’t move z except for multipass with weak lasers. However if you don’t move z up at all, the PP won’t know where to add g0. So I just setup the cutting operation to retract 1mm, so the PP can pickup travel moves and replace them with g0. Overall this greatly speeds up operations, as 1mm retract combined with rapid xy is much faster than no retract with cutting speed travels. Of course with lasers, z hops are no big deal and won’t affect precision. So this seems to me like a valid workaround to get rapids in f360 cutting ops.

1 Like
3

I just noticed, when using Z during a cutting opertation it appears the g0 rapid replacement is not respecting safe z on the way down. It works properly for milling operations though. Here is an example of what I mean…

In a cutting operation, with g0 replacement set to 1, and retract height set to 3mm, the travel moves look like this:

( MOVEMENT_LEAD_OUT)
G1X106.562Y13.133
( >>> LASER Power OFF)
M5
( COMMAND_POWER_OFF)
( MOVEMENT_RAPID)
G0Z2.54F2500
X136.822Y128.825F7500
Z0F2500
( >>> LASER Power ON)
M4S800
( COMMAND_POWER_ON)

On a milling operation with the same parameters, it looks like this:

( 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

See how with milling, it rapids down to z1, then slows down to plunge rate. However with cutting, it rapids all the way to z0. Now, this isn’t going to cause any real issues with lasers that can plunge with infinite speed. However it just did not seem right to me, and would cause problems if someone was using a cutting operation with a hard bit (if that is even something anyone does I don’t know).

[edit: Disregard everything below… my idea actually changes the toolpath while it is engaged in a cut… no beuno.]
I also noted milling does not rapid going up (z+), where as cutting does (from zero though, which I noted above seems wrong). Not sure if it is possible, but rapiding up on z above safe height for milling will speed things up. So something like this would be ideal…

( MOVEMENT_CUTTING)
G1X109.247Y14.907Z1
( Safe G1 --> G0)
G0Z2.54F2500
X24.777Y55.558F7500
( Safe G1 --> G0)
Z1F2500
( MOVEMENT_PLUNGE)
G1Z0F508
( MOVEMENT_RAMP)
X24.742Y55.621Z-0.003F762

I know this may disrespect the original physical toolpath, but this is only happening in the air and the same end position is there (though it would have to be different for relative and absolute files).

4

I will have a look at the SafeZ moves while using a laser. I do recall thought seeing that F360 Hobby was leaving G0s for drilling operations and this may also be the case for some laser operations - can’t change to a G0 what isn’t already a G1.

1 Like
5

One more observation, and this may be more of general importance than just for f360…

When starting a laser cut where the first G1 move is very close to the current position (say we G0X0Y0 at the start, and the first cut is G1X0.01Y0.5), sometimes there is not enough time between M4 (laser enable) and the first G1 for the laser to fully turn on. I noticed this when I was etching my name in some tools, and the bottom inner part of the “B” was missing. It was the first part of the cut, and located very close to the part origin. The laser was simply not getting warmed up before that cut was finished (I could see the code was right, and the laser did move properly… just was not lit up yet).

I can workaround this issue by inserting a 1sec pause (G04 P1000) right after M4. Another less elegant workaround is to use absolute coordinates and make sure the head is far enough from the part origin to give enough time. Would it be possible to add a parameter to the PP to insert a pause after laser enable?

This would be fw independent. I know some folks aren’t using laser enable and just rely on pwm. They probably won’t have this problem. However, in my case I have to kill power to laser for safety, since ramps makes d44 (pwm out) high during reboot (not foating, so pulldown won’t fix it either). This means it takes longer after spindle enable before my laser can actually cut (capacitors have to charge, uC bootup, etc).

[edit: Saw your post after I replied. You may be right, and then there is nothing that can be done to change it in PP. If that’s the case, oh well, good thing it’s just a laser anyways.]