Experimental Physics and
Industrial Control System

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