Servo Troubleshooting - the endless loop

Join Date
Apr 2002
Location
Just a bit northeast of nowhere
Posts
1,117
In my recent "whaddafuh" post, I got alot of good suggestions, and some criticism on shotgunning the repair. No arguement, I don't like shotgunning a repair any more than the next tech. And I'm running out of chickens...

Anywho, I thought I'd open a discussion on servo troubleshooting techniques - this is one area I wish I was stronger in. My difficulty in troubleshooting servos comes from not knowing which end of this serpent is the head, and which is the tail.

Let's say I have a following error fault on a previously working system. I find looking at the encoder on an o-scope to be somewhat less than helpful, because

1. It could be the mechanical load. Changes in the load mechanism can render the original tuning incapable of operating the drive successfully.

2. It could be the motor/encoder. I can take off the motor, disable it and turn it by hand to verify the pulses are there - but are they correct? To get an accurate count, I have to move a fixed distance and compare expected vs real counts. And I can't do that because I'm failing for following error at every attempt.

3. It could be the drive. It may be getting the encoder pulses, but not seeing them. Far, far worse, it may be getting the pulses, but not seeing ALL of them. Or maybe I'm not putting out all the pulses in the first place(see #2).


So to troubleshoot at all, I gotta start somewhere. I go mechanical, and have the maintenance guys certify that the mechanism is okay - 4 out of 10 cases, the thing needs greased, another 2 in 10 it has something loose or misadjusted.

I used to go after the motor; it's the easiest change, and you get a fresh motor and new encoder in the deal. However, it's almost never the motor, only a few times in several years. So these days, I usually go after the drive instead. About 2 in 10, the drive corrects it - these things are pretty fragile.

After that, last resort, I start with the tuning and limits. I can usually get it up that way if all else fails. On those occasions I've not been able to, something else has been at fault - the motor or drive on the shelf was bad.

So that's my approach. Yeah, it's shotgunning, but that's the logic behind it. I'd like to hear how others tackle these things, particularly Peter and Ron.

How about it guys, which end do you grab first?

TM
 
Assume Nothing and Divide and Conquer

I like to disconnect the pieces and see if they respond correctly in isolation. In your cases I would hook up another counter in parallel and see if both channels read the same counts and change in counts. The trick is that you can split the line at the drive or controller or you can split the line at the encoder. I often suggest running a second set of wires. It doesn't need to be pretty as it is only temporary but it can provide information as to where the problem is. More later.
 
There's absolutely nothing wrong with your approach to troubleshooting. Call it 'Shotgunning' if you will, but this is exactly how it's supposed to be done. This is First Level troubleshooting.
Second Level starts when you replace the same part a second time - in this case, the cable. You recognized the transition from Level 1 to Level 2 immediately. Swapping parts is only a temporary fix, prompting your post.
My reply is the first step of Level 2. Check the connectors, and use a scope to verify them. No deep analysis, just look for good shape and amplitude.
It's unrealistic to assume you'll be able see missing pulses or out-of-phase signals without getting seriously in-depth. That's not needed, because the controller will report these faults. Simply use the scope to see that the signals are 'clean'.
Other posters shared their solutions, clearly pointing to the connectors as problematic. You said you hadn't though of the connectors and will check them next. Good - everything you've done is correct.

My concern was related to other posters. Level 2 is deeper analysis to discover why swapping parts alone isn't curing the problem. They keep swapping more parts and waiting days or weeks to see if that fixed it.

Without more information (description of your specific encoder signals) and/or use of deeper analysis tools (scope), then you remain permanently trapped in Level 1.

Nobody wants to be permanently stuck at Level 1, and it bugs me to see it. In this case, I told you exactly what's happening (connector pins corroding) and how to verify you fixed it (use a scope).
There's several factors involved in Level 2. Peter's suggestions are a good start. Prove hardware works by bench testing. Rule out all cables and connectors by running a temporary direct connection.
Next is looking for the strange stuff like a flaky power supply, AC line spikes, nearby equipment generating noise (it only fails when somebody runs machine X).

In many cases, the tech doesn't want to tell the boss it's time to call in the experts because "I can't fix it", so he stays trapped at Level 1 endlessly swapping thousands of dollars worth of parts.

There's no need for that. This forum is where you come for help in Level 2. There are many experts here that love helping with tough problems.

So, "which end do you grab first"? It doesn't matter what order you do Level 1 troubleshooting. Take the easiest path. What does matter is when it's time to decide you're at Level 2, and it's time to post your question.
Tim, in your case you did this and got your answer. I believe the "critcism" was directed at the other posters that didn't.
 
Peter Nachtwey said:
In your cases I would hook up another counter in parallel and see if both channels read the same counts and change in counts.

I discussed this with my friend Ray (top servo ace) and turns out the software for this drive has a diagnostic feature to do just this.

Interesting thing about the Electro-Craft IQ series, and it's AB Ultra descendants: some of them had pretty bad incremental encoder diagnostics during online operation. For instance, it was overly tolerant of incorrect counts from the encoder at a given velocity.

