Jon Elson wrote: > So, this just records the time of the LAST count, not ALL counts since > you read the encoder status last?
Yes. >> My approach to the "ideal encoder counter" is to allocate the register >> space between counts and timestamp. Unfortunately there is no single >> split that is ideal for all systems. > Hmm, an interesting way to do things. I'm not sure I'd do it this way, > although that would keep from increasing the I/O traffic. But, just > adding 4 more 16-bit reads to the traffic might not be such a big deal. > Then, with a little bit of code, old boards could work with the new > driver, and new boards could work with an old driver. In either > cross-version, the new timestamp would not be operative, but wouldn't > interfere with other functionality. I don't know if I have enough time > before the fest to try to implement the timestamp in the FPGA, but it > doesn't sound real tough. Be careful here. You must ensure that the count and the timestamp are from the SAME encoder edge. That's why I like stuffing both values into the same wide register. There are certainly other ways to ensure the same result. You already deal with that problem when reading your 24 bit count registers over the 8 bit EPP bus, now you have 40 bits to deal with. > Add a global counter for all 4 axes, and a > register that latches the counter at every transition. Is that all > that's required, catching the timestamp at the last encoder count? Yes. Regards, John Kasunich ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
