Hi Pete,
What you are describing should never occur, and I have never seen it in many years of working with the motor record on many types of controllers. The last step in your sequence is:
IOC re-started, save restore writes previous positions into motor driver, causing them to move to that position, and havoc!
What should happen is that save restore restores the positions into the motor record in the phase 0, before the motor record will move anything. Thus it just sets the position in the controller, it does not cause
a move.
One explanation for what you are observing is that you have motor VAL field in the wrong autosave set. There are typically 2 autosave request files for an IOC that has motors. auto_positions.req saves the motor
DVAL and OFF fields. auto_settings.req saves everthing else, like .DHLM, .VELO (perhaps), etc. These 2 request files generate 2 different .sav files, auto_positions.sav and auto_settings.sav. The autosave configuration file then has lines like this:
set_pass0_restoreFile("auto_positions.sav")
set_pass0_restoreFile("auto_settings.sav")
set_pass1_restoreFile("auto_settings.sav")
Note that auto_positions.sav is only restored on pass 0. During that pass autosave cannot cause the motor to actually move, it just sets the DVAL position in the record, which then gets pushed to the controller
in set mode.
Is what I describe above how you have your motor autosave values configured?
If so, then what type of controller are you seeing this issue with, and is it reproducible?
Mark
From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Siddons, David via Tech-talk
Sent: Thursday, January 6, 2022 3:14 PM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: motor record startup
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.
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.