Weird banging + following error disable on arcs?

[cwatson1982]

I haven't really run much of the HSM style adaptive toolpaths since I completed my retrofit last year due to the products I am making not really needing it until the last few days.

At certain code segments I am going from smooth motion to violent motion during small arcs, so bad that I am getting random X or Y axis disabled due to following error. (max error is set at ~.01", which has been a non issue so far, following error during tuning is under 60 counts or ~.0008 even at rapid speeds of 1000 IPM). I have had similar issues with non HSM toolpaths during vertical lead ins, there seems to be a large jerk when transitioning from the small vertical arc move to a linear move almost as if acceleration limits are not being honored, even at low feed rates.

This is code taken from the program that is causing the issue and seems to be arc related, this is not the worse spot but it's 1000's of lines of code and was easiest to find, feed rate is 60IPM but you can hear the banging even with feeds down to 20 IPM. This harshness persists even with acceleration set so slowly as to make the machine basically unusable (2 in/s^2, I normally run everything else at 9).

Code: Select all

%
G1 X4.352016 Y4.62238
G3 X4.328557 Y4.594552 I0.005832 J-0.028718
G3 X4.331621 Y4.580587 I0.029291 J-0.00089
G3 X4.411656 Y4.51855 I0.104405 J0.052047
G3 X4.450706 Y4.516903 I0.02437 J0.114084
G1 X4.475054 Y4.52086
G3 X4.45509 Y4.618996 I-0.08801 J0.033195
G3 X4.405596 Y4.631326 I-0.039559 J-0.053291
G1 X4.379165 Y4.626913
G3 X4.358287 Y4.585976 I0.005843 J-0.028772
G3 X4.475054 Y4.52086 I0.102584 J0.046701
G1 X4.499065 Y4.524761
G3 X4.482059 Y4.622179 I-0.084419 J0.035457
G3 X4.431338 Y4.635624 I-0.04078 J-0.051447
G1 X4.405596 Y4.631326
G3 X4.384307 Y4.591178 I0.005853 J-0.028822
G3 X4.460061 Y4.52684 I0.100988 J0.04214
G3 X4.499065 Y4.524761 I0.025234 J0.106478
G1 X4.523825 Y4.528784
G3 X4.507956 Y4.626022 I-0.082992 J0.03637
G3 X4.456798 Y4.639875 I-0.041214 J-0.050814
G1 X4.431338 Y4.635624
G3 X4.409866 Y4.595806 I0.005861 J-0.028859
G3 X4.484831 Y4.530948 I0.100353 J0.04024
G3 X4.523825 Y4.528784 I0.025388 J0.105098
G1 X4.548172 Y4.53274
G3 X4.527686 Y4.634791 I-0.078792 J0.037264
G3 X4.481963 Y4.644077 I-0.03576 J-0.058868
G1 X4.456798 Y4.639875
G3 X4.435127 Y4.600442 I0.005868 J-0.028896
G3 X4.548173 Y4.53274 I0.099624 J0.038117
G1 X4.57252 Y4.536702
G3 X4.55305 Y4.638644 I-0.077635 J0.038003
G3 X4.506924 Y4.648245 I-0.036168 J-0.058163
G1 X4.481963 Y4.644077
G3 X4.460129 Y4.604933 I0.005877 J-0.02894
G3 X4.533546 Y4.539014 I0.099048 J0.036472
G3 X4.572521 Y4.536702 I0.025631 J0.102391
G1 X4.596531 Y4.540707

I have tried different smoothing settings in cam, changing vertical and horizontal lead in radiuses to large numbers, turned off backlash comp, and played with the trajectory planner settings all basically to no avail. Turning on arcs to segments helps but only if I turn facet angle up to something non-useful like 5 degrees. For the vertical arcs, turning co-linear tolerance up from .001 to .004 seems to have lessened where they happen but not eliminated the issue.

Other trajectory planner settings are currently:

look ahead: 5 seconds
corner tolerance: .001
break angle: 179 (turned off, wondering if this is the issue, though I tried 90 with the same results)

When this happens, monitoring the drives there are current spikes up to ~6 amps, which is the continuous motor rating. Mechanically everything is fine and smooth as it should be. Rapid motion on all axis runs about 1.8 amps.

Any ideas, it's driving me nuts at this point and I am afraid to run the last batch of parts

[cwatson1982]

Disregard. I changed break angle to 45 and all my problems vanished, I was able to increase acceleration up to 18 in/sec^2 without any of the previous issues. I just didn't think it through! I can't even remember why I had it set at 179

[TomKerekes]

That's interesting. I was just looking into this. I wouldn't have expected that to make a difference.

The GCode has a sharp angle every loop of probably about 70 degrees:

Angle.png (11.69 KiB) Viewed 4917 times

With break angle of 179 degrees the sharp angle is rounded (Corner Tol = 0.001) and the feedrate slows way down to ~ 12ipm. Basically full deceleration of X then full acceleration in Y:

With break angle of 45 degrees there is a complete stop:

Its not clear to me why Break angle 45 would be so different or not worse actually.

Can you do something in CAD to avoid the sharp angle?

What Version of KMotion are you running?

[cwatson1982]

Can you do something in CAD to avoid the sharp angle?

What Version of KMotion are you running?

I tried all that I can think of. The default lead in/out radius for a 1/4" tool in the CAM software is .025, I increased it to .125 which didn't make any difference as far as the dynamics go, it just moved "where" it happened; neither did increasing smoothing substantially, turning it off, changing to a much looser tolerance or applying a slower feedrate to lead ins (what the arcs are). It's a 3D HSM roughing strategy so it kind of just does what it does with some adjustability. I would describe the motion as almost as harsh as using "step" in the step response screen at maximum motor velocity when it's at the worst portion of code.

I am running 4.35f.

I will see if I can get some video of running the above code with break angle at 179 and 45. I didn't look at the run time but I have a hunch the entire code fragment actually ran faster overall instead of slower (edit: it didn't it was because I was able to double the acceleration ).

