I have written a VHDL program(look post script)to count pulses from quadrature encoder. Basically i read both the clocks(here QEP0 and QEP1) and count on two different conditions based on if the motor is going forward or backward. In the previous case count is increased and the latter case the count is decreased. I store the count in a S/W accessible slave register generated when i use "Create Peripheral wizard" (EDK) (slv_reg0)
Usually everything works fine, however at times (roughly 1 out of
15-20) what happens is that when i keep reading from that register continously(for (i=0;i
When this occurs, take note of the binary values - that can indicate the type of error more clearly.
Some notes on Quad counting, which is not trivial to do correctly :
** Caution is needed when crossing clock domains. You have to watch for aperture effects, and metastability.
** Many solutions are possible, up to a max of one-count per edge. ( You seem to be doing less than that ? )
In the simplest form, one phase can be CLK and the other UP/DN
** If the whole counter is clocked in the QUAD domain, then reading that counter will be difficult : ie it may change during read. That said, it should return to the expected value, with such jumps being rare. - your error above seems to 'stick' in the example given ? If so, that indicates a HW counter problem, not a change-during-read problem. A ~5% failure rate is quite high. ie not a subtle effect
** You should include an edge-chatter test case, to ensure the counter does not creep on "edge fur" effects : ie many changes on one phase only.
** Also check there are no edge oscillation/slow edges effects, in your sensors.
Direct counting, which you seem to be doing, will have very high bandwidths - and slow edges like from optocouplers may be too slow for the FPGA. This can have the exact effect you describe - sudden burst advances.
A common design is to use Schmitt buffers, with preceeding RC filters, to put a ceiling on the possible edge rates, and speed up the edges from what are commonly opto sensors. This gives better behaved Quad encoders.
If I understand you right, you would be better served with a very simple design that I published a while ago. Sorry forthe lengthy posting.
Quadrature Decoding
Any forward/backward mechanical motion is best converted into electrical signals by a quadrature encoder generating two overlapping output signals A and B. These two signals can then easily be decoded into two more practical signals: a count Clock, and a Direction signal.
The simple decoder described below is inherently insensitive to contact bounce, and operates equally well with active High or active Low inputs. It uses a single slice (two LUTs and two flip-flops). The clock frequency should be higher than 1 MHz to operate reliably, even when the mechanical action is very fast, perhaps spring-loaded.
The two 3-input LUTs are both driven by the quadrature signals A and B, and each LUT also uses the Q of its associated flip-flop as a third input. The two outputs Q1 and Q2 are interchangeable, either can be the Clock or the Direction signal. In a synchronous system it is good practice to digitally differentiate the Clock output in an additional flip-flop, Q3 and use it as the Clock Enable input to the counter that keeps track of the mechanical movement.
Q1 is set when A is High, and B is Low, Q1 is reset when A is Low and B is High.
Q2 is set when A is High and B is High, Q2 is reset when A is Low and B is Low.
Under all other conditions, Q1 and Q2 maintain their state. Contact bounce on A and B must not exceed the High or the Low times of these signals. The decoder maintains a proper count value even when the mechanical motion is erratic, changing direction in the worst possible way. No need for any analog filtering or de-bouncing.
What happens to Q1/Q2 with respect to the third input to the LUTs (the feedback Q signals)? If under other conditions, Q1/Q2 maintain their state, what is the point in feeding back the Qs? Sorry if I am missing something obvious here.
Also, what do you thinking about this Quad Decode circuit:
I would call this a debouncer, rather than a decoder. It does work well at removing edge chatter and noise, but does not give full decode precision.
The better (most resolution) quadrature decoders/counters can generate one COUNT per EDGE. ( 4 counts per quad cycle )
Systems that take the A/B (or I/Q these days...) and use as CLK/DIRN are simple, but loose potential resolution.
Most mechanical sensor systems pay for better resolution.
It is also a good idea to drive only ONE register .D ( or J.K) across a clock domain, so often these Quad encoders have IP sample registers, or in some cases 2,3 registers for majority vote noise filtering [ see Quad counter chips from hp ]
The two bits of the quadrature encoder are like a 2-bit Gray counter.
Consider what it might take to turn these 2 bits into an n-bit Gray counter, then decode the gray to binary when it's in the clock domain of interest. If done properly, chatter on one of the two quadrature inputs will not result in anything except chatter on one bit of the Gray value.
Thank you very much for the reply. In case i use D as Clock and E as direction (say i convert D and E according to your set and reset) the program might look like the code below. what clock (??? in the program below) shud i use for trigger (the processor/bus clk?)
------------------------------------------------------ E program will look like::: ============================ if(???'high and ???= '1') then
I assume you have a fast clock available so instead of treating QEP0 and QEP1 as clocks treat them as data; Sample the two pins with a couple of flipflops and look at the state. There only four states and for each state theres only two legal next states, forward/backward.You could even add an error flag that is set if there's an illegal transition.
That way your counter and everything else is synchronous with you system
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.