Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 9 Dec 2004 00:47:57 +0100

On Tuesday 07 December 2004 14:15, Mark Rivers wrote:
> Benjamin Franksen wrote:
> > Reading back initial values of output records via init_record (what is
> > usually called 'warm reboot' or 'bumpless reboot') has never worked
> > with asynchronous device supports. In particular, to my knowledge
> > devGpib doesn't provided any support for warm reboot (I doubt the new
> > asynDriver based GPIB support is any different here; if it is, I'd be
> > interested to know).
>
> The generic device support for EPICS records in asyn 4.0 sets the
> initial values of output records to the current device value in
> init_record.
>
> [...snip code fragment...]
>
> So it calls the driver's getBounds() method so that linear conversion
> can work, and then calls asynInt32SyncIO->read() to get the current
> value, setting ao->rval to that.  Note that since this is being done in
> iocInit it is OK to wait, and a synchronous call is being used (no
> callback needed).

Most interesting, this. When (years ago) I proposed such a solution the answer 
was invariably that in this case the IOC initialization could be delayed 
indefinitely and that this was not tolerable. Imagine 1000 CAN objects with 
timeout set to 1 second each; IOC boots and just hangs in iocInit... until 
after a few minutes you loose your patience, go over to see what's wrong and 
find out some idiot (probably yourself) has unplugged the cable. It seems 
cable connectors have become much more reliable, if not intelligent, since 
then...

Seriously, there *is* a clean and simple solution that avoids indefinite 
blocking inside iocInit. For asynchronous device supports, init_record must 
act like the first stage of asynch (read) processing. I.e. leave the record 
in an active state (PACT=1) and set up a normal process callback. Since PACT 
is set, the record can't be processed in the normal way (and remains in 
UDF/INVALID state). If and when the callback arrives, (read-) processing 
initiated by init_record completes and everything goes back to normal. You 
just need to make sure that the device support's write method knows it has to 
complete a read (and not a write) the first time it gets called.

BESSY's MultiCAN library works this way.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System