Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Mon, 13 Mar 2006 10:48:32 +0100

Hi Ben
Benjamin Franksen wrote:
I have one question: the docs say that readback from devices for output
records (for bumpless reboot) is done synchronously, blocking iocInit
until all such readbacks have completed. There may be situations where
this is the right aproach. However, there are others, where one would
wish to have the readback to proceed asynchronously, for instance if
there are a lot of such records on an IOC.
In our MultiCAN package we do this by letting init_record 'fake' the
first phase of asynchronous processing. That is, init_record starts
readback, sets PACT and arranges for a special kind of process callback
that lets processing complete with a read (instead of the normal write)
operation.
Would it be very difficult to enable such behavior (optionally, the
synchronous version remaining the default) for StreamDevice, too? Would
you accept a patch that implements this?

If you have many of such records, iocInit may take a long time.
Initializing the records synchronously was the easiest way to ensure
that all initialized records have got their values before any record
processes and can ask for that value. (This is something I do not want
to give up.)
I'll try to implement a more clever way to do this, initializing the
records asyncronously ("in parallel") and then waiting in iocInit until
all records have competed before the scan tasks start. If you send me
some code example from your MultiCAN package, I will have a look at it.

The StreamDevice docs mention the interaction with PINI flag. I think
the best solution is to enable readback on startup only if PINI
is /not/ set. Reading back from teh device hardly makes sense if the
first thing you are going to do is overwrite the value with something
else. OTOH, if PINI is not set, then doing a readback on startup will
at least not do any harm.

There is a conceptional difference between the @init handler and PINI.
The first is initialization of the record (called from init_record()),
the second is initialization of the device (called from process()).
Readback on startup is enabled if and only if an @init handler is
defined (that reads the value). If you don't want a readback, don't
define an @init handler. If you don't want to overwrite the value in the
device, don't set PINI. I leave it to the user to decide if PINI after
@init makes sense or not. Why should StreamDevice try to be smarter than
the user? BTW: Maybe @init handlers do other stuff than readback, e.g.
initializing the hardware. There is no simple way how StreamDevice can
find out what @init actually does.
Dirk
--
Dr. Dirk Zimoch
Swiss Light Source
Paul Scherrer Institut
Computing and Controls
phone +41 56 310 5182
fax   +41 56 310 4413

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System