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
- References:
- asyn bo record staying in INVALID DRIVER UDF Torsten Bögershausen via Tech-talk
- RE: asyn bo record staying in INVALID DRIVER UDF Mark Rivers via Tech-talk
- RE: asyn bo record staying in INVALID DRIVER UDF Mark Rivers via Tech-talk
- RE: asyn bo record staying in INVALID DRIVER UDF Mark Rivers via Tech-talk
- RE: asyn bo record staying in INVALID DRIVER UDF Mark Rivers via Tech-talk
- Re: asyn bo record staying in INVALID DRIVER UDF Ralph Lange via Tech-talk
- Navigate by Date:
- Prev:
Re: Epics MODbus driver, can this be run as a MODbus Slave? Mark Rivers via Tech-talk
- Next:
RE: asyn bo record staying in INVALID DRIVER UDF Mark Rivers via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: asyn bo record staying in INVALID DRIVER UDF Mark Rivers via Tech-talk
- Next:
Display Only Lock and/or pw protection for Phoebus Manoussakis, Adamandios via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|