Wrong results using quadrature encoders with NI DAQCard-6036E

[User56]

     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.

[Logan_081]

Hello User56,

I suggest you to first evaluate these documents:

https://www.ni.com/en/support/documentation/supplemental/21/using-quadrature-encoders-with-e-series-...

And if needed consider to check if you correctly performed the wiring connections, this could provide for some additional advices.

https://www.ni.com/en/shop/data-acquisition/measurement-fundamentals/field-wiring-and-noise-consider...

Let me know about your system.

Regards

[User56]

     Dear Logan_081,

thanks for your reply. Unfortunately, the problem is still there.

I already read https://www.ni.com/en/support/documentation/supplemental/21/using-quadrature-encoders-with-e-series-... about quadrature encoders with NI multifunction I/O's. But what I actually get is not a problem linked to vibrations, like the ones described in the document. I re-checked the wiring as you suggested and it's ok. Also https://www.ni.com/en/shop/data-acquisition/measurement-fundamentals/field-wiring-and-noise-consider... was not helpful.

In the past I already experienced a problem like the one I have now. At that time I was using quadrature encoders (the same model I'm using now) supplied with an external LV PS. The only way to solve the problem was to supply the encoders with the GND and +5V provided by the multifunction I/O. Now I am using exactly these two pins, but the counter shows the strange bahaviour I explained you in my last post.

     Cheers

     Marco

[Logan_081]

Hello Marco,

First of all, we have to be sure that your encoders are correctly configured. Did you try to contact Micro Epsilon? Maybe they could give you some advice regards to correctly configure your system. Then after verified this, we can perform the next step in evaluating your problem.

Cheers 

[User56]

     Dear Matteo,

I just got a reply for Micro-Epsilon. The encoders work fine, so the problem must be linked to the DAQ.

1 - Is the DAQ card already set in such a way to correctly recognize encoder signals as square waves with a quarter-of-period pulse separation? If not, what functions should I call in LabWindows/CVI v8.1 to configure such a parameter (or to check the actual parameter status)?

2 - Each encoder provides 4 output lines: track A, track A inverted, track B, track B inverted. The inverted lines can be used in long transmission lines to suppress common mode noises. Is there any way to exploit this feature with my multifunction I/O NI DAQCard-6036E? Or it is necessary to combine the two signals before sending them to the card?

     Cheers

     Marco

[User56]

I would like to express my bewilderment for the problem I had and I still have.

It has been more than one month from my first post. From my side, I didn't put so much pressure on the NI technical support bacause I was busy with lots of other stuff, but also from your side I got no useful advice. Now the time to have everything working properly is getting closer. The setup has to be ready in one week. I will appreciate any suggestion from you.

Thanks a lot.

Marco

[Kevin_Price]

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.

[User56]

     Dear Kevin,

First of all thanks a lot for your reply.

I'll answer your points:

1 - Ok, I'll try to call NI.

2 - The answer I got from Micro-Epsilon was not a mail. They called me and we made a few test while they were on the phone. Basically we checked that the signals given by the encoders are as expected. But there is another point that makes me think that the encoders are fine. In fact, I have 4 encoders and I get the same problem with all of them. I don't believe that all of them are defective in the same way.

3 - Well, you're right when you say that the encoder provides differential outputs. There are 4 outputs: A, /A, B, /B. Each of these lines is in TTL logic. At present I'm using only track A and B and I do not connect the inverted lines at all. Micro-Epsilon told me that using this configuration is fine. Do you think it can give troubles?

4 - Yes, I'm aware of that. But as I said in one of my previous posts, what I get isn't a problem of precision when I change direction. It is not linked to vibrations in stationary position. What I get is a count rate which is double in one direction with respect to the other.

5 - I think that each track is a TTL with respect to DGND. If so I can use track A and B and leave inverted ones disconnected.

6 - Yes, sorry. I didn't explain very well what happened with the external PS. For sure it was vincolated to the DGND of the DAQ board.

7 - I need to measure the movement of a system with respect to a reference point. The system can move for 5 meters and I need a precision of about 5 - 10 mm after the full path, without changes in direction. I know that I can solve the "vibrations" problem with a M-series device or with other methods, for example a encoder signal conditioner placed before my E-series DAQ. The point is that I don't really need extreme precision and at present I cannot afford further expenses.

Thank you again for your help.

     Cheers

     Marco

[Kevin_Price]

My only past experience with a similar asymmetric counting behavior was tracked down to the following 2 issues:

A. Poor ground referencing.  The screw terminal was clamping the power supply's ground reference on the insulation rather than the conductor.

B. The power supply had been set at too low a current limit.  With the system running and the current limit kicking in, the voltage dropped down to less than 4 volts. 

We didn't observe consistent differences when counting in opposite directions, but we *did* see a tendency for the count to drift in a specific direction.  So it's kinda sorta similar.  So my best guess at this point is to *really* check out your digital ground consistency among DAQ board, power supply, encoder, whatever else.  Take ohm measurements with the DAQ cable disconnected from the board and with the power supply off to make sure you have good ground contact.  (Sometimes a voltage measurement may "happen" to read 0V potential even if there isn't truly a good grounding connection.)

There's still a bit of uncertainty over whether A and /A are TTL inverses of each other or whether they are a differential pair.  There are a variety of types of differential, some of which operate between 0V and 5V and are said to be TTL-compatible.  I've had past experience where I wired that kind directly into counter inputs and they seemed to work fine.  It got me through some quick-and-dirty testing, but I wouldn't advise relying on it for the long haul. 

I was just in a very recent thread where the poster used a neat technique that *appears* to solve the E-series problem of miscounts during direction change / vibration.  He hooked up A & B for the directional event counting on counter 0 and hooked up /A and /B the same way on counter 1.  Then he summed the count values of the two counters in software.  The result *appears* to be a good 2X quadrature reading.  That means you increment by 2 counts per full cycle of quadrature.  I sketched up a little timing diagram for myself, and am tentatively convinced that his scheme handles direction changes and vibration.

Hopefully, something here will help.

-Kevin P.

[Steven A.]

Hi, it's been a year or so that I'm working with labview real time and this forum has been very helpfull

I have the same problem as Marco: my quad-encoder with TTL signals, mounted on a brushless motor, is read by a PCI-6024E (E-series) and the counter doubles the counts in a direction while the other is ok.

Was this problem solved in some way? is there a way to read this encoder?

I also have an M-series and there's no problem with the same encoder, so i'd say, is there something wrong in the VI? I'm using this:

http://zone.ni.com/devzone/cda/epd/p/id/1427 

I put channel A in the source (pin37 - PFI8) and channel B in the up/down (pin 16 - P0.6); in a DGND i put the reference ground.

Their specs are TTL with 20mA per channel.

I checked a hundred times if everything was ok with screws and wires.

I even uses 2 analog inputs to read this channel and at low speed of motor (as the DAQ can reach 1khz maximum) and i count the rising edges just like the NI vi should do. My counter is right, the NI counter is wrong, as it doubles the counts.

So the wiring is ok, any one as an idea of where there could be something to fix?

Then, how can i use the A\ and B\ to create a sort of X2? I can't see the VI linked in this thread. Labview says that something is missing...

Thanks for any suggestion,

Steven A.