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 ***
G90
G21
M84 S0
; *** 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
; COMMAND_START_SPINDLE
; COMMAND_SPINDLE_CLOCKWISE
M0 Turn ON 11999RPM
; COMMAND_COOLANT_ON
M117 Bore1
; 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.
Just in case this is a useable workaround, you can set the maximum feedrate in Marlin with M203. That will make your max Z speed for any moves limited to that value.
The gcode should be right, and I haven’t seen this particular issue with fusion complained about before, but if you’re just worried about the top speed, then you can limit that in the firmware.
Hi Guys,
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
I think I’ve been having the same problem as you, my machine cut a big gouge into the workpiece right at the very start.
I fixed it by removing G21 and M117 lines. Full thread here.
I also had the issue of Z feedrate. Thank you Jeff, Robert and everyone for your help.
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.
While reviewing the Beta I noticed that the adjustFeedrate() appears to always return properties.jobTravelSpeedZ when the Z feedrate needs to be scaled.
Ignoring that properties.jobTravelSpeedZ is the Z travel speed and not the safe Z cut speed, there is an issue with the math.
The Beta’s calculation of the new feedrate is
var k = properties.jobTravelSpeedZ / _zfeed;
var newfeed = _zfeed * k;
If you substitute k into the second line then the two zFeed values will always cancel each other and you always get properties.jobTravelSpeedZ.
Thanks Robert, I was able to import by following the instructions you pointed out.
I am using Mac OSX so it was little different from what you mentioned, but it was there in the instructions.
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.
Do you think it could be related to the personal license of Fusion 360? I don’t wanna buy a license without knowing it will work with my machine.
BTW, I am sure it is not related to EMI, as the problem happens with just the arduino running.
Anyway, I appreciate any insight people would have to help me with this.
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?