Fusion 360 2d adaptive cut rogue behavior

I posed here first because i thought this was a fusion problem; however, looking at several NC/gcode programs, it looks like there is something going on with how mpcnc is interpreting the gcode.
I get several rogue cuts from running mutiple 2d adapative cuts.

I believe this has to do with the “linking”. I have setup the same manufacture process, but this time i had individual 2d adaptive clearing instead of selecting all the sections on the same toolpath. same depth limit of 5mm. so far so good on my cut this time.

Him Tim. I took the Fusion 360 file you provided at the Autodesk forum, produced a g-code file using the guffy Marlin post processor and ran that file through a g-code simulator. I did not see any problems. This is essentially what they did on the Autodesk forum, but I wanted to make sure I produced the g-code file using the guffy post processor. The Marlin g-code interpreter is very well tested since it is at the heart of many 3D printers, so while not impossible, I doubt it is the root of the issue. So my first though is some sort of mechanical problem with your machine…grub screws a bit loose for example, or a cut that is too aggressive and causing the stepper to slip under certain conditions. But without more information, it will be difficult to track this issue down. A picture of the piece with the bad cut might help. A cut down example might help. Isolating the part of the g-code that is causing the problem might help. The actual g-code file that caused the problem might help. Video of it going bonkers might help.

it just happened again and wondering if you could look at this section of Gcode…should it have a “X value” right before the “movement cutting”?

G1 X365.282 Y341.553
G1 X365.544 Y340.969
G1 X365.61 Y340.82
; MOVEMENT_LEAD_OUT
G3 X366.206 Y340.891 I0.286 J0.139
G1 X366.216 Y340.94 Z-12.796
G1 X366.227 Y340.987 Z-12.784
G1 X366.236 Y341.032 Z-12.765
G1 X366.245 Y341.074 Z-12.739
G1 X366.253 Y341.111 Z-12.707
G1 X366.26 Y341.142 Z-12.669
G1 X366.266 Y341.168 Z-12.627
G1 X366.27 Y341.186 Z-12.581
G1 X366.273 Y341.198 Z-12.532
G1 Y341.202 Z-12.483
; MOVEMENT_CUTTING
G1 Z16
; *** SECTION end ***

Images of bad cuts:


this was on a different run when i isolated all the adaptive passes to use one contour at a time.

https://www.amazon.com/photos/shared/fQNaDpQcRwSuZ1eZqOwDnA.uL0qHQ29U9VsgaN3sWKQL2

this is referring to the following Gcode that was generated:
https://drive.google.com/file/d/1-7z_mtSREHBGwkNEcjtiHzUyBFom0IB9/view?usp=sharing

here are the bytes/info of the post processer files i’m using:

If you haven’t already addressed it, I have an idea about your issue. Recently Fusion 360 removed rapids from the free version of Fusion 360. Looking at your g-code file, it appears you are running the free version. I see:

;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. 

This causes problems on the MPCNC since the screw driven Z axis cannot move as fast as the X and Y axes. Without the rapids, the g-code attempts to move the Z axis too fast. The solution is to limit the feedrate for the Z axis in the Marlin firmware. If you have not already fixed this issue, you can address it by sending the following two lines of g-code once (it is a persistent fix):

M203 Z8   ; Limit feedrate to 8mm/s (480mm/min)
M500      ; Save the changes to EEPROM

it just happened again and wondering if you could look at this section of Gcode…should it have a “X value” right before the “movement cutting”?

This is not a problem. X will just remain unchanged.

changes made…sending new job now. fingers crossed.

it was going so good and then this happened.


https://drive.google.com/file/d/19wQbxBRGWvjyzPdVBMqMo6pkABHo2E9N/view?usp=sharing

How are you sending the job? We have seen issues like this that were from the lcd sd card. The trouble seemed to be EMI (electrical noise) on the lcd cables. It would occasionally just drive to Y=0 or Z=0. Presumably because it was missing a number in a gcode line.

1 Like

yes. i’m using lcd and sd card. i guess it’s time to switch to octoprint. i am inclined to think this is the issue because I just took the same job and set it back to x0 y0 rebooted and re-ran the same job and it did not go “rogue” in those same places…it picked a different place to go wild this time.

If the issue is EMI then can he solve it by shielding the cables? If so, do you recommend any particular shielding?

Tim: You might want to send a M503 g-code and see the results to make sure the feedrate was correctly changes. I think you will have to run it from something like Repetier-Host to see the values.

i did verify the M203 Z8 went through. it ran slower than molasses. not optimal at all because it was throwing saw dust and not chips.

You might be able to bump up the feedrate some. If you are using Ryan’s/Jeff’s firmware, the original max feedrate for Z is 15 (900mm/s), and I know that for my cutting it was too fast. I was losing steps, and there were others on the forum complaining of losing steps. But you might get away with 10 or 11…especially since the Z feedrate does not appear to be at the root of your issues.

When we saw this before, there were a few mitigations they used. If you have extra long cables, then you may need to replace them. Then make sure they aren’t running next to other cables, especially the motor or power cables. Then I would try wrapping the lcd cables in aluminum tape, but I think that will only really help if the tape is grounded, which is a pain.

Try it with a computer first to confirm. I would hate to see you go too far down that road without confirmation.

so i can report that after removing the LCD cables and using octopi to send jobs via USB, i have had 3 successful jobs run and no erroneous cuts/behavior. Thank you @robertbu and @jeffeb3 for helping me get this sorted out. i’m back to throwing chips again! I think one of the main reasons this never manifested for me was that I don’t think i ever went above 6-7 mm (1/4 in material). either way, i’m excited that got octopi up and running as this was going to be my next progression anyway.

3 Likes