LabVIEW
Detect rotation direction from 2 pulse train
Hi tokar,
@tokar wrote:
Somehow i need to decide which one of the pulse train that goes high before the other, and also the opposite for the other direction.
If someone can provide some example code it would be much appreciated.
You just need to keep track of the current and previous state of both pulse trains, so all you need is a shift register!
Turning "right" will go FF, TF, TT, FT (typically for A rising before B), the other direction will go FF, FT, TT, TF…
Hi tokar,
@tokar wrote:
why do i need shift register?
Because "movement" is defined as "difference between previous and current position"!
And encoders give you the current position…
@tokar wrote:
Can you provide a short labview code example?
It's just a comparison between previous and current state. (And state is defined as combination of A and B value.)
Some practical questions first:
What is the frequency of those pulse trains?
What is the electrical specification for those digital signals?
What is the hardware you intend to use to read those digital signals?
These answers will determine very much what route you will actually have to go. If your signal is anywhere in the 100 Hz or higher ranges, a simple digital input with software detection is going to be bound to miss level changes and cause your detection to be inaccurate.
If you have a DAQ card with a general purpose counter you can let that counter do pretty much all the work for you even for very high pulse frequencies by using the Edge Counting mode with the optional Direction input on the according Aux input. It's basically a bi-phase signal counting operation.
If you have a (c/sb)RIO FPGA hardware you can program everything even for very high pulse rates in the FPGA fabric of your device.
Since you seem to have a cRIO-9047 and a 9423 you should be able to go up to several 100kHz pulse input rate.
There are various examples that come with LabVIEW about implementing a bi-phase counter on FPGA with simple digital IOs.
Yes it involves shift registers to be able to compare the previous digital state of both IOs with the current one in order to detect the logic level changes, aka slopes of your signal. The most simple implementation is nothing more than this:
However things can get a lot more complicated in real world. Input signal debouncing might be a requirement if your signal is not a nicely defined pulse.
Also you might want to have some additional detection about if the actual source is moving at all (meaning causing a minimum amount of pulses per second, millisecond or whatever). And if you are at it you may also want to maintain a count value.
After having added all this, your solution will have led you into the abyss of digital circuit design for sure. 😁
