Re: Stepper Motor Controllers

[Mark Davis <davism50@msu.edu>]

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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Pearson, Matthew R.
> Sent: Wednesday, July 15, 2015 9:06 AM
> To: Torsten Bögershausen
> Cc: mark_a_davis@comcast.net; tech-talk@aps.anl.gov
> 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