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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | motor record startup |
From: | "Siddons, David via Tech-talk" <tech-talk at aps.anl.gov> |
To: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
Date: | Thu, 6 Jan 2022 21:13:55 +0000 |
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.
|