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 ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
