HAL pin query (error?) in wiki "Combining Two Feedback Devices On One Axis"

Hello.

I have a lathe which has AC servos/high resolution encoders on the ballscrews.
I also have lower resolution scales on the axis' themselves (200 pulses per mm or .005 mm per pulse).

I have been reading the wiki "Combining Two Feedback Devices On One Axis" and I would like to check if there is an error?
In the wiki it states net X-motor-pos-fb 'axis motor position feedback' pid.0.feedback.
I take 'axis motor position feedback' to mean the "axis.0.motor-pos-fb" pin.

Am I right in assuming that this is the pin who's value is displayed on the DRO as the actual joint position?
i.e. taken from the manual: "axis.N.motor−pos−fb IN FLOAT The actual position for this joint."

If this is the case then wouldn't it be better to connect the linear scales to this pin under the assumption that as they are rigidly attached to the axis they will be free of backlash and other lost motion and thus provide the most accurate and direct display of position for the on screen DRO indication of an axis' position?

And thus (notwithstanding signal names) should the wiki have the following pins reversed:
4. linear scale position feedback connects to the input of the pid.4 PID
1. net X-linear-pos-fb 'linear position feedback' pid.4.feedback
5. motor encoder position feedback connects to the feedback input of the pid.0 PID
1. net X-motor-pos-fb 'axis motor position feedback' pid.0.feedback

I am keen to gather thoughts on the idea that the actual axis position, which scales provide directly, be displayed on the screen rather than a calculated position being downstream of motor encoder, ballscrew mapping, backlash, lost motion etc. being displayed. The way I see it, the best use of the motor encoder in this scenario is as a high resolution, high accuracy velocity measuring device (the servos are in velocity mode) to achieve the required position with ultimate reference to the low res scales (which should be set to indicate on the DRO?). It just seems that scale position would not be displayed on the DRO, rather motor encoder position.

Put another way, I have tried with the scales alone (not bringing in motor encoder feedback either for position or velocity) and given the low resolution of the scales, the velocity calculations and therefore accuracy of the axis is poor at low feed rates. Hence the idea of bringing in the encoder velocity from the higher resolution source of the motor encoder to increase accuracy, yet still have the most undiluted feedback information displayed on the DRO (the scales).

Of course I could have the concept and pins wrong but beyond the detailed wiki in question I don't have any better guidance to follow hence the question and search for any additional guidance. So in summary, is the wiki correct with its choice of which feedback device for which pins?

Thanks for all input.
Regards,
Marty.

I haven't tried this but I throw out my two cents...

The reason the rotary is used to be pushed back to the motion controller as feedback, is because it is understood to be higher in resolution - so less notchy in feedback.

The linear encoder is used to modify the command to the amps and in that case only for I in the PID which is what you adjust to fix steady state error.

An analogy might be calculating distance by counting telephone pole (linear encoder) and rotation of the car tires (rotary encoder)
The telephone poles give great absolute position when you are directly across from them, but the tires tell you more information when you are between the poles.

While I agree in principle if you could combine the two feedback for posiiton back to the 'DRO' would be better, I bet that after you consider the PID tuning it does essentially the same thing.

Chris M

Hi Chris.

Thanks for the reply, and I think you have given me a different way of thinking about this.

After your input, my new view point is based upon the fact that historically the majority of machines did not have scales. In other words, they relied entirely on motor encoder feedback which was then modified by backlash, possibly screw mapping and other offsets etc. to arrive at a satisfactory joint position which was fed back to the controller and was largely accepted as "correct" in the absence of other supporting information.

If we take the above as a foundation, then the scales serve to add that "other" supporting information to the loop rather than necessarily being primary. As an enhancement, rather than replacing the foundation.

To take this a step further, I draw upon the behavior with backlash input. To be able to more clearly see its effect, I have put in a ridiculously large backlash value, say 10mm, and so at axis reversal I see the axis "jump" the 10mm to respond to the backlash input. In theory there is no actual change of position with this move, the axis simply thinks it is taking up the slack of the ballnut to go the other way and not loose motion in the process. Thus when this backlash jump occurs the DRO remains at the previous value. Again, this is completely logical given that backlash is not used to modify position, rather remove otherwise lost motion by moving the motor/ballscrew a prescribed number of encoder counts but whilst doing this not changing the "actual" joint position as far as the controller is concerned (i.e.not change the DRO readout).

Move now to my experiment where I had sole input from glass scales feeding back to "axis.N.motor−pos−fb". If a backlash value is used here, upon axis reversal the axis moves to take up the backlash value but freezes the DRO value in the process. In the case where the motor and encoder feedback position to the controller this is desirable behavior, whereas in the case of a scale this is undesirable as by freezing the DRO we are loosing actual axis/joint positional accuracy.

Thus it brings me back to my original comment that perhaps the best way of thinking about the scale's role in the wiki is as supporting information for the historical motor/encoder feedback loop, this being tied to the "axis.N.motor−pos−fb" pin. Taking backlash as an example, in this way, any backlash applied will be applied to the motor/encoder loop which is correct. This should also leave the scale value unaffected which is also correct. This then leaves the original scale value in place to continue to provide supporting info based on its still accurate joint position, to refine the motor/encoder position via its own I gain via its own PID.

So for me, thinking about axis scales as "supporting" rather than "primary" might be the best way to think about this. Thinking about it in this way it sounds like the wiki is correct. It also means that the motor encoder is used to supply more accurate velocity and positional information "between the telephone poles" as you've said.

Before I implement this do you think the above makes sense?? Particularly the use of the backlash analogy and therefore the ability to use backlash to affect motor-encoder position whilst leaving the scale position unaffected to continue to refine axis position?

Again, thanks for all the input.

Nitram wrote:

Hi Chris.

So for me, thinking about axis scales as "supporting" rather than "primary" might be the best way to think about this. Thinking about it in this way it sounds like the wiki is correct. It also means that the motor encoder is used to supply more accurate velocity and positional information "between the telephone poles" as you've said.

Yes this seems a sensible way to look at it.
The wiki was written by the guy (Stuart) who did use this technique on a big cnc - so it's probably right.
There used to be a blog about it but it has since been taken down.

Chris M