Steve Blackmore wrote: > Here's a halscope of the encoder pulses > > http://imagebin.ca/view/1SkQrEB.html > > what you can determine from the pulse widths/spikes is inconclusive. > OK, now that we have the A and B signals there, we can determine the raw count rate. It is between about 25 quadrature counts per 50 ms division in the photo. So, that is about one count every other servo period. So, the UNSCALED delta is 0.5, a condition for maximum jitter in the perceived count rate. So, the unscaled delta should be zero, one or on very rare occasions two. It should never be more than two, and that ought to be a rare event. So, mostly it should just be zero and one. When scaled, that should STILL come out to a narrow band of just two discrete values, with the most rare ocurrence of something beyond those two. Well, your encoder.0.velocity trace looks NOTHING like that!
Something is very wrong. I am not familiar enough with the software encoder component to really know what is going on, but the velocity estimation routine seems to have a problem under your specific settings and circumstances. I don't even know if the velocity output is even used by the threading function, I tend to doubt it as my PPMC encoder driver does not produce a scaled velocity output, and we can do threading fine without it. Your position trace in your earlier photos didn't appear to have anomalous jumps, but the scale probably was too coarse to see them (10 units/div, as I recall). It might be useful to set the X axis very close to zero and record near there, so the position display can be scaled up (or use the HalScope's offset feature so you can scale it up) to see if these jumps in velocity are also reflected in the position count. If so, then there is some real anomaly in the way encoder signals are counted by the encoders.capture-position function. It sure seems like the sampling interval is not constant, or something like that. If there are jumps and flat spots in the position count as well when it is blown up, then that has to be your problem. If there are NO jumps in position, then it must be that this is not the problem, but certainly an anomaly in the velocity estimation that should be investigated. You could also turn the spindle a bunch of turns one way, then back the same number of turns the other way and index to a precise location. Maybe have a bar pinched in the chuck and slide a tool holder block it at a repeatable position. If something is going funny in the encoder counting process, it may also be losing encoder counts, and so the encoder.0.position would not return to the same number. Jon ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