[cwatson1982]

https://youtu.be/BabqqbAs-_4

Sorry for the weird EQ, it was the only way I could make the bang prominent over the phase converter and spindle motor/power supply fans.

[cwatson1982]

While I am at it: Does FRO effect acceleration limits or just velocity? While I was testing things yesterday I noticed that the machine does not hit programmed feedrates during tighter arc portions of the toolpath at 100% FRO due to what I assumed were my acceleration limits but if I turn FRO up beyond that, it will easily exceed the programmed feedrate; earlier in this same program with a programmed feedrate of 60 IPM, the display maxed out around 50 IPM at 100%, with FRO turned up to 200% it was able to hit 90+ IPM in the same spots.

It doesn't really make any functional difference for me, I was just curious when I noticed.

[TomKerekes]

Regarding Video: Its sort of hard to tell. I suppose I do hear a slight banging sound. You might have recorded with the Spindle off. We might also capture data including the XY Positions so we can see how the servo is following the different trajectories. It might be a quirk on how the servo is tuned where that trajectory start/stop rate excites some dynamic. Or maybe some mechanical cross talk between axes? Where some force on one axis induces a disturbance in the other? So decelerating one axis while accelerating the other cause an issue where when happening separately there isn't? Otherwise I have no explanation.

Regarding FRO: Two types of FRO are provided - Hardware and Software.

Hardware FRO works by varying the "rate of time". The advantage is it can be applied instantaneously. I think of it like turning the crank faster. The disadvantage is that maximum accelerations or velocities may be exceeded. If an original trajectory accelerated up to some speed in a certain period of time, then at twice the rate the trajectory will now accelerate up to twice the speed in half the time and require 4X the acceleration.

Software FRO properly trajectory plans for the higher speed goal where twice the time, and 4X the distance, is needed to accelerate to the double speed. Or the speed will be limited if not possible to be planned without exceeding velocity or acceleration limits. The disadvantage of the Software method is it must be planned ahead and buffered in KFLOP so involves a buffer delay in response.

KMotionCNC has a Feed Rate Override Hardware Range parameter to control how FRO is applied. See here.

[cwatson1982]

Thanks for the FRO information.

The motion is a lot louder and more violent than it seems in the video. You can feel it in the floor when it happens, especially further on in the program where it would actually trigger a following error alarm. The audio in the video kind of reduced it to a thumping.

I hadn't considered the servo tuning. I will give that a shot and try reducing VFF a bit first. As you originally had said, I still don't understand why reducing the break angle eliminates the issue, even with acceleration set to 3x the original values but it works, which is good enough