Wrong results using quadrature encoders with NI DAQCard-6036E

Question

     Hello,
I'm experiencing some troubles using two quadrature encoders with a NI multifunction I/O.
The encoders are Micro-Epsilon WDS-7500-P115-CR-TTL. They are incremental encoders in TTL logic. They are connected to a HP laptop running Windows XP Professional. The connection is via the multifunction I/O NI DAQCard-6036E. Each encoder is connected to the DAQ board with four wires: +5V, DGND, track A, track B. I used the system in my office for a while and everything was fine. Then I moved it in another place and now it shows a fuzzy behaviour.
I made the following tests:
Test 1) I connect track A&B to analog inputs on the DAQ card. Then I use SignalExpress v2.5 to perform a DAQmx analog input acquisition. The waveforms I get are exactly as expected.
Test 2) I connect track A to the counter source and I leave track B disconnected. I use SignalExpress v2.5 to set a DAQmx edge counter, with the "Count up" option enabled. Also this test is fine. When I pull the encoder cable I get +N counts and when I release the cable it goes back to zero position, giving other +N counts.
Test 3) I connect track A to the counter source and track B to P0.6 (or P0.7 for the second encoder), which is the pin used to control the count direction. I use SignalExpress v2.5 to set a DAQmx edge counter, with "Count up". In this way the DAQ should ignore track B and count always up. Actually it does, but the count rate in one direction is double with respect to the count rate in the other direction. This means that when I pull the encoder cable I get +N counts and when I put it back to initial position I get other +2N counts. In this way the counter indicates +3N at the end, while it should be +2N.
Test 4) I connect track A to the counter source and track B to P0.6 (or P0.7 for the second encoder). I use SignalExpress v2.5 to set an "Externally controlled" DAQmx edge counter. Now I get +N counts when I pull the encoder and -2N counts when I put it back to zero position. In this way the counter indicates -N  at the end, while it should be zero.
Test 5) I repeat test 4 using LabWindows/CVI v8.1 and I get the same result.
Test 6) I swap lines A&B. Now track B is connected to the counter source and track A goes to P0.6 (or P0.7 for the second encoder). Using SignalExpress to perform an "External controlled" count, I get +2N counts when I pull the encoder and -N counts when I put it back to zero. So, at the end the counter indicates +N, but it should be zero.
Do you have any idea on how to solve the problem? Thank you very much in advance.

Answer 1

A few things:
1. I'm not from NI and won't try to speak for them.  But I don't believe these forums are meant as a primary means of support, probably not an *official* means of support at all.  Most of the folks here (like me) are NI's more-or-less satisfied customers, not employees.   If you buy a service contract, you can get instant phone support.  If you rely on free support from the forums, I think you'll get good help most of the time, but there's just no guarantee. 
2. "I just got a [email] reply from MicroEpsilon.  The encoders work fine."   Um.  Based on what, exactly?  Of *course* they will expect their own stuff to be just fine, and in fact I very much suspect they're right.  But NI will expect their board to be just fine, and I expect they're right too.  Or at least it was fine *before* you hooked things up.  Leading us to #3.
3.  Part of the app note on Quad Encoders on E-series boards warns against connecting differential encoder outputs directly to your board.  I think it mentions that a 24V differential (for example) can damage the board.  But even a low-voltage differential signal isn't electrically *compatible* with your counter inputs.  Your first posting claimed that the encoders produced TTL.  Your June 30 post referred to inverted A and B signals for rejecting common mode noise over long transmission lines.  These are classic code words that scream "differential output", *not* TTL.  So now we can start addressing some specific tech issues.
4. Your E-series board is not inherently capable of handling true quadrature, as the app note says.  (The newer M-series multifunction boards *do* have the capability.)  You can get kinda sorta close, but you'll be at risk of count errors due to direction changes or during vibrations when otherwise stationary.
5. You will also need some type of differential to TTL conversion on your (A, /A) and (B, /B) pairs.
6. You will need a common "ground" reference for all your digital signals (probably not a true earth ground).  So the ground for your conversion circuit and its TTL outputs must be tied to your DAQ board digital ground.  Also the return terminal from any related external power supply.  Sounds like failure to do this had been an issue with a past implementation of yours so perhaps it's an additional factor at play this time too?
7.  What are you trying to measure?  For what purpose?  What decision is made from the data?  How much do you care about its accuracy?  These are leading questions, but I'm suggesting that meeting schedule with an unreliable app that produces untrustworthy data just might not be the best goal to strive for right now.  If you care to maintain accurate position count despite direction changes or vibrations, you *need* something more than your E-series board.  If you want reliable edge counting operation with *any* DAQ board, you *need* electrically compatible signals.
-Kevin P.