KFlop/Kanalog Circle Cutting Troubles

[EvanR]

Hey All,

I am REALLY struggling with my Kflop/Kanalog build here. I finally got my motor tuning to place where I was happy with it, my init and homing code set up and my IO wired. Unfortunately the second job I tried to run was a circular operation with a helical plunge and it just wont cooperate! It is almost like the Y axis is stuttering when it changes directions but I am not sure if its my arc and radius settings or if it the g-code instruction itself. I have attached a representation of the finished product along with my tuning results. Any help would be greatly appreciated. Thanks!



-Evan

Similar Threads:

• Looking for a Dynomotion Kflop and Kanalog
• kflop + Kanalog wanted
• Kflop/kanalog combo
• KFLOP/Kanalog set up
• KFlop Kanalog and DMM

[TomKerekes]

Hi Evan,

The Step response looks good. What are your other settings and Init C program? How was the data plot of the circle collected? What GCode are you running?

[EvanR]

Hi Tom,

I will post my Init C program so you can take a look at it (if you don't mind). I am not doing anything except motor params in it, and the Homing C program is pretty basic( I'll post that also). The circle g-code is comming from a drawing in Fusion 360 and using the RS274D post processor for Kmotion CNC. I will try to zip the G-code to u can upload.

[TomKerekes]

Hi Evan,

I don't see any issue with the C Code, GCode, or settings. The Step Response reversals only have ~ 2 encoder counts of error. What is the resolution of your system? Are your encoders linear or rotary? Are they measuring the motor or lead screw?

You didn't explain how you obtained the plot of the circle, how it was collected, or what the scale is.

You might also post your Trajectory Planner Settings.

You could use the example CaptureXYZPosDestToFile.c to capture the data while running the GCode to see if the servo is holding the position correctly. If it is it must be some mechanical error like backlash.

[EvanR]

What is the resolution of your system? Are your encoders linear or rotary? Are they measuring the motor or lead screw?

The resolution on the X is a 1000ppr encoder at .200in per rev (so 20,000 counts/inch). I have rotary encoders and they are attached to the back of the motor.

You didn't explain how you obtained the plot of the circle, how it was collected, or what the scale is.

I guess I don't fully understand what you are asking on this one. I just created a drawing of a 2x2 block with a 1.35 x 0.3125" pocket (using a circular milling operation) in Fusion 360, used the RS274D post processor with Fusion's CAM software to get my G-code.

You might also post your Trajectory Planner Settings.

You could use the example CaptureXYZPosDestToFile.c to capture the data while running the GCode to see if the servo is holding the position correctly. If it is it must be some mechanical error like backlash.

Ok, I will spend the day collecting more data on that. When turning the lead screw both directions by hand and watching the encoder counts, I see no backlash. When rotating, as soon as I change directions (with the servos off) the encoder counts change counting directions. Now, it is possible that the cutter is actually pulling the axis during a direction change when the motor is at almost zero command. But hopefully the capture program tells me that.

Thanks for your help.

-Evan

[TomKerekes]

Hi Evan,

You didn't explain how you obtained the plot of the circle, how it was collected, or what the scale is.
I guess I don't fully understand what you are asking on this one. I just created a drawing of a 2x2 block with a 1.35 x 0.3125" pocket (using a circular milling operation) in Fusion 360, used the RS274D post processor with Fusion's CAM software to get my G-code.

You posted a circle with some flat spots and some bumps to indicate the problem spots. How did you make this plot? The "bumps are how much in distance?

When turning the lead screw both directions by hand and watching the encoder counts, I see no backlash. When rotating, as soon as I change directions (with the servos off) the encoder counts change counting directions.

I don't see how you would see backlash rotating by hand unless the backlash was huge. Normally you would use a dial gauge and move in tiny increments like 0.0005 inches then reverse and watch the gauge to see how many increments before the gauge shows movement..

[EvanR]

I gotcha. I literally created that drawing in Windows paint. I was just trying to show where the problem areas were because I couldn't explain it well enough.

The main problem areas, on my machine, are right where the axis does a direction change.

As far as backlash, I was thinking the worst area would be between my motor and ball screw since 2 out of 3 are are belt driven but I was mistaken.
This afternoon I found the Y axis ball screw was a bit loose in the endcap so I tore it apart and tightened up the end cap nut. It is much better now but after using a dial indicator on the table itself, I found 225 encoder counts of
backlash on the Y axis, and 83 counts on the X axis, before any movement on the table occurred. I started messing with the backlash compensation settings and the problem areas on the part got much better but I am not certain I understand exactly how the system applies the backlash settings.

I have the X set to:
ch0->BacklashMode=BACKLASH_LINEAR;
ch0->BacklashAmount=83;
ch0->BacklashRate=1000;

And the Y set to:
ch1->BacklashMode=BACKLASH_LINEAR;
ch1->BacklashAmount=225;
ch1->BacklashRate=6000;

Hopefully I am not WAY off base here. Any help is greatly appreciated.
Thanks again.

-Evan

[TomKerekes]

Hi Evan,

Backlash compensation should only be used as a last resort and has limited benefits. It is like pulling a sled with a rope and trying to position it accurately. If there is enough friction and you pull it slowly it might work ok. But if the rope is jerked or something pushes on the sled (cutting forces) then it isn't likely to be accurate.

83/20000 = 0.00415 inches
225/20000 = 0.01125 inches

Seems somewhat large for a mill.

The rates come into play when the direction reverses, again considering the sled/rope analogy, we need to quickly run ahead to take out the slack in the rope. Too slow and the axis doesn't reverse quickly like it should. Too fast and there is a risk of jerking the rope.

83/1000 = 0.083 seconds almost 1/10th second to move 0.004 inches. Hard to say but maybe a bit faster would be better
225/6000 = 0.0375 seconds. Seems reasonable.

HTH