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 Davis <[email protected]>
To: [email protected]
Date: Thu, 16 Jul 2015 14:03:55 -0400
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







Replies:
RE: Stepper Motor Controllers Mooney, Tim M.
RE: Stepper Motor Controllers Mark Rivers
Re: Stepper Motor Controllers Ron Sluiter
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

Navigate by Date:
Prev: Re: Linux vs. RTOS: cost and security; was: Stepper Motor Controllers Benjamin Franksen
Next: RE: Stepper Motor Controllers Mooney, Tim M.
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 Mark Rivers
Next: RE: Stepper Motor Controllers Mooney, Tim M.
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 ·