Re: motor record startup

["Mooney, Tim M. via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Pete,

Are you by any chance doing a manual restore after iocInit returns?  If so, autosave uses channel access (as opposed to static database access) for manual restores.  This would cause motors to move if values are restored to, say, VAL fields.

Tim Mooney (mooney at anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Siddons, David via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, January 7, 2022 2:31 PM
To: Peterson, Kevin M. <kmpeters at anl.gov>; EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: motor record startup

 

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.