combining two feedback devices, rotary axis

I made a 4th axis rotary table for my mill and it has a servo motor with Mesa 8i20, a low backlash gear reducer and a v-belt for the final drive.

Because of the v-belt the axis position creeps pretty much continuously when moving. It creeps about .1 to .3 degrees per revolution.

I have fitted a gage wheel encoder which has a hardened steel traction wheel that rides on the perimeter of the 19 inch diameter rotary table.

I would like to use this second encoder to correct the creeping position error.

I am following the insructions in the wiki entry about combining two feedback devices on one axis.

The wiki says that I should use the motor encoder for P and D and the extra encoder for I.


I don't know how to tune this, or if it is the right approach to use on my machine.

The motor runs OK with settings of P = 3 I = 0 D = 0.1.

If I add any amount of I , all motion stops.


I don't know much about tuning servo motors. I am not even sure what signals I should be looking at on the halscope.




### use sum2 component to combine gage wheel encoder(pid.5) and A axis motor encoder (pid.3) #
setp sum2.0.gain0 1.0
setp sum2.0.gain1 1.0
setp sum2.0.offset 0.0

# position command signals

net emcmot.03.pos-cmd axis.3.motor-pos-cmd => pid.3.command => pid.5.command

net motor.03.command pid.3.output => sum2.0.in0
net october1 pid.5.output => sum2.0.in1

net october2 sum2.0.out => bldc.3.value
net motor.03.current bldc.3.out => hm2_[HOSTMOT2](BOARD).0.8i20.1.1.current

You can probably put the I-gain in [AXIS_3] with the rest of the stuff, and it is entirely possible to add items, so you could use [AXIS_3]I1 and [AXIS_3]I2 if you wanted.

It seems strange that motion stops. does it f-error or actually stop dead?

On my own 8i20 / bldc component system I do not pass the current command through the bldc component. The component just calculates the rotor angle for the 8i20 to consume.
It is possible that your way does at least make it easier to reverse the sense of rotation of the motor, but I would check that if the pid output changes sign then so does th 8i20 current.

I-gains are generally quite small. I would start at 0.00001, then 0.0001 and so on until you get an effect.

Thanks for the help, Andy.

I tried smaller I-gains. With any number higher than .000001, the pid.3.output and pid.5.output change to 1 or something like .99837, but with opposite signs.

I guess that the opposite signs cancel each other out , resulting in no motion. The position display still moves and the velocity display shows maximum speed.

(I have the following error set to 99999 for testing purposes)

If I lift the gage wheel off , during movement, nothing happens. What I think should happen is that motor would gently speed up and try to get to the

programmed position.



I tried using the motor encoder just for commutation, and the gage wheel encoder for positioning, but the motor shook violently, I suppose because of the .080 degree backlash in the gearbox. ( I messed around with the dead band and backlash settings , a little bit, but was not able to stop the shaking.)



Do you think that I don't need to use the current command? I commented out this line,-

net motor.03.current bldc.3.out => hm2_[HOSTMOT2](BOARD).0.8i20.1.1.current, but then the motor would not move.

johns00056 wrote: I tried smaller I-gains. With any number higher than .000001, the pid.3.output and pid.5.output change to 1 or something like .99837, but with opposite signs..

It sounds like the two encoders disagree about the direction of motion. invert the sign of the friction wheel encoder.

I tried changing the sign on INPUT SCALE and that made the display count in the other direction, but that did not change any other behavior.

If the values of P, I or D , for pid.5. are larger than approx. .0001, the output goes to 1, which I presume is maximum output.



I think that there is something not right about pid.5.(for the friction wheel encoder) The output is always positive , no matter what I do.

pid.3.output (for motor encoder) moves from positive to negative as I expect it to when the axis over shoots or falls behind.

johns00056 wrote: The output is always positive , no matter what I do.

Is the error always positive too?

PID is three rather simple calculations to arrive at an output:

error = command - actual
P = error * Pgain
I = last_I + error * Igain
D = (error - previous_error) * Dgain

Output = P + I + D.

So, for the output to always be positive the error must be positive.

I suspect that the two feedback devices disagree about where they are. Are their outputs even remotely comparable?

You might have to try something a bit different if the two feedback devices are likely to develop a large disagreement about position. for example set up the motor encoder as a velocity loop, and have the friction encoder create a velocity request for that loop. (ie, loops in series not parallel)