You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One difference between CA and PVA protocols is that PVA does not have the same native conception of DBE, in particular there is no direct analogy of DBE_VALUE vs. DBE_ARCHIVE. With PVA, the pvRequest blob is intended for this sort of modifier.
QSRV2 looks for record._options.DBE in a monitor pvRequest, this can either by a string, following the parsing behavior of the old caChannel from pvAccessCPP, or an integer bit mask. In either case, VALUE, ARCHIVE, and ALARM can be specified.
One difference between CA and PVA protocols is that PVA does not have the same native conception of DBE, in particular there is no direct analogy of
DBE_VALUE
vs.DBE_ARCHIVE
. With PVA, the pvRequest blob is intended for this sort of modifier.QSRV2 looks for
record._options.DBE
in a monitor pvRequest, this can either by a string, following the parsing behavior of the old caChannel from pvAccessCPP, or an integer bit mask. In either case,VALUE
,ARCHIVE
, andALARM
can be specified.https://github.com/epics-base/pvxs/blob/ff1d6510cbf84229f7018eacf4008ecd85dce565/ioc/singlesource.cpp#L108-L118
That said, I see that PVXS has no test coverage of this feature, and perhaps unsurprisingly it doesn't work (epics-base/pvxs#97).
So I intend this ticket as a placeholder for eventually getting DBE handling sorted out on both ends.
@kasemir fyi.
The text was updated successfully, but these errors were encountered: