0
\$\begingroup\$

I am trying to read the encoder signal of a drive amplifier using an ARM (TM4C). The amplifier has differential outputs (+- 5V), the MCU has 2 QEIs (Quadrature Encoder Interfaces).

First I have tried to use the A and B signals like single ended ones, and sometimes I get a steady signal / count number. (Compared to the drive amplifiers configuration software both of them are dead on the same count).

BUT from time to time, the counts start to float even if the motor is not moving. Or while moving from one direction to the other it starts to lose count.

I have measured the signal with my Rigol DSO and there are spikes on the encoder signals. So I have decided to use both A and notA feed them to a UA9637A to make the differential signals single ended and get a nice square wave, but no joy.

The problem persist.

Side notes:

  • Drive Amplifier = Hiwin D2
  • Encoder = 13 bit incremental (RS4222 Differential)
  • MCU = TM4C123G LaunchPad

What shall I try to get the proper count of steps? The cable coming from the amplifier to the breadboard is not shielded but it's only like 20-25cm long. Does this matter?

I am open for any ideas that might fix this issue.

|improve this question
\$\endgroup\$
  • \$\begingroup\$ You have a serious EMI problem that needs to be fixed. Twisted pairs only for motor and sensors, add CM choke and show/ choose better common ground so that sensors do not share motor current or even close to motor wires. filtering may help shunt stray noise with optimal load cap. Yes cable length and proximity to noise (?) counts. Shld cable is best. \$\endgroup\$ – Sunnyskyguy EE75 Nov 14 '17 at 20:31
  • \$\begingroup\$ @TonyStewart.EEsince'75 I will replace the wires with an UTP cable to see if it will get better. The drive itself has a pin called "digital GND" which is right next to the encoder outputs. I am using that one. \$\endgroup\$ – Zoszko Nov 15 '17 at 13:24
  • \$\begingroup\$ STP is better than UTP and good supply decoupling and choice of "star" gnd is critical. \$\endgroup\$ – Sunnyskyguy EE75 Nov 15 '17 at 19:46
1
\$\begingroup\$

This is a common mistake with quadrature encoders.

You can NOT just count the edges / pulses of one signal or the other on it's own. Encoders inherently generate spurious edges as the mask uncovers the sensor, whether that be optical, magnetic or whatever.

You can add filtering to reduce that noise when the thing is turning, but that will not help if the encoder is stopped exactly on an edge of the slot or mask. Obviously electrical noise will be an issue, but even vibration from a fan connected to the same chassis can make the thing send out hundreds of edges.

As such you actually need to use an up-down counter algorithm or logic that monitors both lines.

Lets say we are using line A to count.

  1. If you see a rising edge on Line A and Line B is low you count up.
  2. If you see a falling edge on Line A and Line B is still low, your encoder is telling you it thinks you went backwards a bit. You need to count down

This gets further complicated by the fact that the extra edges can happen faster than your monitor can watch them.

When you are driving something at speed, and you know whatever it is can't spontaneously go backwards you can use the second signal as a throttle for the first. That is if you see a rising edge on Line A and Line B is low you count up and wait for line B to go high then low before monitoring line A again.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Hello! The driver library has it's own QEI code (with built in QEI interfaces on the board) so the problem sould be the noise thats beeing picked up. I will try using a shielded cable, see if it helps. Stoping on the edge, would not make any issues. 1-2 steps difference is not a big deal when the whole scale is -60000 to +60000 counts. \$\endgroup\$ – Zoszko Nov 15 '17 at 14:04
  • \$\begingroup\$ @Zoszko no you are missing the point. When an encoder is stopped on an edge, it will, normally, give out all kinds of extra edges if there is even the hint of vibration in the mechanics. This is not "NOISE" and should NOT be filtered out because if you are trying to hold the shaft at that position, you need to know when it moves left or right early. not some time after when the filtering lets the signal through. \$\endgroup\$ – Trevor_G Nov 15 '17 at 14:22
  • \$\begingroup\$ Well I get you, but this happens even if there is not so much load on the shaft. The motor connects to a gearbox with a ratio of 1:100. So while idling and nothing moves the mechanics, there is no vibration the count goes up rapidly. (Sometimes even faster than the motor would run.) I understand you, but still cant see the end of the tunnel. How does the drive amplifier not suffer from this? On the controll app I can see nice steady numbers. Is there a solution that would eliminate the issue? How does PLC-s solve this? They run much slower, still can get the correct position). TY \$\endgroup\$ – Zoszko Nov 15 '17 at 14:35
  • \$\begingroup\$ @Zoszko because with a quadrature encoder things happen in an order on both lines. The controller is programmed, or configured with hardware, that properly monitors both signals to only increment the counter when both lines go though a complete cycle in one direction or the other. If you just watch one line and count edges without qualifying that with seeing the other line go through a complete cycle, you will count extra edges from the same spot. \$\endgroup\$ – Trevor_G Nov 15 '17 at 14:44
  • \$\begingroup\$ I am monitoring both A and B lines. I thought TI took care of this programatically in their driver library. Well it seems like they did not. \$\endgroup\$ – Zoszko Nov 15 '17 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.