sorry I forgot the add the full command is G92 X0 Y0 Z0 or just G92 Z0 for the z axis
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
Did the M203 help?
Hi, I ended up buying a subscription for Fusion so I can’t really tell.
Hi Ossi:
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.
4 Likes
hi
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.
You can fnd and try my version here:
That’s it at the moment.
1 Like
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.
Have anyone tried to import recently?
Thanks
Import does not work, but you can following the instructions here and just place the two necessary files in the correct subdirectory.
On my Windows 10 machine I place the files here:
C:\Users\rober\AppData\Roaming\Autodesk\Fusion 360 CAM\Posts
I use Marlin, so I put these two files in from the Guffy zip file in that subdirectory:
- DIYCNC_Common.js
- DIYCNC_Marlin20.cps
I suspect that the import fails because Guffy split the PP into multiple files.
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.
Thanks and Regard
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?
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