Hello, I am using Mach 4 and I run small very small intricate detailed music instrument parts. Normally I have no issue running the parts. But recently I noticed something new happening. A part might have 4-5 machining steps. So in fusion I might have 2-3 rotary jobs, and then a contour or parallel path in between. These 4-5 machining steps use the same bit so I export all the steps as 1 file to run.
Each of the steps runs perfectly fine, great cut speeds, nothing too fast or too slow. BUT for some reason recently when it will jerk the axis at the start of each step now. I ran CV tuner, lowered acceleration from default 1000 to 500, lowered the rapids to 25% roughly 125ipm from default 600 on last test run. But it still jerks at the start of each program step which causes it to knock it out of alignment. I’m not sure if this is a recent update in Fusion360, some incompatibility with the post processor, or my machine.
I just noticed at the start of every step there is a large increase in the rotation speed and not sure if this could be the cause of the sudden jerk?:
Just to experiment, if I use the default rotary post processor with fusion360 it now outputs those large F values at the start of each program. Yet if I enable radius arcs it doesn’t seem to be outputting it anymore from a visual review of the gcode output. I haven’t run a test yet to see results. But curious now about other options. Should I enable radius arcs, should I be using inverse time feeds, any of those use subroutine options improve g-code any? Thanks much for the help!
The large F commands are in G93 inverse time mode. That means the feed rate is distance x FcmdValue. In your third block of code, the linear step is Y0.0002 inches and the angular step is A0.007 deg. With an F command value of 139403.3228 1/min, the linear feed rate is 0.0002 inches x 139403.3228 (1/min) = 27.88 ipm, and the angular feed rate is 0.007 deg x 139403.3228 (1/min) = 975.8 deg/min (about 3 rpm).
These are both reasonable values for feed rate, but the short move (0.0004 sec long) could be causing numerical issues. You can try putting these code snippets in their own file to see if you can reproduce the jerk. Run different subsets of the code until the problem shows up so you can isolate the line that’s causing it.
If you don’t need simultaneous linear & rotary moves, you can try disabling inverse time feeds. If the rotary rates become ridiculously slow, then you’ll know you need them.
I wouldn’t expect the radius arcs setting to fix the problem because there are no arcs commanded in these code snippets, but it could have some impact, I suppose, maybe through different handling in the post-processor.
It would be nice to know why it’s commanding such tiny steps in the first place.
Thanks for the info! Helps make it clearer. Your right the arc radius didn’t help. The parts are small and intricate details. I use rotary axis for the entire part. It starts with a very small 2-3mm round tip to a wider 22-23mm wide by 8mm thick face with fine intricate carvings so I use 0.0005" tolerance, with 0.002" smoothing, 0.002" stepover, and run 5 ipm for the small part circular cut both ways, 15 ipm for the larger part circular both ways, then it runs a shaft component aprox. 8-9mm so 30 ipm with a continuous spiral. For some reason it cuts each program perfect but just ran a test and noticed it is gone from the first two step transitions. But it was present for the 3rd so will look into the gcode to see if anything there that looks suspicious.
Even though the parts in question ran fine previously. I believe some sort of update in Fusion360 is just generating something new that is causing the sudden jerk motion in transitions between programs (when you have multiple continuous steps in one file).
To compensate for it I dropped the acceleration on my A-axis (rotary/indexer) from 500 to 300 and was able to raise the cut speed 25%-30%. If I cut larger parts the original 1000 accel may be fine, but for very small intricate parts I’m using a fine point bit the 300 acceleration seems to be running very smooth and less wear on the machine from those random sudden jerk motions that can knock it out of alignment.
For anyone working on understanding their gcode better, checkout “G-Code Syntax” and a highlighter like “nc-gcode” in Visual Studio Code application. Also, integrating GPT4 through an extension like “Code GPT” can be a great helper to step through and diagnose any issues you have!
So I ran a different program today that always ran perfectly fine and the file locks up the rotary axis and I’m thinking it is the Mach4 look ahead value. I just noticed it is set to 20 on recent install of 2.4.3 and I have suspicion it should be 200? Although I haven’t tested that theory yet. It appears that the gcode is fine nothing out of the ordinary so it might be locking up because it is choking on the speed of the lines. Running a test now and it kept locking up at the start running 35ipm so dropped it to 70% and it is fine now. The cut is spinning in one direction for entire rotary pass and it was choking at 100%. I notice the spin isn’t that much slower at 70% but the lines scrolling is much slower. I will run part again in an hour and see if 200 look ahead fixes the issue or not.
200 look ahead didn’t solve it, just seems to be exceeding the velocity of the rotary axis now at the start and needs to be slower then I use to run it.
