View Single Post
  #22   Spotlight this post!  
Unread 17-02-2013, 16:28
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,128
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Magnetic encoders? Anybody else having trouble?

Quote:
Originally Posted by Bryscus View Post
All this was possible only at slow speed though.
I'm guessing you were using the Encoder class and instantiating 4X decoding?

That's your problem. That's overkill for a shooter wheel speed sensor.

If instead you connected only one channel of the sensor, and made a Counter object that counts only the rising edge of that channel (with no direction control), the FPGA is capable of keeping up with 1024 rising edges per rev at well over 5,000 RPM (perhaps as high as 8,000 RPM).

Please note though: for high-CPR counters at high RPM, if you use the getPeriod() method, you must set FPGA samples much higher than the default 1. For your app, I'd use 127 (the maximum), which is about 1/8 of a revolution. Setting the size of the FPGA sample buffer is easy in LabVIEW. In C++ or Java, it requires a small edit to the WPILib code.

Or, at those high speeds with a high CPR (like 1024), you could get the counts (instead of the period), and divide by elapsed time. To get good results with this method, you need a good value of elapsed time. In C++ you can use the PPCtimer (low overhead and microsecond resolution). In LabVIEW you can use a Timed Structure and just divide by the period.



Last edited by Ether : 17-02-2013 at 17:36. Reason: added note