Chinese AC servo encoder failing: fixing or replacing

I have several chinese AC servos on my machines (with A1-SVD15 servo drivers) and 3 of them failed on my this summer. One of them gives me an overload alarm when I try to move the motor (but is related to the encoder not working), the other two give me an encoder alarm at startup. So I'm writing this post to share my venture tryinig to fix them (or replace them with the help of LinuxCNC) and get ideas from other users.

Options to go on:
-Try to fix the encoders if possible (and gain some extra knowledge)
-Replace the encoder. They are NEMICON (copy) U48-T09-2500L-62C and U48-T09-2500L-62-03. Found a similar copy one but not exactly the same code. Price is not much less than the whole servo.
-Replace the ABZ signals with a linear glass scale and the UVW with a simple encoder/hal sensors.
-Replace the ABZ signals with a linear glass scale and replicate UVW with LinuxCNC using the BLDC component.

After checking that was not a drive problem, I fed 5V to the encoder and started measuring the outputs. 2 of the servos had the right voltajes at the otputs but were not responsive to shaft movement, also consumed current was steady and low. The other servo did respond to shaft movement in all lines, although voltages were a bit low in some, so this will be a great candidate to try to repair the encoder.

Opened the encoder and it haves a pretty simple electronics. Two Avago AELT5000 ICs convert the photodiode signal into a diferential output. One of them is used on the ABI signals and the other in UVW. Input voltage at the chip is fine. Interestingly I could not find anywhere the IC datasheet, but after checking the pintouts, it's a standar quad output diferential drive.

Since the lines with lower voltages were on the ABI, the IC might be slightly damaged giving lower voltages and replacing it could solve the issue. So got both a replacement IC (AM26C31Q) and a RS-422 0.1um glass scale. While witing for the replacement IC, I installed the glass scale on the X axis of my lathe and rewired the servo driver so the glass scale feeds the ABI signals and the encoder the UVW ones. This "kinda" worked: I could moove the servo at slow speeds but sometimes it just keep stalling and going into alarm. At higher speeds I could see how the plate that holds the servo was bending and asumed this made the servo loop unstable, so ordered the material to make a better support.

While waiting for the material I kept messing with the encoder. Changed the ABZ diferential driver IC with other AELT5000 from the other faulty encoders (that IC should be fine) but didn't work. Put the wiring to use again the glass scale and, what it was working before, didn't now. Weird, I could have damaged something else. So fired up my new oscilloscope for the first time and took a look to the signals. They were a bit low on voltage (something more than 2V) but sharp and clear. Enabled the motor and... oh man, here comes the noise, lots of noise. Highest spikes were around 75% of signal voltage, as I understand not enough to disrupt the diferential signal. Encoder wires are shielded (globally, not each pair) twisted pair, but motor ones are not. Changed back the diferential IC with one an AM26C31Q but I don't remember if I checked the noise after it.

So asked myself how was the servo driver receiving the diferential signals so opened a spare one I have. Like with many other electronics, the chinese company have put some black epoxy on the ICs to avoid getting reverse engineered. With some carefull sanding and a digital microscope I was able to see the ICs numbers. The signals are received by two 26LS32ACG4 RS-422 differential receivers. There is also a 74HC14 inverter with Schmitt-Trigger inputs. On the other side of the PCB there are a couple of 74HC86, XOR gates. The XOR gates detects if there is something wrong in the diferential signal. The Schmitt-Trigger give some signal cleaning, but have not checked if for the line driver or the XOR gates. So a radical option to make this encoder work would be to desolder the XOR gates from the servo driver and force an OK signal.

Decided to take a working servo and start exchanging the encoder signals until I found the faulty one. Happened to be the B signal, so I used a MAX490 module as buffer. Connected the diferential output of the encoder to the diferential input of the MAX490, then both TTL input and output together, and finally the diferential output of the module with the input in the servo drive. Worked an I went happy into chrsitmas holydays. Cambe back, turned on the lathe, meanwhile I was servicing other machine, went back to the lathe and the alarm was on again...

Since I was suspecting that random noise could be causing the problem, I decided to exchange the motor into another axis of my lathe (and took out the B signal buffer), were I could separate the power and encoder cables easily. Everything turned on right and I could move the motor, but after a few minutes the alarm popped. Power cycled the drive and the alarm was still there. Turned it off again, waited some minutes and turned back on. There was not alarm and I could move the motor again, but after a few minutes (less than the first time) it gave me the alarm. This is an interesting behaiviour and I think it could be key. Seems that, when the servo driver has been shut down for a while, I turn the on the power and it works for a few minutes. Power reseting don't clear the issue, but waiting some time does, like some component is heating and need some time to cool down. Powering the drive and just waiting wihtout moving the motor causes the same issue.

If this hypothetical heating is caused by excesive current consumption on the encoder, I have not notice any component temperature being excesive. Could be the drive (keep in mind I have tested several) encoder 5V power supply getting overload an making micro cuts. This micro cuts might be seen as several channels changing at the same time, this could be read by the drive MCU as an encoder exception. I have to think how I could try to detect the moment of the failure. I can power the encoder with an external 5V power supply too.

Did tested buffering all the signal with 6 MAX490 modules, but same result. Will try again beause found one wire getting loose. Any other idea of what could be the cause, how to solve or what to test is really welcome!
 

Some servo drives may have PTC thermistors (self-resetting fuses) to protect the drive from damage if the encoder cable shorts out. An encoder that draws too much current may cause the PTC to heat up to near the trip point, so it takes a while to cool. In this case, the +5V at the encoder will sag when the PTC gets hot. You could measure that when the drive faults.

You may need to tinker with the grounding and or shielding of the encoder cable to eliminate the noise when the drive is powered on. Connecting a heavy ground wire between the drive frame and the motor frame might help, or even floating the encoder body with an insulating material, to keep noise on the motor frame from affecting the encoder signals. Also, the scope may be "lying" to you, as it might pick up noise from the mains plug.
Jon

Tommylight is right about the mains filter. I had to put a mains filter on the power input to the VFD on my mill, it was causing communications errors between the computer and motion interface. Never had an issue since I put the filter in.
Jon

You are right tommylight, the post is quite long and my apologies about that. I know is not the best way to get an straight answer since many people will not take the time to read it, but I wanted to explain all test I have done to give the knowledgeable people all the info I could. Plus writing it donw might be usefull fore somebody in the future. So many thanks to everybody who bothered to read it.

Motors don't have ferrite toroids on the wires, would be easy to install. I will take a look at installing some line filters. I guess one per drive would be better, right? I don't have much space on the cabinet for that, but one for the whole machine is easy. Since my mill has been working withot them and no problem, never really looked into them.

Encoder cable is shielded and connected on the drive side. Is not connected on the encoder side and I cannot see where the shield end. Motor power cables have a ground. I could check if the encoder body is connected to pcb ground.

The PTC thermistor makes a lot of sense. This "working" encoder was consuming around 90mA, while the two non working ones aroun 25mA. I will measure a working encoder to compare. I can also try to catch the issue with the multimeter or use the trigger function of the oscilloscope. My concern if I use an external PSU is that the encoder could overheat.

I have repaired encoder that had failed bearings with axial / radial play so the clearance distance of optical disc from
pulses photodetector was not stable giving random results.
Also repaired another encoder by recalibrating
the trimpots in oscilloscope.
Check these first.