Direction detection in Quadrature Decoder

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Direction detection in Quadrature Decoder

9,010 Views
ni
Contributor I
We are programing Freescale 56F8357 DSP in Metrowerks CodeWarrior IDE version 5.6.1 1658 environment.
 
We have a problem using Quadrature Decoder. We have an encoder that gives us two signals with 90º phase difference.

We need to obtain the direction of spin given by the encoder. For that goal, we have readen in "MC56F8300 Peripheral User Manual Rev 4.0" Page 12-5 that: "The direction of the count is determined by direction signal". But how could us obtain this direction? it appears in a register? or we have to deduce from "POSD" register? Does this register give negative values if the encoder gives back-direction values? How could us proceed?
 
Thank you very much,
 
Ni
Labels (1)
0 Kudos
Reply
6 Replies

1,874 Views
rocco
Senior Contributor II
Hi, NI:

Actually, the 56F8357 is a 16-bit device. ;o)

Unfortunately, there is no direction status bit available, though there should be, since there is one internally.

The easiest way to determine the direction is to read the "Position Difference Counter Register" and test its sign. Its sign bit is the only direction bit this device offers. It will not give you an instantaneous direction (the current direction at this instant in time), but will give you the aggregate direction since the previous read of the "Position Difference Counter Register". In other words, if the direction changed, you would not know that. You would only know which direction the encoder moved the most since the previous read.

The only way to really catch the 'current' direction is to sample the "Position Difference Counter Register" often. Even then, it's an aggregate, but over a smaller time sample.

Personally, I found the quadrature decoder in the 56F series rather lame. It gives you a lot of features that you can easily do in firmware, but is light on features that cannot easily be done in firmware, like a "direction changed" interrupt.
0 Kudos
Reply

1,874 Views
imajeff
Contributor III
Glad you got it figured out. Last night I broke down and read Ch.12 in
MC56F8300UM.pdf...

I think that the Position Difference Counter is a better way to detect direction than to have a flag that only indicates the direction of the very last "tick" direction.

That is because this is a very responsive decoder, and the nature of the quadrature decoder is that it detects discrete, not continuous motion. In other words, each time you read the state it can only give you an instantaneous position. Whether it is at that time moving in any direction is not known. Further, because of the fast response, it might detect _one_ negative tick in the midst positive 1000 ticks per second. If you just happened to read an instantaneous flag at that moment, you would have thought it was going in the wrong direction. So you need to really see a sum of how far it has moved since your last check. Hence, the "Position Difference Counter". It doesn't mean you don't have a flag. The sign bit IS the flag. Just test the one bit as a flag if you like. If it has gone more '+' then the bit will be '0'. If it has gone more '-' since last read then the bit will be '1'. Note you might want to read the "Position" reg first and test this flag in the latches. I don't know if the Difference reg clears if you didn't read the Position also.

Hey, I don't try to make things hard for people, contrary to what my coworker says. This has been my long-time speech: Read it on your own; Think of it on your own; liberate yourself from the chains of OPK (other people's knowledge). It empowers you. I'm just saying that the answer was in description of registers afterall. I still hope you get some insight from the above paragraph also. I believe in learning from every experience.


P.S. Yes, it is 16bit. I had forgot because it is not in the same catagory as the (misnamed) "HCS12", so I apologize for the rant here. Unfortunately the problem still does exist on this forum :-/ Perhaps they hope to get the rest of us interrested in the "migration path" to higher end products? It's not working as long as I see so many questions and so few answers. Seems easier just to stick with my (relatively) simple 9S12.
0 Kudos
Reply

1,874 Views
ni
Contributor I
Thank you very very much, Rocco.
0 Kudos
Reply

1,874 Views
ni
Contributor I

Thank youfor your answer, but  that has not solved my problem. I understand how encoder runs, and how it give us two signals out of phase that determine the velocity and the direction.

But our goal and problem is to detect using Freescale's 56F8357 registers and using CodeWarrior, the direction of turns each 100ms. We want to read the difference of edges that has been between each 100ms and with the result, to obtain the velocity and the directions of turning machine.

Thanks again!

0 Kudos
Reply

1,874 Views
Fabrico
Contributor I
Dear Ni,
 
Usually, quadrature encoders are interface with a D Flip Flip, where one signal feeds the D input of a 74LS74 and the other signal feeds the CLK input.
 
The trick is to sample one signal as the other changes state, a rising edge for example. This way, the Q output can be read as the direction, while your actual CLK signal can be thought of as the pulse/speed input.
 
In software, you have to check the new state of a signal against the old state, if it changed than, sample the other signal and voila!
 
Fabrico

Message Edited by Fabrico on 2006-11-2101:57 AM

0 Kudos
Reply

1,874 Views
imajeff
Contributor III
Uh, that shouldn't be hard. In fact if you just draw a trace of the two signals by hand while it turns, you should see it easily.

I have two square waves... A and B. I notice when turning clockwise, B lags A (this could be opposite for you, but what ever it is it will not change unless you redesign it).

It is really as simple as that.

A ___--__--__--___ CW
B ____--__--__--__


A ___--__--__--___ CCW
B __--__--__--____

Message Edited by imajeff on 03-23-200607:34 AM

0 Kudos
Reply