Date: Sat, 18 Jun 2011 13:52:05 -0500
From: Jon Elson <[email protected]>
Reply-To: EMC developers <[email protected]>
To: EMC developers <[email protected]>
Subject: Re: [Emc-developers] CUI encoders
Kim Kirwan wrote:
Jon,
I am very glad that you are doing this, I have wanted to do it
myself for a long time. I have always felt that the CUI encoders,
while being admirably cheap, are not as good as an optical
encoder, but I have had no data to support my belief. Maybe you
are about to come up with some.
In the last picture you mentioned, yes, I do see the "lag" (again,
encoder in light-green, CUI in red) and also I see a "lead", where
it seems to realize that it's way behind and it starts to "hurry",
resulting in a steeper slope than the encoder, and an overshoot.
Yes, exactly. Not a position overshoot but a velocity overshoot.
Anyway, since a major
part of a PID control loop is to manage velocity, serious velocity
errors are going to
cause difficulty in closing the loop.
So, the acceleration lags, and then the velocity has to overshoot for
position to ever catch up.
If you look at the right side where it's fairly level, the CUI
oscillates a time or two. So overall it gives the appearance that
(at least in this case) its "estimator" is "overtuned". This is
not necessarily a criticism, because I'm sure it has to be tuned
for the "general case", or to fit in everywhere if possible.
The problem as I see it is that the CUIs are inferred measurement
devices, and so take some finagling to arrive at the result.
Whereas an encoder is strictly a measuring device, like the
barrel of a micrometer. You look, you get a measurement, and
that's it. Even a resolver is a little bit of an inferred
measurement, but I think there's a little less finagling with
a resolver than with the CUIs.
Well, it is pretty much an unavoidable part of using an interpolation
scheme to turn
a low-resolution sensor into a high-resolution measurement in the form
of a quadrature
encoder signal. Almost all the schemes I've seen used some kind of
velocity tracking
loop so the output pulses try to replicate the velocity of a real encoder.
On the other hand, some other systems like the Analog Devices 2S1200
chip for
resolvers seem to handle this without great delays. Of course, that
chip costs $28
or so.
I suspect that the CUI encoders would be very good for adding to
open-loop stepper systems for use as following-error monitors.
(Follow the cautions in the data sheets about mounting them too
close to strong magnets, like stepper motors!). That way, if there
are any problems with them, you can just loosen the following-
error limits a smidgen, and everything will work fine. The tuning
of the machine would not be dependent upon them.
I'd like to see you do a graph of static error vs. rotation, using
some kind of precision degree wheel. In format, something like the
monotonicity error of an A/D or D/A converter. If CUI does not
have a graph like that, one is needed. If they do, you'd be
keeping them honest.
Carry on, Jon, and let us know what you find, please write it up
when you've got some good results there. It should make for a very
interesting report.
Well, as Jan de Kruyf mentioned earlier, there are some settings that
can affect the problem.
I removed this smoothing filter jumper (I'm guessing that's what "SF"
stands for) but it made
very little difference. I reduced the encoder resolution from 1000
cycler/rev to 512 and that
made a definite improvement. But, cutting encoder resolution is not a
desirable thing to do,
and it only helps but doesn't come anywhere near "curing" the problem.
I tried to decipher the info in the CUI document that Jan quoted from,
but they don't define
units in their equations. Attempting to deduce what the heck they are
saying, maybe this
"But it does cause some lag in position, proportional to acceleration
and T^2. (with T= 100, 50, 25, 13 µs at resolution settings D2, D1 = 11,
10, 01, 00, respectively)" means that if T=100, T^2 means a delay of
10,000 us.
That would certainly explain the problem!
Pretty annoying! I was just about to order some of these encoders for
installation in some really
NICE Pacific Scientific motors I got, but clearly they won't do. I'll
have to spend a lot more
to get Renco encoders, I think. I have Keling motors with encoders
listed on my web store,
but I will have to come up with something different to put on them.
Jon
