Experimental Physics and Industrial Control System
> 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
<2015>
2016
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
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024