Re: synchronizing the value of a read/write record

["Thomas, Patrick via Tech-talk" <tech-talk@aps.anl.gov>]

I see.  Thank you.

---

From: Mark Rivers <rivers@cars.uchicago.edu>
Sent: Wednesday, August 20, 2025 10:34 AM
To: Thomas, Patrick <pthomas@caltech.edu>; EPICS Tech Talk <tech-talk@aps.anl.gov>; Ralph Lange <ralph.lange@gmx.de>
Subject: RE: synchronizing the value of a read/write record

 

It is done whenever the driver calls setIntegerParam, setDoubleParam, or setStringParam for the parameter used by that output record, and then calls callParamCallbacks.

 

From: Tech-talk <tech-talk-bounces@aps.anl.gov> On Behalf Of Thomas, Patrick via Tech-talk
Sent: Wednesday, August 20, 2025 11:59 AM
To: EPICS Tech Talk <tech-talk@aps.anl.gov>; Ralph Lange <ralph.lange@gmx.de>
Subject: Re: synchronizing the value of a read/write record

 

Hi Ralph,

 

Does the ASYN readback mechanism periodically update the value of the output records that use it, or only once after a write is made?

 

Thank you,

Patrick

---

From: Tech-talk <tech-talk-bounces@aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk@aps.anl.gov>
Sent: Wednesday, August 13, 2025 4:45 AM
To: EPICS Tech Talk <tech-talk@aps.anl.gov>
Subject: Re: synchronizing the value of a read/write record

 

On Wed, 13 Aug 2025 at 02:41, Thomas, Patrick via Tech-talk <tech-talk@aps.anl.gov> wrote:

... I am wondering however if there is a way to do this with the val field of just an output record.

 

In general, yes.
Look at ASYN's READBACK mechanism or what the OPC UA Device Support does.

 

Is there any way to synchronize things so that write requests coming from channel access are always written to the hardware and not overridden by periodic updates from reading the hardware?

 

That is indeed the crucial flaw.

Obviously, with two masters, you will always have a race.

The right way to handle this in the IOC: keep the write requests separate and execute them, while keeping the record's VAL at the value that the device updates you with. That will push the race to the device, where it belongs.

But: EPICS output records first get their VAL field set, then they process() and write the value to the device.

There might be ways to sneak around this... so I do have the intention to try implementing that for the OPC UA Device Support. I'm not 100% sure that it will work, though.

(Look at issue 173 of the OPC UA Device Support for some more discussion on a different aspect of that topic.)

 

Cheers,
~Ralph