Closed loop position: motor remains powered after arriving at target

I now have my system working with the new MDC1460 controller and a US Digital 8192 PPR encoder on the output (geared) side. I know that this configuration is not recommended due to backlash, but I have no alternative without dismantling and rebuilding the motor.

I have an issue which I assume is due to backlash: shortly after starting a smooth acceleration (I am moving a 1 tonne object, whose link to the drive is only screws in wood) I find a glitch in loop error which leads to a glitch in motor power. If the proportional gain is too high the system starts violently oscillating with a period of 2-3 Hz and huge variation in motor power and loop error. The whole building shakes. The boundary of Proportional gain is not rigid: 5.0 will do it, 4.0 sometimes, and I'm now operating at 3.0, to minimise Loop Error. But what triggers it is the glitch in loop error, which I am currently assuming is due to backlash (while testing I am running from a rest position to a nearby position (about 70 cm away), and so the motor starts in a different direction each time). I can check this by moving to another position in the same direction: a job for tomorrow.

Of course I could order a new encoder with reduced PPR, so that the Loop Error will (I assume) have a lower value. But I think then I would need to increase the Proportional Gain and end up in the same situation.

However, the point of this message is something different: when the system reaches its destination, the motor power never reduces to zero, even though the Loop Error is zero. It takes different values. but can be as high as 50 (even though this is not enough to make the motor turn). How can I eliminate this?

thanks,
Richard

One of two things is happening:

1) The motor is counteracting another force acting on your door in equilibrium, and needs to draw current. You can test this by shutting off your control or throwing an Estop while it is in this state. If the door moves, this is the case and the current draw is unavoidable because it is holding the door in place. I would recommend adding a mechanical lock brake if this is the case.

2) The controller is really oscillating around the 0 state faster than it can debug to the utility. This shouldn't be possible - you should see some error. If you shut off the controller during this state and the door stays in the same place this is the case. You can consider throwing a motor stop with the !MS command, or switching the controller to open loop to directly control the voltage going to the motor.

Thanks for the quick reply.

Concerning 1., it is possible, but the motor is heavily geared and the thing (it's a sliding roof, rather than a door) really doesn't move. During strong winds I rely on the stiffness of the motor and its gearing to hold it in place, and until now it's been fine. During testing today, and especially when it starts violently oscillating, I have thrown a big yellow breaker switch which disconnects the contactor. There has been no subsequent movement.

Concerning 2., I don't know about the explanation, but the solution is something I have been thinking about before with my previous setup (with the old home-made encoder). This also ended up with the motor powered but at a level insufficient to move the load (it needs to have a motor command of about 150 before anything moves). The problem is the motor gets hot. I was thinking even then of throwing a !MS command if the Loop error gets small enough.

thanks -- as always you give quick and sensible responses. I really appreciate it.

cheers,
Richard

Oh, I meant that you can switch the motor to open loop when it is stopped and then switch back to position control when you want it to move again.

Yes, I have tried just that, and it works!
That's what I will build into the automated software.
thanks,
Richard