write logs sometimes not indicating updated value
This is transferred from bugzilla:
Jameson Graef Rollins (LIGO - Caltech) 2016-11-30 15:27:00 PST
I'm re-opening this report after talking to Sheila about it a bit more. ezca
writes have wait=True set by default, and are therefore not supposed to return
until the write has taken place. The failure we're seeing here seems to
indicate that the wait is not happening, or is not happening in a truly
synchronous way. I think more investigation is required.
Jameson Graef Rollins (LIGO - Caltech) 2018-02-15 20:00:13 PST
Some more clarity on this:
It's entirely possible that a pyepics get() immediately following a put() will
not show the just-put value. This is because by default get() is reading the
value from the EPICS CA subscription, and the subscription might not have been
updated yet from the recent put(). With pyepics you can specify
pv.get(use_monitor=False) to force pulling the value directly from the channel,
instead of just taking what's in the subscription value.
There's no clean way to universally deal with this in Ezca without incurring a
cost. One might expect that write(wait=True) would not return until the
subscription itself had been updated, but that would definitely add
considerable more time to writes, which are already slow. read() could use
use_monitor=False by default, but that would undermine the entire point of
subscriptions and also slow down reads considerably.
I think the best we could do is to expose the use_monitor=False in ezca.read()
so that it could be used if needed.