View Single Post
  #32   Spotlight this post!  
Unread 25-08-2013, 15:27
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,083
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: Encoder problems

Quote:
Originally Posted by Peleg2230 View Post
I'll try that but aren't your calculation showed that it is over the FPGA limits?
I'm not sure where you got that from. Here is the calculation I posted (with bold added for emphasis):
A US Digital 360 CPR E4P encoder outputs 2*360 = 720 total edges (360 rising + 360 falling) per rotation on each channel. So for each channel, an edge transition occurs every 1/720 of a rotation, if the symmetry is perfect (see attached excerpt from datasheet).

When using just a single channel of this encoder as a counter, and assuming perfect phase symmetry, speeds greater than (1/720)/(6.525e-6) = 212.9 rotations/sec = 12,771 RPM would cause a problem for the FPGA1.

But the symmetry is not perfect. According to the datasheet, the symmetry across the range of recommended mounting tolerance can be off by as much as 75 electrical degrees. So instead of being (1/720) of a rotation apart, some of the edges in a channel could be as close as (1/720)*((180-75)/180) of a rotation apart. So speeds greater than (1/720)*((180-75)/180)/(6.525e-6) = 124.2 rotations/sec = 7,450 RPM would cause a problem for the FPGA.

Reply With Quote