In this instance, I disabled the drive, started the encoder diagnostic applet, and found the index mark. I then cleared the count and spun the motor one full revolution by hand, nice and slow, until I got back to the index mark.

2000 line quad encoder is 8000 pulses per revolution. Suprise - I got 8130. This motor had already been rebuilt once, so to the the dumpster it went.

This is particularly significant because this application involves the motor moving only about 160 degrees of a single rotation, repeatedly. Not enough to send it completely off the handle, but enough to create a drift.

I then took a known good motor off another running machine of the same design, and low and behold, it's been running perfectly for 2 days now.

I did spray out the connectors with high-quality contact cleaner, and swabbed them as well, but this had no immediate effect. Nevertheless, it is now in my playbook as a "first-thing", directly under "tighten all terminals".

Thanks!

TM
 
Hi Keith, and thanks for the encouragement. I took the criticism as directed at myself, but in all honesty, it doesn't bother me - I welcome honest correction.

As for your advice on the pins, while it wasn't the case in this instance, it's nevertheless going in my standard toolbox. Henceforth, every servo issue I have is starting with tightening the screws and cleaning the contacts!

I will always keep posting my questions here, in the neverending hope that my trials will not only be resolved, but will help someone else as well :)

You put some excellent advice in there, and I'm taking notes!

Thanks!

TM
 
Troubleshooting Encoders

Your post regarding the solution shows how valuable feedback is.
1) The controller has valuable diagnostics.
2) The controller is tolerant of errors. That's exactly why I said "It's working now" isn't good enough. You must verify signal quality.

Extra counts is something I hadn't considered. This can only be caused by a scratch on the optical wheel, producing extra lines. To see this on a scope, you would need to look at all 8000 pulses, and notice some are a different size (pulse width) and wrong phase relationship (not 90 degrees). Not gonna happen - the controller diagnostics is the proper tool for this fault.

I searched for a link to Encoder theory, and found many to be overly complex. Here's a page that describes how to build an Encoder interface. The theory at the beginning is good.
[size=-1]www.bipom.com/applications/encoder/encoder.pdf[/size]

The issue to consider in this circuit is the threshold. It's 2.4 volts with Schmitt input devices. When looking at encoder signals with a scope, become concerned if they're lower than 3 volts. Most controllers probably have a lower tolerance, but a good encoder should still have a strong signal of 4 volts or more (if it's 5 volt powered).
 
2000 line quad encoder is 8000 pulses per revolution. Suprise - I got 8130. This motor had already been rebuilt once, so to the the dumpster it went.

That may or may not have been a defective encoder, it would not take but a 1 to 2 degree difference to offer an improper count when done by hand.

When it comes to drives, motors, and possibly encoders, depending on type and cost, if I can not determine the exact problem I will send it to the factory for failure analysis whether it is to be repaired or not. The failure analysis can be invaluable.

The factory is always more expensive when it comes to repairs but I have had more luck using them. In many cases, if they have that unit in stock, they will just send one that is already repaired. In some cases where a motor is concerned they will just use the housing and replace the rotor, stator, and encoder...it depends, check with the OEM to see what they offer. A motor can be rebuilt numerous times as long as the housing is not damaged, the rest can be replaced at a much lower cost then new in some cases.

I do not know how many servo systems you are using but if the number is high then you should consider building a test bench just for them.

I worked with a flexographic press with 8 decks and 7 stepper motors for each deck. I built a test bench just for them and ran spare cables on the machine to use WHEN a problem occured. This was the first unit that company built and I figured out early on the job the encoder/motor wiring was a major problem.

Also check out this thread on a time when I did work at a plant that had burned out 4 Indramat servo drives. I say we alot in the post but I am "WE". It took time but using the factory analysis and a scope I finally determined there was a grounding issue. They only ran the system a few times in less than 18 months and let the smoke out of 4 drives, to my knowledge the last one has not faulted in over 2 years after I eliminated the "noise" problem.
http://www.plctalk.net/qanda/showthread.php?t=8414&highlight=servo
 
Last edited:

Similar Topics

Our Allen Bradley Ultra Series 200 Digital Servo Drive has been faulting out without providing a fault signal. After about 15 minuets of...
Replies
0
Views
2,069
CNC machine: Servo went out, and was replaced. Still having problems, encoder cable, and drive replaced. Motor runs and faults. Amps go from 8 to...
Replies
8
Views
3,319
I hate to admit this... I'm at a loss for figuring out if a servo motor is bad. A regular motor can have a megger-test. What does a servo have...
Replies
3
Views
2,287
Hi All, I have a customer with an old system which I think was bought by Bosch who was then bought by Rexroth and I'm not having much luck...
Replies
9
Views
2,809
Hello All! I'm working on a basic troubleshooting procedure for servo systems. Nothing brand-specific, and not strictly PLC, but related :)...
Replies
3
Views
3,456
Back
Top Bottom