The issue I’m having today is that as I attempt to cut this job the tool is raising as it moves through the arc of the radius and lowering back down as it gets to the other side. For reference, I did all the design and manufacture steps in fusion 360 and output the g-code using the Maslow post processor. I have done things like this before with no issue but now (after Many fusion updates) this issue raises its ugly head.
here is the Maslow G-code post from fusion : CBP.nc (223.2 KB)
And here it appears to have the same issue but I’m not a G-code expert so I’m really not sure, posted with the Acramatic Post Processor : 1001.nc (190.4 KB)
As always any help is greatly appreciated, So thank You All in Advance!
So I had a quick poke around in the first file, and there’s no ‘K’ values for any of arc commands (G2, G3). So there’s nothing from a GCode perspective to raise (or lower) the tool while cutting an arc.
You’ve got a single plane defined at the start - G17 (XY) so there’s no reason for any other funkiness in interpreting the arc commands.
There’s very few Z values throughout the entire cut. So this could be some weirdness in interpreting the arcs.
Having said the above most of your GCode is straight forward G1 linear cut commands that have been path-matched to the curves of the lettering. You’ve got very few arc commands at all. Are you sure that it is the actual G2 / G3 commands doing this? Could this be a mechanical problem?
So I asked this same question on the Fusion 360 forums. here is a link to what was found: https://forums.autodesk.com/t5/fusion-360-manufacture/z-axis-lifting-during-radius-cut/td-p/9577453
I believe there is an issue with the Maslow Post Processor for Fusion. I don’t know how to make changes to the Post, if that is indeed the problem.
So as I read through the forum post I made on the 360 forums I see that the Maslow Post is telling the tool to plunge the depth I set of -.150 and then to raise to -.075. The problem is I did not program it to come back up to -.075 . It should be staying down at the -.150 number I set in the Fusion software.
Has anyone else had an issue like this? The issue appears to be in the Post Processor but like I stated in the other post I’m not the guy to be messing with that. So any help would be greatly appreciated.
I’ve had more luck using the Grbl post in Fusion. You might want to give that a try and see if you have the same issue.
Thank you for the suggestion. I will try that in the morning. Do you know what the difference is between the two posts, GRBL and Maslow? I haven’t had any issues , that I was aware of, until now. I’m just wondering what could have changed.
The posts are all different “dialects” of g-code, depending on the machine, they all read slightly different versions. GRBL is the more generic version that the Maslow is based on, so using it will help troubleshoot a post/hardware problem. The main difference is that GRBL has more commands available to it, so it has more functionality. In the Maslow’s case, it will ignore any unsupported commands.
I’ve been using the Maslow Post basically since AutoDesk wrote it for us and I haven’t seen any issues like this. One thing you can try is to turn off arc moves. If you look in the post window, there are a whole bunch of custom properties at the bottom right. You can try to disable arcs and turn off radius arcs and see if that converts all the G2/G3 (arc commands) to G1 (straight line) segments. It will slow down the Maslow a bit as it has to send more lines of code to the controller, but it may behave a little bit more like you want it to. You can change the size of the G1 line segments by changing the value of “(Built-in) Tolerance”. You will have to scroll through the list to find these properties
Trying the GRBL post will also be informative, so if you don’t mind trying a few things out, I’d try that as well.
Unless there’s been an update to the Maslow firmware, G17-G19 aren’t supported, so those commands sound get ignored. In this case, it sounds like having that functionality would be helpful, so the Maslow knows it needs to constrain the arc move to the XY plane.
the maslow doesn’t yet support radius arcs.
If the Maslow doesn’t support G17-G19, then by definition it ‘assumes’ everything is G17 - XY. And yes it should constrain everything to the XY plane deliberately, unless there is a ‘K’ value in there.
A ‘K’ value on an arc motion (G2, G3) in the XY plane should tell the processor to increase/decrease the depth of cut over the course of cutting the arc (i.e. a partial helix). This is how you can cut a screw thread for example.
radius cuts are supported in the latest firmware. A PR was done and I did the testing on it. It works. That was added recently, though I don’t know that it is released yet.
Ok, switching to the GRBL Post, fixed my issue, and for those who didn’t catch it, I may have misspoken on saying radius, as it appears the z axis and was raising and lowering during the lead in and out moves, not during radius cuts.
Thanks to everyone who put time into this issue for my benefit, it is greatly appreciated, and a big reason why, I Love my Maslow