Currently, if we have an AttrRW, we add:
p4p_raw_value[pv_leaf][attribute.access_mode] = pv
where attribute.access_mode is rw; thus, our served structure is:
structure a
string rw P4P_TEST_DEVICE:A
However, we also do:
case AttrRW():
attribute_pv = make_shared_write_pv(attribute)
attribute_pv_rbv = make_shared_read_pv(attribute)
provider.add(f"{full_pv_name}", attribute_pv)
provider.add(f"{full_pv_name}_RBV", attribute_pv_rbv)
so we end up serving an _RBV, but not including it into the pvi structure. On ophyd-async, this leads to the same read_pv and write_pv, and thus a get_value() on a SignalRW returns the setpoint value.
Steps To Reproduce
Steps to reproduce the behavior:
- Launch an example IOC on FastCS
- Check PVI structure, then check generated gui
- See served "_RBV" not included in PVI structure
Acceptance Criteria
- If
AttrRW, add entries for both r and w into the PVI structure
Currently, if we have an
AttrRW, we add:where
attribute.access_modeisrw; thus, our served structure is:However, we also do:
so we end up serving an
_RBV, but not including it into the pvi structure. Onophyd-async, this leads to the sameread_pvandwrite_pv, and thus aget_value()on aSignalRWreturns the setpoint value.Steps To Reproduce
Steps to reproduce the behavior:
Acceptance Criteria
AttrRW, add entries for bothrandwinto the PVI structure