| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: motor record startup |
| From: | "Siddons, David via Tech-talk" <tech-talk at aps.anl.gov> |
| To: | Kevin Peterson <kmpeters at anl.gov>, EPICS Tech Talk <tech-talk at aps.anl.gov> |
| Date: | Fri, 7 Jan 2022 20:31:58 +0000 |
|
Hi Kevin,
It seems likely that Mark is tight and my save-restore is incorrectly set up. When I get to the bottom of it I'll post the solution. Also, part of it may be the driver, but until I fix the s-r stuff I can't be sure. The motor record is motor-R7-2-1.
Pete.
From: Kevin Peterson <kmpeters at anl.gov>
Sent: Friday, January 7, 2022 3:15 PM To: Siddons, David <siddons at bnl.gov>; EPICS Tech Talk <tech-talk at aps.anl.gov> Subject: Re: motor record startup Pete,
Which version of the motor record is being used? I've seen unexpected motion problems with ancient versions of the motor record, but they involved stopping a motor while it was in SET mode, not restoring autosaved positions. A new motor-record field, RSTM, is available in the master branch of the motor module, which gives users more control over how autosaved positions are restored: https://github.com/epics-modules/motor/pull/160 Kevin On 1/6/22 15:13, Siddons, David via Tech-talk wrote: > I would like to suggest an addition to the motor record logic (or > save-restore, not sure which). I have been bitten several times by > having a set of motors under save-restore and having a restart provoke a > runaway. The sequence goes like this: > > motor system running fine, save-restore operating. > IOC is stopped. > Motors are powered down. > motors powered up, causing their internal position registers to be set > to zero. > IOC re-started, save restore writes previous positions into motor > driver, causing them to move to that position, and havoc! > > My proposed change would cause someone (motor, save-restore) to notice > that the hardware and software disagree, and ask the User how they want > to resolve this dilemma. Those of you old enough to remember Spec know > that this is exactly how Spec behaved on startup. If the User decides > that the software is right, then the new positions should be entered in > the SET=1 mode. If she decides that the hardware is right, then that > value should be entered in the same way. It isn't enough to just take > the hardware value as right, since it is quite liable to be wrong, as > described above, although that would prevent runaways. > > In my case, the problem was compounded by the fact that the STOP command > did not work! But that is the subject of another discussion. > > Pete. |