Experimental Physics and
Industrial Control System

"Mooney, Tim M." <[email protected]> · Thu, 16 Jul 2015 19:04:11 +0000

Hi Mark,

I think it's important to distinguish between the way stepper and servo motors rely on encoders.  With a servo, there normally is nothing other than the encoder to give the controller any idea where the motor is.  With a stepper, the controller can safely assume the motor moved by the number of steps it was told to go, and an encoder is not normally needed.  If a stepper motor loses steps, it is because it was not configured correctly for the load it's driving, so you check that it runs reliably at all permitted speeds while commissioning it.  Steppers can run for years without ever missing a step.

However, you can use steppers where the step number isn't exactly equivalent to the desired position, for example because of backlash or other defects of the drive mechanism.  In such cases, an encoder and a retry capability can make up for the mismatch.

Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

________________________________________
From: [email protected] [[email protected]] on behalf of Mark Davis [[email protected]]
Sent: Thursday, July 16, 2015 1:03 PM
To: [email protected]
Subject: Re: Stepper Motor Controllers

Thanks everyone for the clarifications on the whole closed-loop issue.

I am relatively new to the details of stepper motors and controllers
(and the EPICS interfaces), but I have to say I am surprised that - at
the very least - the option to use an encoder to CONTINUOUSLY
adjust/correct the position as needed during movement isn't the norm.

The scenario Mark describes (doing all the correction at the end of the
move) is bad enough if you are changing position along just one axis at
a time (particular if you are doing an on-the-fly scan between the start
and end points).  The thought of that happening on multiple axis at once
would just magnify the problem.  Aside from having the positions between
the start and end ones being wrong, you don't want sudden jumps along
one or more axis when it gets to what it THOUGHT was the end position
for each axis (when it suddenly corrects for the cumulative errors on
each axis all at once).  I certainly wouldn't want to discover a
high-end 3D printer or milling machine was using a controller with such
a handicap.  Or to explain to a physicist why the data from an
experiment is invalid.

Of course, either way, if corrections are needed,  it means that either
the timing or the position will be off from the ideal.  But if the
corrections all wait until the "end" of a move I expect you are far MORE
likely to end up with unusable data points.

NOTE:  The one case where I suppose there is no difference between these
two philosophies is a stepper motor that is already being moved as fast
as it can (or at least as fast as the controller can make it move).
Correcting for lost/incomplete steps along the way would mean
temporarily moving the motor faster (less time between steps) until you
"caught-up" to where it should be.  So if you are already "stepping" the
motor as fast as you can, there is nothing you can do but continue at
the same rate until you reach the target position.

Mark

On 7/15/2015 11:08 AM, Mark Rivers wrote:
> On a related note, we asked the Pro-Dex engineers about the closed-loop correction for stepper motors in the MAXv controller the other day.  He said that if the MAXv is configured for position maintenance with an encoder and stepper motor then it does any required correction at the end of the move.  It does not do any corrections as the move is in progress. It is not clear if the EPICS driver supports this mode.  Most of the applications I know of are using the EPICS motor retries, and not the built-in controller correction.
>
> I also don't know for sure how the XPS handles this.  My impression was that it was constantly correcting, and not just at the end of the move, but I am not certain.
>
> Mark
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Pearson, Matthew R.
> Sent: Wednesday, July 15, 2015 9:06 AM
> To: Torsten Bögershausen
> Cc: [email protected]; [email protected]
> Subject: Re: Stepper Motor Controllers
>
>>> Regarding closed loop mode:  While I can imagine circumstances where you might
>>> want to disable it, I would think that any controller that supports an encoder
>>> would also provide a closed loop mode.  Is that not so?  I would think there
>>> would be little advantage to supporting an encoder if it couldn't be used
>>> directly by the controller during movements (i.e. isn't this question the SAME
>>> as "Does it support a position encoder"?)
>> I think so.
>> Some controllers should be able to make "smooth movements" towards the
>> target position.
> Just to clarify this point. The Parker 6K series does support encoders, but not closed loop control on stepper axes. It's only for feedback to the user. For some stages where the mechanics are poor, or we lose steps, we have to use the motor record retry capability. It's best to have the controller do the closed loop, so it can move to position, or fail, without having software logic on top.
>
> Cheers,
> Matt
>
>
>
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System