EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Stepper Motor Controllers
From: Mark Rivers <[email protected]>
To: "'[email protected]'" <[email protected]>, "[email protected]" <[email protected]>
Date: Thu, 16 Jul 2015 19:16:46 +0000
>  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.

That depends on the following:

- Conventional step-scan or on-the-fly scan.
If it is a conventional step-scan then it does not matter how the correction is done as long as it gets to the target position before it says it is done.

- If it is an on-the-fly scan then what is triggering the detector?  If it is time or the theoretical motor position (e.g. stepper motor logic pulses) then it does matter that the correction is done at the end.  But if the detector trigger is the encoder signal then it is more tolerant of the path that was taken to the position.

A well-designed stepper motor system should be quite accurate open-loop.  Typically encoders are used to correct for cyclic errors in the gear train, not errors that are cumulative over long travel.  So the amount of correction at the end of run are small.  An exception would be a system like a vertical translator using a linear encoder but a scissors-jack actuator.  In this case the number of steps/mm is changing significantly over the travel range, and you would really want to use a system with continuous correction.

I think most 3-D printers and milling machines use DC-servo motors, not stepper motors.

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mark Davis
Sent: Thursday, July 16, 2015 1:04 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
>
>
>
>
>



References:
Stepper Motor Controllers Mark Davis
RE: Stepper Motor Controllers Mark Rivers
Re: Stepper Motor Controllers Mark Davis
Re: Stepper Motor Controllers Torsten Bögershausen
Re: Stepper Motor Controllers Pearson, Matthew R.
RE: Stepper Motor Controllers Mark Rivers
Re: Stepper Motor Controllers Mark Davis

Navigate by Date:
Prev: RE: Stepper Motor Controllers Mooney, Tim M.
Next: Re: Stepper Motor Controllers Ron Sluiter
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Stepper Motor Controllers Mooney, Tim M.
Next: Re: Stepper Motor Controllers Ron Sluiter
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·