John Kasunich wrote: > Jon Elson wrote: > >> Certainly does look nice, but you can't do this with a standard encoder >> counter. >> > > Define "standard counter". A position counter for a quadrature encoder. When asked, it reports position, and that is IT. No velocity of any sort. > The whole idea behind FPGA based hardware is > that you can do creative things that make your product better than the > next one. Count+Timestamp counting of encoders isn't new - a former > employer of mine was doing it in the early 1980's, and maybe before > that. IMO, count+timestamp is (or should be) the "standard" for > hardware encoder counting. > OK, I see the advantages. But, it requires changing things in the field. (Maybe not having downloadable firmware was a mistake, but these products started life in 2000.) Also, the communication overhead is already pretty high, I don't want to slow things down any more with additional registers to read. >> Wait a minute, your scope trace is 100 ms/div, or 100 default >> servo cycles per div. So, I'm not sure this really does much different >> than a hardware encoder counter. >> > > That image isn't about hardware counting. Hardware counting enables > high count rates, which in turn lets you use high PPR encoders to reduce > quantization noise. That scope trace shows a dramatic reduction in > noise with a LOW PPR encoder. > OK, I think I did see the coarseness of the counts, there. > >> If it does, I can't see it at this >> time scale. >> > > You can't see the difference between the red and blue traces?! > I'm used to seeing something that looks like the red trace, so maybe I failed to look at the difference in information content there. Yes, there IS a difference in the traces. > >> Anyway, due to the limitations of communication rates to >> external devices, I don't see a real easy way to improve upon such >> hardware as I sell. >> > > Agreed - that is why I much prefer PCI attaached devices to EPP attached > devices. > And, apparently others do, too. I am mostly out of business here, maybe that is the reason. Perhaps an ethernet interface would revive things.
> > I don't know what a velocity counter is. A timestamp register DOES > provide more info, regardless of how often you read it. > > So, this just records the time of the LAST count, not ALL counts since you read the encoder status last? > 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. 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? Lets see, at 1 KHz, and 10 MHz timestamp clock, that's 10,000 counts per sampling interval, so 16 bits should be fine. It will roll over every 6.5 samples. Using a PCI parallel port card can speed up the I/O to my boards a good deal, so these additional bytes might be no slower than using the on-mobo par port with the original encoder function. Jon ------------------------------------------------------------------------------ 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
