Chris Radek wrote: > On Thu, Apr 28, 2011 at 10:39:45AM -0500, Jon Elson wrote: > > >> So, the readout takes almost a ms. Now, a lot of people would want to >> convert this to quadrature. >> One problem shows up immediately, they have 65K and 1 million count/rev >> versions. >> > > Converting it to intermediate quadrature seems like a losing > proposition. Wouldn't you want the hardware to receive this serial > and then present it in HAL directly? Yes, I'm sure you are right. Maybe this is a real "edge" for me! To use these motors with a typical CNC control, you have no choice but to convert to quadrature, and I think we agree this has a big downside. I think I can re-code the encoder board for my PPMC to read the format. I'd need to write a new module to the ppmc driver to accept both position and commutation data, but that won't be a big deal once I decode the data format. > By the time you've received all > the serial you're already running behind - and now you have to > generate a whole mess (arbitrary number?) of quadrature edges at > breakneck speed (but slow enough for regular encoder hardware to count > them correctly). I can't see how you can even be sure of being able > to burst enough edges in another whole servo cycle. > This takes a lot of calculating to make sure the worst-case number of encoder counts can be sent within the available time. At least with my PPMC, I can trigger the encoder to send data synchronized with the EMC servo cycle. What I imagined was to send the serial data during one servo cycle, then send the quadrature counts during the next. This would avoid having the quadrature pulses split across servo cycles, which would cause a dither effect. > If nothing else this will fool a timestamp based sub-period velocity > estimate algorithm into giving you something crazy, which defeats > our new pid features. > Yes, bursting counts would ruin the timestamp velocity estimation. The PPMC doesn't have this feature yet, only the UPC. I will have to work on that, too. > It seems like a custom firmware to read the protocol is the way to go > here, not custom hardware that tries to convert to quadrature. > Yes, I definitely agree. But, this also wrecks the velocity estimation, you only get about one update per ms if the numbers I've been given are right. From the data I have, it works just like a UART, only the data word is 77 bits long. I'm a little worried about staying in sync for 77 asynchronous bits. But, I guess crystal clocks are accurate enough for that.
Jon ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
