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)

I got this working now. the main problem was that I had pid.N.MAX_OUTPUT set to 1. When the output reached 1, the pid output went to zero, which stopped all movement. I fixed that by setting pid.N.MAX_OUTPUT to 0, which disabled that feature.


Summing the two pid's together did not do what I wanted so I ended up using the cascaded pid method ,as Andy suggested.

The axis does have some backlash. I measure about .010 inch backlash at 19 inches diameter , but only about .0005 inch at 4 inch diameter.
I think that most of the backlash comes from the "low backlash" Bayside planetary gear reducer.

I am very happy with the positioning accuracy. If I push the axis , with my hand, from one side of the backlash to the other , the motor will return it to the correct spot in about 1/2 second.

As a test I loosened the belts and shifted the position of the table , to simulate the belts slipping under load. When I cleared the following error and restarted the program , the axis went right back to the correct position within .001 inch.

I ran a test program for an hour which rotated a block of metal to a dial indicator , then away 270 degrees, repeated 500 times. The dial indicator showed no change in zero, although at certain speeds the axis would under shoot or overshoot a little bit. I had to add a 2 second dwell at zero to give it time to creep the programmed position.

(the axis has a brake to hold position during heavy cuts.)

I am homing to the home switch only and not using the encoder index.


################### 11/7/15 cascaded pid ###
# the position command goes first to pid.5 then to pid.3 and then to the servo drive
# this allows the friction wheel encoder to correct position errors caused by v-belt creep

net motor.04.pos-fb hm2_[HOSTMOT2](BOARD).0.encoder.05.position => pid.5.feedback => axis.3.motor-pos-fb # friction encoder, position only, to pid.5
#push copy back to Axis GUI
net motor.03.vel-fb hm2_[HOSTMOT2](BOARD).0.encoder.03.velocity => pid.3.feedback # velocity only , feedback to pid.3 (motor encoder)

net emcmot.03.pos-cmd axis.3.motor-pos-cmd => pid.5.command # command in to pid.5 for friction wheel encoder

net october1 pid.5.output => scale.3.in # scale component to make friction wheel encoder output the same scale as motor encoder output

net nov7 scale.3.out => pid.3.command # pid.3 for motor encoder

net nov71 pid.3.output => bldc.3.value # in to brushless D.C. component

net motor.03.current bldc.3.out => hm2_[HOSTMOT2](BOARD).0.8i20.1.1.current # command to motor servo drive

############ 11/11/15 pid settings #################
# pid.3 (motor encoder) ### pid.5 (friction wheel encoder)
# P 0.13 ################### P 2
# I .0001 ### ################ I 4
# D 0 ###################### D 0
# FF1 .003############# ###### FF1 0.6

johns00056 wrote: Summing the two pid's together did not do what I wanted so I ended up using the cascaded pid method ,as Andy suggested.

I am glad that worked. I had actually begun to wonder if you had had enough and given up when there was no reply for a few days.

You may find that more I-term gets that last bit of error out quicker.

Thanks for the help. I was pretty close to giving up, but I pushed on .

Next time I will think long and hard before trying an unconventional approach in a field where I am not an expert.

I am sure that I can get it tuned better, but I am going to run it as is for now.

johns00056 wrote: Next time I will think long and hard before trying an unconventional approach in a field where I am not an expert.

But now you are the World Expert, you realise?