Still being driven mad by arcs

[Hood]

Is it easy to distinguish which axis it is?
If so then does it swap to the different axis if you swap motors on your drive?
If you swap pin assignments in Mach?

Hood

[Cactus Pete]

I have not tested this in Mach3, but in Mach1 there is a math algorithm issue when converting metric code to inch for the machine movement.  When running Mach1 with a metric gcode on an inch based machine with inch based lead screws,  I found several "poisoned" locations where a G2 or G3 command would be ignored or not executed.  When an arc command was given, followed by the next line of code to drop the Z for multilevel cuts to machine a post, the machine would remain stationary and only make one drop after another in Z while ignoring the arc commands in between, manifesting them as a pause.  The same set of code would work in some locations, but not others.  To prove this point, I changed the "poisoned" location by repositioning the location of X 0.01mm and the "I" arc center coordinate by the same amount so that the arc was still the same diameter.  This solved the problem.  I can only surmise that the issue resides in Mach1, and possibly Mach3, if the basic algorithms were not changed.  It must be an issue with rounding or conversion of metric to inch.  I ran into this with some other unrelated programs that also were metric and were arcs.  It was not until later that I was able to isolate the problem.  Rewriting the code by hand never had an effect.  This might also manifest as lost (or gained) steps when there are many G1 movements in a metric set of code.  I am doing all of my machining in inches until I can be sure.

[GytarrMann19]

Hood,

The problem seems to exist in both axes, though most notable in the Z axis. I've been experimenting with different sizes of arcs and varying amounts of arc swing. The program that originally showed the problem was a .0315"r arc swinging 90deg. I've gone up to .5" arcs and the loss of position seems equal. The one exception being full circles, where the loss of position is very small (too small to measure in one cycle, it may go out .005" after 20 times.)

As I said, the single biggest thing to help so far was setting the axis accel rates the same. I also experimented with CV v. Exact Stop modes to no noticeable effect.

Pete,

I'm doing all my work in inch mode with inch programming on an inch machine, so I don't think there are any issues there.

How about a drive tuning issue or Mach motor tuning issue?

Kevin

[Hood]

Mach motor tuning of servos is straightforward, you  you max RPM so you can work out the max Velocity from that, the only thing you have to find is the acceleration and that is fairly straightforward as you just keep increasing until your axis faults. However this assumes that your drive/motor tuning is good and tight with a low following error set. I presume you can setthe following error in the drives? So first thing to get right is the motor/drive tuning. Can you monitor the axes position from drive software? What kind of following error do you have set? On my machines I usually aim for about 20 counts following error allowance with 8000 counts(2000 line) per rev encoders.
Hood

[GytarrMann19]

I spent a couple hours tonight playing with the drive/motor tuning settings, i.e. PID values. This got my peak error down to under 10 counts with 1000 line encoders. I have the drive set to error at 15 counts. Not too shabby. With the new settings I'm getting much better results with my position loss. Not sure that its perfect yet, but much better.

I'm still not too pleased with the motor performance graphs, I seem to get a little more oscillation than what the book deems ideal. But I really have no idea what that PID stuff means.

Kevin