I’m surprised nobody has asked about your gcode sender.
Are you using universal Gcode Sender? If so, is it a 1.X version and not the 2.0 (nightly) build? I also use fusion 360 and I’ve never had an issue out of its grbl post processor.
I’ve had similar issues where it would carve perfect one run and completely screw up with the exact same code on other runs. The issue was UGS.
The 1.X versions use a method of sending commands where it knows how big the Arduino buffer is and sends enough commands to fill it without overflowing. The problem with this is if you tell the program to stop, it executes everything left in the buffer. The Biggest issue, and one that you are likely encountering is that this version of UGS does not, and cannot stop the machine if a line of code failed for some reason. And circular/arc gcode was ALWAYS the culprit for me. The machine thinks it reached the end of the arc but it really doesn’t causing a shift in the x-y axis positions resulting in incorrect homing. You can verify this by looking at UGS command table and you’ll see a lot of “error” showing up on the gcode arc commands.
The 2.0 “platform” nightly build (not the latest “stable” version as I found it unstable) is a better interface than the classic and it sends commands differently and more reliably. It sends a command and verifies it returns ok before sending another. I thought this would cause issues but I’ve never experienced any. It fixed ALL of my arc issues and finally made my machine reliable after months of debugging.
There is a minor annoyance with the UGS 2.0 platform version. It throws an unknown command on the tool change “T” commands. So I just modified the post processor to not spit those out. If you do a find for “T” (including quotes) in the post processor, you should find a couple of places. The only place that really needs commented out is the line that has the “T” and the “M” on the same line.
Good info, @JoshuaHendrix. I think a lot of problems are caused by the popularity of UGS.
That said, the OP said he’s run adaptive toolpaths with helical ramps without issue previously.
The sender could always be the issue, though.
Thanks for the recommendation. I am currently using UGS 2.0 and having the issues. I also tried the previous version and gives me the same result. It also doesn’t show any error when running.
I usually would manually erase the T2 M6 line. How did you change it on the post processor?
Have you tried the same code but with say half or a quarter of the current feed?
Or running identical code but change $120-122 to 50?
What are the stepper drivers, DRV8825?
What is your input voltage, 24V?
So I tried reducing acceleration and speed and the machine still doing the same thing just slower
Don’t know what else to try at this point
how can I check the controller to determine if it is working properly? I got an arduino based board (Phoenix CNC controler by Hayri)
I had a similar issue once because the set screw on the z-axis pulley had loosened a bit. I wasn’t loosing physical steps but the physical movement didn’t align because of a small amount of pulley slippage. Check that set screw to make sure it’s still tight.