Experimental Physics and
Industrial Control System

Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> · Fri, 28 May 2021 12:02:53 +0000

Hi Ralph,

>  The whole idea of doing an initial readback as part of record initialization is based on the assumption that the readback is immediate, i.e. synchronous.

> If it is asynchronous and the device answer is only accepted after the equivalent of interruptAccept being true, the timing and order of things may be pretty different.

No, that is not true.  The initial readback is always done with the "syncIO" functions.  For example this is the call in the devAsynInt32::initBo() function, which is the init_record code for the bo record:

    /* Read the current value from the device */
    status = pasynInt32SyncIO->read(pPvt->pasynUserSync,
                      &value, pPvt->pasynUser->timeout);

pasynInt32SyncIO->read() is synchronous, i.e. it blocks until the read operation is complete. This means it is slowing down iocInit, but eliminates the possibility of the asynchronous timing you described.

>  Dropping the device answer would leave the record with UDF cleared (from the silent initial readback) but without processing (as the device answer was lost), which resembles what Torsten is seeing, doesn't it?

The initial readback does not cause the record to process anyway.  That is only done if PINI is true.  In the case of a bo record, PINI with cause a write operation, not a read operation.

Mark

________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, May 28, 2021 4:02 AM
To: EPICS Tech Talk
Subject: Re: asyn bo record staying in INVALID DRIVER UDF

Might that be related to the initial readback being an asynchronous process(ing)?

The whole idea of doing an initial readback as part of record initialization is based on the assumption that the readback is immediate, i.e. synchronous.
If it is asynchronous and the device answer is only accepted after the equivalent of interruptAccept being true, the timing and order of things may be pretty different. In those cases, initial readback has to be done as part of PINI processing, as that runs late enough and works with asynchronous device access. In case that asyn:READBACK is set, the read request can be done as part of the record initialization if the device answer is delayed long enough (or queued) to be processed after interruptAccept. Dropping the device answer would leave the record with UDF cleared (from the silent initial readback) but without processing (as the device answer was lost), which resembles what Torsten is seeing, doesn't it?

Cheers,
~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System