Servo motor and encoder. How to debug?

[ESjaavik]

I have just connected up PacSci 902 servo drives to a motor.
It is confused about where it is.

Usually it oscillate between two positions some 30-50 degrees apart. If it settles, I can make it oscillate by just turning slightly on the shaft.

I've been there several times before with other drives. Then it was fixed by just swapping two motor leads, indicating that it could not hit the target position because it went in the wrong direction when correcting it. It didn't work this time.

Anyone have some rules for debugging that tells what cnages to make based upon the behaviour?

And no, I'm not just guessing. The motor and drive is connected using the documentation for them both. The motor works fine with another drive brand, so there should be nothing wrong with it.

[HuFlungDung]

Is this a DC servo?

Is there a balance adjustment pot on the drive? This would usually be adjusted to stop drift, rather than oscillation, I suppose. But, I think that if the encoder and motor are hooked up backwards relative to one another, you will get a runaway condition, not an oscillation. Of course you checked that the encoder is tightened in its coupling to the motor?

[ESjaavik]

It's a BLDC servo.

On the other drive I had trouble with (because I connected it wrong), it detected the problem and went into fault mode shortly. It may be that the PID parms are totally wrong, but then I would expect the oscillation to worsen exponentially and not go into a stable rhytm.

There are no pots, but I can do the same thing using a PC-program. I'm just used to getting the no-move behaviour without tweaking anything. Yes everything is well connected.

I'll have to pop in the OC930 option card and see what the setup is. It may be as you indicate that it is too far off to be able to control the motor.

[Al_The_Man]

Isn't the 902 a digital servo drive that expects resolver feedback? What kind of feed back is on the motor you are using?
are you closing the motion control loop with an encoder?
Al

[ESjaavik]

Al: Yes it expects a resolver. It's just me working mostly with encoders lately, and then that's what I plunk down. Sorry for the confusion. (Can I change the thread name?) Anyway forget the encoder, it's not there.

The motor is a Stromag with a standard resolver. I connected it using the docs. And I am sure that the excitation winding is going to the right place using an ohmmeter (it has a lower resistance). I also tried swapping polarities in case the two brands use different naming. Although it should be a standard, or am I wrong here?

Looking through the motor doc's I may have wrongly specified it as a 6pole while the doc indicate it may be a 4-pole. But it's fuzzy on that point (and in German) so I have to reread it tomorrow. I guess that would confuse the drive enough if wrong.

The bright side is I'll never need a crossword puzzle or a Rubiks Cube as long as I have a drive and a motor that's not in the list of known motors. :-)

[Al_The_Man]

It might be worth an email into Danaher (PacSci) support to see what they suggest.
Al

[ESjaavik]

Problem(s) solved.

The main problem was that I think metric, and use a motor with metric parameters, but the drive expect lbf-feet and similar stange units. And I more or less told the drive it was tugging a train, while in fact the motor was free-running. As the drive is a "european version" I must admit I didn't even notice it wanted non-SI units first time around.

After taking care of that, it now has responses like an Italian car! :-)