Rigid Tapping - depth is short and retract overshoots

[cwatson1982]

Hi,

I am cobbling together a basic rigid tapping program based off the Mach3 program. I got it working finally(I think); for some reason I had to invert Z0 in the slave function to get it to work.

float Destination = (chan[SPINDLE_AXIS].Dest-S0) * SlaveGain + -Z0;

Z distance traveled and spindle revolutions are correct for the g-code parameters BUT:

When watching the DRO for Z (I put a 3 second pause between tap down and retract). The depth is short about .004" and on retracting back to the R plane, it overshoots exactly the same amount before re-settling to the correct position (I'm thinking when the slaving ends). This happens regardless of whether I tap at 50 rpm or 1000 rpm.

My spindle operates +-10v and has a 4000 ppr encoder output from the drive. I have it configured as a closed loop servo.

Everything else verifies as far as counts per inch for Z, etc.

This ONLY happens when tapping, it does not happen when making normal Z moves. It happens with backlash comp on or off.

Any idea why this might be happening? I took out the spindle error correction portion in the beginning of the Mach 3 code I copied over, and didn't realize that could have something to do with it until I shut down for the night.

[cwatson1982]

Looks like I fixed it. It was poor tuning on my spindle axis. I was only really paying attention to velocity when I tuned it the first time so following error was ~400 counts. It's now down to less than 10 and suddenly the DRO is hitting the correct depth and not over-retracting.

This would be a lot easier if I wasn't terrible at math!

[TomKerekes]

Hi cwatson1982,

I took out the spindle error correction portion in the beginning of the Mach 3 code I copied over, and didn't realize that could have something to do with it until I shut down for the night.

I don't understand. Does that mean the program you posted is different from what you are using?

There are several approaches to tapping. The Z motion can be synced to the commanded position (chan[SPINDLE_AXIS].Dest) of the Spindle or the measured position (chan[SPINDLE_AXIS].Position). If the Spindle is open loop then there is no choice but to use the commanded position. If the Spindle has feedback it is usually best to use measured Position unless the actual spindle motion is herky jerky such that the Z Axis could fault trying to follow it.

If the Spindle works well as a servo the Position should match the Command and there shouldn't be much difference. You didn't post the Spindle Axis Parameters. Having some I gain should make the average error zero. Without any I gain the actual position will likely lag behind the commanded position.

This line samples the Actual position at the start and is factored in to how far the spindle is commanded to move and in turn effects the amount of Z motion.

Code: Select all

S0 = chan[SPINDLE_AXIS].Position;

If Slaving Z to Dest it would probably be better to change this to Dest.

You might also try tuning the Spindle to have less error and so it actually goes to where it is commanded.

You might also try slaving the Z motion to the Position.

HTH

[cwatson1982]

Thanks Tom. I'm slowly learning. I haven't seriously coded anything in about 6 years; my last project was an Android accessibility service and UI in java that interacted with an Arduino over USB serial acting as a touch screen emulator. Takes me a while to get my brain back in to it.

I got it mostly working using Dest but will try re-writing it using Position.

My spindle seems to be very finicky about the tuning (I missed a zero in the last post, at 1000 RPM the following error was over 4k, an entire revolution). I can get it down much lower but there is a very small margin between acceptable following error and runaway oscillation when stopping or reversing. On the old control there was a "c-axis enable" output, separate from the spindle enable (the spindle was c on it); I'm going to wire it up and see what it does, if anything. It ran in open loop mode unless tapping or orienting.

[cwatson1982]

Yep, it completely changes the drives internal tuning Would it be possible to just re-set up the channel within the tap program and then switch back when tapping is over if I can't just run it in "c-axis" mode full time?

[TomKerekes]

Hi cwatson1982,

You can switch parameters if needed but I don't think it should be necessary. If it works as a servo well at low speed then when running at high speed it should still be stable. Especially since you probably don't care about accuracy at high speed.

You still didn't post your settings. But again if there is any I Gain then the error should reduce to zero at 1000rpm. Without any I Gain a large error will be required at high speed to generate the output necessary to run at high speed.

[cwatson1982]

P: .1
I: 0.00005
D:0
VFF: 0.0025

The I gain is small with a small integrator (50). Anything higher and it dithers at rest pretty badly regardless of what else is changed and sounds odd at higher RPM's. Any higher P with or without D results in run away when stopping/reversing. As it is I can get down to about 1k of following error but not much lower without issues. The tap program appears to run this way, after changing S0 from Position to Dest it's off by ~.0002 or so; which is probably fine.

With C-Axis mode on I can get up to:
P: 1
I: 0.0005
D: 15
VFF: .0045

This gets me smooth reversals, minimal dithering at stop, following error around 60 and exact bottom/retract. Unfortunately I discovered the drive limits max RPM to 2k in the mode so I can not just run it this way at all times.

I emailed the guy that helped design the servo and spindle system and am waiting to hear back from him as to what actually happens in the drive when c-axis mode is switched on. I don't have access to Windows XP to run the drive link software to check.

It's hard to believe these systems worked as well as they did. The control consists of 2! 486 motherboards, joined together with a "bridge board" that the I/O and Servo Board plugs in to. One motherboard does real time stuff ala k-flop. The other does UI, file handling, etc and runs Windows NT 3.0

[TomKerekes]

Hi cwatson1982,

The I gain is small with a small integrator (50).

Not sure what this means. Max Limit integrator? That would make it not do much of anything.

We'd really need to see all of your parameters, Filters, Configuration, and a Move Plot to help.

It not normally a problem to get stability and small errors if you don't care about performance just reduce the gains until it is stable.

Yeah it would be nice to know what the drive is doing.

[cwatson1982]

I installed VMWARE and Windows XP on my laptop so I could use the drive software. It looks like the c-axis mode changes the drives velocity integrator (doubles it) and also changes the electronic "gearing", reducing the ratio from .053 to .018. I believe this is how it scales analog input voltage and is why it wont go over 2k RPM in c-axis mode.

Even more frustrating is that I discovered it is a 4096 count encoder output and not 4k. This leaves me with a consistent 2.5% RPM error on the down side. Commanding 1000 rpm in g code, the drives monitoring software reads a velocity command of 975 RPM and an actual RPM +- 5.

[TomKerekes]

It looks like the c-axis mode changes the drives velocity integrator (doubles it)

Not sure what a velocity integrator is.

also changes the electronic "gearing", reducing the ratio from .053 to .018. I believe this is how it scales analog input voltage and is why it wont go over 2k RPM in c-axis mode.

If this is a scaling then I wouldn't expect it to have an effect on stability. Scaling down in the drive and scaling up in KFLOP (gains) should basically result in the same stability and performance. The only difference would be higher resolution on the DAC voltage which is not likely to be significant.

Even more frustrating is that I discovered it is a 4096 count encoder output and not 4k. This leaves me with a consistent 2.5% RPM error on the down side. Commanding 1000 rpm in g code, the drives monitoring software reads a velocity command of 975 RPM and an actual RPM +- 5.

Wouldn't that be simple to correct?