Problem with Fusion and Z feedrate

I wish it was bit change code related, but I am using the same bit for all the jobs.

The machine stops on idle mode, not hold, so something is wrong and it stops. I was able to run different types of jobs, like 2d contour and Pocket, but when using adaptive is when I see these issues, that is what makes me believe it is the arc issue. I even disable arcs, but still have the issue. Very frustating.

The idea that your halt problem is related to arc rounding does not feel right to me. A number of people on this forum use Fusion 360 (including me), and I’ve not seen any problems that cause a halt of any sort. The only issue I’ve seen is this one, and it is fixed in the latest V1 firmware releases (it was a Marlin issue and did not cause a halt). Here are four issues that I read about on the forum that have caused a halt.

  • I’ve read of a TTF issue that causes a halt.
  • I’ve read of g-code issues that cause a halt. Some issues are valid Marlin g-codes that are somehow inserted in the pipeline. Some are g-codes because the PP does not match Marlin. If you are using Don’s version of the Guffy’s PP, then it is pretty new and could have a bug.
  • I’ve read of overheated electronics causing a halt.
  • I’ve read of power issues including bad power supplies and the current set too high on the drivers causing a halt (reboot of the control board actually).

I’ve done a couple of simple pieces with Don’s version of Guffy’s PP, and have not had a problem, but none of those included any adaptive clearning.

If you want help from the forum on this issue, consider opening a new topic. Include information on your hardware and software pipeline. Attach the g-code file that is failing as well. Good luck. This is one is more puzzling than most.

Look to see if there is any Gcode with a feedrate of 0. Search for F0.

I believe a feedrate of 0 stops Marlin. If you are using my version of the PP please let me know if this is the issue. I thought I checked for the case but maybe its not working. It’s worth a look.

Can you cut the GCode up and do an air cut to isolate the issue?

Post your GCode in a zip so we can review and try on other machines.

1 Like

yes, you are right. thanks. fixed

2 Likes

First post. I’m not a MPCNC user, but I use Marlin for my Root3 CNC and have always used the PP from here.
Until now, I’ve been manually editing the G-code, not realising it was caused by the new Free edition rules. Main worry is that it moves all 3 axis simultaneously, marking my workpiece or potentially clashing.
Just tried the 1.1 Beta and even though I can see a few G0 now in my code, it’s missing the initial move.
; COMMAND_COOLANT_ON
M117 2D Contour1 (5)
;Detected travel mode Workaround
; MOVEMENT_CUTTING 2 false false
G1 X-54.446 Y-60.2 Z15 F600
G1 Z5 F300
; MOVEMENT_PLUNGE 2 true false
G1 Z3.6
G1 Z-1.617

Any ideas?

There is a new post processor that you could try for F360. See Flyfisher604 v1.beta5

Review it’s docs and set the SafeZ, G1–>G0 mappings and Travel Speeds and you should be good.

2 Likes

I ran into the same issue after the switch to Fusion personal license.
Using this postprocessor the Z can be separated from the initial move (Make sure to set the 'Map: Allow Rapid Z in the post processor setting)
; First G1 → G0
G0 Z15 F300
G0 X161.507 Y215.158 F450
Thanks FlyFisher604!

1 Like