Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Mon, 17 Jun 2013 14:37:07 -0500

On 6/14/13 1:20 PM, Mark Rivers wrote:
> I'd be very interested in hearing what others think of the above
> ideas.

Hi, Mark.

I think your idea of minimizing error messages (when a device
disconnects) directly in asynManager would be good.  I agree with Bob
Dalesio's statement about having a single error message when a device
disconnects and a single status message when it reconnects.

About the connect-disconnect situation: I agree it is a general problem.
I've run into it a number of times.  For example, I've had an IOC on a
backup power source and a BPM controller not on a backup power source.
The driver for the controller ran on the IOC and communicated with the
controller via RS-232.  The controller lost power and booted again when
power was restored.  Unfortunately, all my BPM readings were totally
wrong because it booted with default values.  Only by setting all the
values from the driver again did my BPM readings return to normalcy.

For noncustom asyn drivers (e.g. implemented as a database of records,
with or without StreamDevice, or as a sequencer program, etc.), I like
your solution #3.  I'm OK with using PINI, but using it in this way is
of course abusing it in an attempt to remain backward compatible.  If a
new field could be added just for controlling the connect-disconnect
behavior, that would be great.  Maybe an even better alternative would
be something like the autosave .req files.  You could add an annotation
to a record to indicate that it should have a specific
connect-disconnect behavior, and then use a tool to generate
.asyn-connect (or whatever) files.  You then load these files via an
iocsh function like .req files are loaded for autosave.  This would
control what records get processed on what connect-disconnect events and
in what order.

For custom asyn drivers written in C/C++, I think something closer to
your solution #2 would be good.  (So I'm suggesting both this solution
and the above solution.)  I think it would be nice to have an asyn base
class that implements onConnect and onDisconnect methods.  This would
help alleviate some of the work for the developer.  By default, these
two methods operate on an ordered list of driver parameters.  (Maybe
there should be two lists: one for onConnect and one for onDisconnect.)
The base class would also provide methods for adding or removing
parameters from this list.  In the subclass, just arrange for the list
to contain the desired driver parameters in the desired order.  For even
more control, the onConnect and onDisconnect methods may be overridden
in the subclass.

I have two use cases I'm concerned about.  The first is the "atomic put"
case where I need to write two or more values (from distinct records) at
the same time to the device.  A good example of this is the
vendor-provided API for setting the threshold of a DECTRIS PILATUS
pixel-array detector.  The threshold is set as an energy and gain.  The
energy and gain are specified in two separate records.  Since it takes
~70 seconds to set the threshold on a PILATUS 6M, I only want to do it
once.  I would like a solution that can handle this case.

My noncustom asyn driver solution can handle this use case by marking
the threshold-energy and threshold-gain records to not do anything on
reconnect.  I add a threshold-restore record that is marked to process
on reconnect, and it disables the threshold-auto-apply, causes the
threshold-energy and threshold-gain records to process, causes the
threshold-apply record to process, and then sets the
threshold-auto-apply back to its original value.  This will only work if
using the .asyn-connect files approach or the new connect-disconnect
field approach so that an ordering can be specified to the record
processing.  This is necessary because, for the PILATUS 6M, the
threshold-restore record should be processed last because it will take
~70 seconds for the threshold to be set.  If other records process after
the threshold-restore record has started processing, they will timeout
because the detector is busying setting its threshold.  (Without a
record process ordering, a hack would be to introduce a delay into the
threshold-restore record behavior to ensure it waited long enough for
all the other records to finish processing before it started.)

My custom asyn driver solution can handle this use case by overriding
the onConnect method to do the following: set ThresholdAutoApply to No,
invoke the super implementation (which will skip setting the threshold
because ThresholdAutoApply has been set to No), apply the threshold, and
restore ThresholdAutoApply to its original value.

The second use case I'm concerned about is what should happen when a
long-running operation is being performed by the device when it is
disconnected from the IOC.  If the device is reconnected and is still
performing that long-running operation, it might not be appropriate to
just cause all kinds of records to process to set various parameters on
the device; the device might not be in a state where it can handle the
requests generated by the processed records.

I think the solution is again to support an ordering to the processing
on reconnect.  In both a noncustom asyn driver and a custom asyn driver,
we want to be able to do some things before others.  For this
long-running operation use case, we would want to command something like
a "stop" or "reset" on the device before we start causing other driver
records to process.  Both of my driver solutions can do this.

Thanks,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System