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. 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. 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. Kim On 06/17/2011 10:17 PM, Jon Elson wrote: > OK, I think I get it, and it is about what I expected from an encoder > with interpolation. > It isn't exactly a velocity lag, it is an ACELLERATION lag! I did > another plot at > expanded time resolution, http://pico-systems.com/images/vel.png > and it looks like there is a real lag in responding to changes in velocity. > > Does anybody agree that is what I'm seeing here? > > Thanks, > > 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
