I am trying to generate gcode from Fusion with guffys post processor. For some reasons Z feedrate in gcode seems to be the same than with X and Y, in my case 720mm/min (cutting rate from fusion feed&speed) . So neither the Travel Speed Z option in post processor nor max Z feedrate in Machine Kinematics in Fusion are working. They both are set below 400mm/min. This is my first time trying to create gcode straight from Fusion so I cant tell if this is something to do with the newest Fusion update or what. Plunge speed limit seems to be working but it only limits plunge moves. Anybody having the same issue? Or is this even anything to be concerned about?
The other issue I’m having is that the first move from machine 0,0,0 to entry position does not take retract or clearance heights into account and is dragging the surface. This is something I can fix manually by lifting the machine after setting z=0 but it’s against the idea I think.:D.
Also tried the other post processor, martindb’s, both issues appear also with it so probably Fusion is the problem?
I used Estlcam earlier succesfully but my current project includes a lot of difficult 3d shapes and various toolpaths so Fusion would be better I guess. If it worked.
;Fusion 360 CAM 2.0.9009
; Posts processor: DIYCNC_Marlin20.cps
; Gcode generated: Tuesday, 6 October, 2020 10:40:51 GMT
; Document: Akustinen Kitara1 v14
; Setup: Setup2
;When using Fusion 360 for Personal Use, the feedrate of rapid moves is reduced to match the feedrate of cutting moves, which can increase machining time. Unrestricted rapid moves are available with a Fusion 360 Subscription.
; Ranges table:
; X: Min=-317.209 Max=6 Size=323.209
; Y: Min=-317.209 Max=6 Size=323.209
; Z: Min=-18 Max=5 Size=23
; Tools table:
; T1 D=8 CR=0 - ZMIN=-18 - flat end mill
; *** START begin ***
; *** START end ***
; *** SECTION begin ***
;Bore1 - Milling - Tool: 1 - flat end mill
; X Min: -6 - X Max: 6
; Y Min: -6 - Y Max: 6
; Z Min: -18 - Z Max: 5
M0 Turn ON 11999RPM
; MOVEMENT_CUTTING G1 X4 Y-0.8 Z5 F720 // dragging is not problem here because travel is short but the problem exists G1 Z2 F720 // this is too fast
; MOVEMENT_LEAD_IN G1 Z0.8 F720
G1 X4.004 Z0.722 F720
G1 X4.015 Z0.644 F720
G1 X4.034 Z0.568 F720
G1 X4.061 Z0.494 F720
G1 X4.094 Z0.423 F720
G1 X4.135 Z0.356 F720
Can you post screenshots is the speed panel for the toolpath?
New restrictions on the fusion personal license will limit all travel moves to the cut speed, but it shouldn’t speed them up. That’s really odd. Of course, fusion releases updates every month with a list of bugs they fixed, soooooo…
As Tony suggested, my first thought was Fusion 360’s changes to feedrate for their personal use license. If it is a Fusion 360 bug rather than an issue with your settings, you might be able to work around it by inserting an M203 command in your gcode file. Note this command takes units per second, not minute.
I am having the same issue. It is because fusion took out the rapid movement.
How it was working before it used G0 and the postprocessor was able to seperate the xy and z axis for moves that not belongs to any operation. But now fusion is saying all these movements counts as cutting movements and now the postprocessor can’t seperate them, so all the axes using cutting feed rates. It is super annoying since my (and might everybody?) MPCNC Z axis can only go as fast as 300 mm/min
The move from 0,0,0 to the first position is caused by the hobby version of F360 converting all Rapids to cut moves.
If you inspect the tool path operations inside F360 you will see the first move is a Rapid to the start location. Rapids are implement in Guffy’s post processor as a move first in Z and then XY. This raises the tool before moving sideways. The same is not possible with cut moves as there may be a cut that moves X, Y, and Z at the same time.
I’ve been working on a new Post Processor and it addresses
ensuring the first move in each cut path is converted to a Rapid, thereby raising Z first.
scaling the feedrate to ensure it is within the limits of mpcnc’s x,y,z axis speeds. This allows 3D moves, like in the corners of Engrave operations, not to violate the x axis low feedrate.
recovering most of the Rapid moves that were converted to slow cut operation by the hobby version of F360. This is possible as to accomplish #2 I need to track the current position in addition to the target position of each cut. Since I have the current position I can determine if the cut is above the material. If it is then it is converted back to a Rapid.
I’ve done several cuts with the resulting Gcode and everything worked as expected but this doesn’t mean I consider it well tested.
Because of the extensive changes I isolated the mpcnc code from Guffy’s code that supports firmware other then Marlin. This is fairly easy to correct, now that my other changes work, but I just have not done that yet.
I had planned to create Pull Requests to merge the code back into Guffy’s repo but the changes are not issolated - so this is not simple. My code is currently in a branch in a forked repo.
I’m looking for people that want to test this Post Processor. Hoping to tidy it up and make a test post processor available this weekend.
@guffy if you have thoughts on a PR to bring the code into your repo we should talk. At this point though all the code has been duplicated into a new file and then changed. I will attempt to again create a commons.js but it has significant changes and I can’t say it hasn’t invalidated some of the extra features you supported.
Honestly, last time many of my DIY activities became significally reduced. Unfortunately. And latest Fusion 360 limitation changes disappointed me a bit too.
But I found a task to somehove overcome them and make PP more safe interesting.
By the way, it seems that CAM motion engine of F360 does not respect to kinametic limitations that you may define for your machine (and select it in a setup). Maybe I’m wrong with this point, but it seems like that. So for a CNC that has limited feedrate for some axis (like MPCNC) it is a big problem, more general that just rapid moves.
So I decided to spend a few hours to solve 2 tasks:
Trying to detect that it is a rapid movement. Only cases when it safe. This can save machining time for sections that use a lot of lean-out/move/lead-in steps.
Proportinally reducing feedrate when Z part of it overcomes maximum defined feedrate for Z axis (taken from Z travel speed option). So I hope any motions will be safe against Z abilities.
Hi Guys, I am trying to import these post processors in Fusion 360 and it is telling me that it is invalid.
I have the personal license and I am facing issues with the gcode generated by fusion. I think it is related to the arc movements and that kind of stuff.
I am still facing issues when running my g-code. It stops in the middle and I suspect it is related to the arc rounding issues. I even disabled arc and still have issues.
I have to leave, so I cannot give you issue much thought, but if it happens with just the Arduino, one approach would be to cut out G0/G1 in the .gcode file to see if you can isolate a particular part of the file that is causing the problems and see if there is any unusual g-codes. Maybe bit change gcode is being inserted?