disabled motor records

[mooney@aps.anl.gov (Tim Mooney)]

Dear folks,

The motor database in every distributed version of xfdApp has an
'Enable/Disable' switch that prevents a specific motor record from processing
and prevents channel-access clients from writing to that motor record's fields.
(I works by setting DISA=DISP=1.  DISV is assumed always equal to 1.)

I recommend you not use this switch until we figure out how to make it work
under all circumstances.

The actual behavior of the motor record when this switch is set to 'Disable'
depends on whether a channel-access client or a database is talking to it.
Generally, the disable mechanism works correctly only when a CA client is
talking directly to a motor record.  When a database (e.g., slit software) talks
to a disabled motor record (perhaps on behalf of a CA client), the disable
mechanism still prevents the motor record from processing, but it does not lock
out changes to the record's fields, and (worst of all) it prevents CA clients
from seeing changes made to the VAL field.

This much of the problem probably applies to all or nearly all EPICS records.

Because the motor record's VAL field can thus acquire a value different from the
value the user sees, and because the motor record thinks you want it to move
when the VAL field differs from the RBV (readback value) field, the disable
mechanism allows a user to set a booby trap that can result in the motor moving
unexpectedly the first time it gets processed after being re-enabled.  (Setting
a motor limit is one way to make a booby trapped motor move.)

-----------

There is a related but quite different problem with the slit (and mirror)
software talking to disabled motors.  The slit software sets a field called
xxx:gateOpen, and depends on a slit motor's 'done' flag to reset it to zero.
(gateOpen works around the problem of one motor's 'done' flag going to 0 and
back to 1 before the other motor's flag has had a chance to go to 0.  This is
important only for the scan software.)  Now, the xxx:alldone calculation, which
tells the user and the scan software if any motor is moving, looks at
xxx:gateOpen.  So if the slit software 'opens the gate'.  and a disabled motor
record is prevented from 'closing it', it looks like a motor is moving and will
not stop--even though no motor actually is moving.  This circumstance can mask
the much more serious problem of a recently enabled motor that really *is*
moving unexpectedly.


Tim Mooney