High Speed Edge Capture On Multiple Channels

[MRSnyder]

Okay so this is my first post here and I've tried to do all the research I could before starting a new post, but I'm coming up broke on solutions to this. So here is what we are trying to do:

I work for a company that makes Encoders and we are trying to develope and End Of the Line (EOL) Encoder Tester so that we can qualify the units before we ship them out. I've used the PCI-6602 board before for Quaderature Decoding and it works wonderfully but for the specific qualities we are testing here I can't seem to make the board work for me. What we are trying to do is get the exact time each channel A, B, Z, !A, !B, !Z change state so that they can all be correlated together. The reason that we are doing this is that we need to make sure that A actually leads B by 90 degrees, Z lies within B, and so on and so forth. I can also use the information to then calculate Duty Cycle, Frequency, and all the other encoder properties. I know there are functions for Semi-Period measurement, which gives me time high and time low, but without a reference time that correlates counter 1 to counter 2 for channels A and B it doesn't allow me to compare them. Therein lies my main problem. In terms of sampling frequency because I know that an important spec, I'd like to maintain the 20MHz rate if not go even faster because the faster I can test the more money we save in automating the process. If anyone has any recommendations as far as other hardware, or a new way to use the 6602 that I just haven't seen yet please let me know, any help is much appreciated and welcome!

[James_M. · Accepted solution]

It should definitely be possible to measure time intervals between the edges on your A, B and Z encoder channels with the 6602.  In Labview, the key DAQmx function to use would be the Counter Input - Two Edge Separation task, where you would be measuring the number of clock cycles between rising (or falling) edges on two different lines. Here's a great description of the concept:

http://digital.ni.com/public.nsf/websearch/4F5002129C5E720D86256AC30079A391?OpenDocument

In such a way, a single counter would be used to get the time interval between edges for one pair of inputs (i.e. between A and B); a separate counter could be used for a different pair (i.e. B and Z).  The following link contains more specifics on configuring such a task, as well as example code:

http://digital.ni.com/public.nsf/allkb/90B79A96D2E81C2986256B6700551DEE

Hope that's what you're looking for!

James M.

Applications Engineer

National Instruments

[MRSnyder]

This ended up working exactly how I wanted it too, however I ended up running into a size limitation. I have some applications with more than 20 different lines that I need to have all referenced back against the same time signal (all starting at the same time) and while this worked in the small scale, for the overall scope of the project I'm going to have to proceed down a different path. Thanks!

[James_M.]

I'm glad to hear the two-edge separation technique worked for timing the encoder channel transitions.  

With regards to expanding the technique to analyze more lines, would it be feasible for you to use additional PCI-6602 cards? If so, you could connect multiple 6602s through a RTSI cable, and export a common trigger to start the edge separation tasks on all 20 lines simultaneously across the 6602 devices.

Let me know if you want to discuss other possible ideas. Best of luck with your application!

James M.  |  Applications Engineer  |  National Instruments

[John_P1]

Hi MRSnyder,

You can timestamp rising and/or falling edges on up to 32 lines on some X Series devices (those that have 32 lines on port 0).  What I would do is configure a change detection digital input task sampled off of the desired lines.  This will generate a clock edge on every state transition that you have selected.  You can use this clock to sample one of the X Series counters to get a timestamp of each event--if you are counting the 100 MHz timebase with the counter the resolution of your timestamp would be as low as 10 ns.

If you know the order of the events ahead of time, then the array of timestamps would be enough to determine exactly what happened and when.  If you don't know the order of events, then you would also have to read back the array of digital data from your DI change detection task so you could correlate the changes in state to the timestamps.

Best Regards,