I'm working with a new build of QUADEM for the tetrAMM and seeing a weird asyn issue.
Summary: When writing to the AcquireMode PV, the associated _RBV PV is 'one behind' in reporting the new value, consistently. But if I manually do a caput to the _RBV.PROC field and force it to process, the readback is then consistently correct.
S28IDFE-XBPM:CM3ds:AcquireMode 03/11/22 09:00:39.158459244 Single
S28IDFE-XBPM:CM3ds:AcquireMode_RBV 03/11/22 09:00:39.158436082 Multiple
S28IDFE-XBPM:CM3ds:AcquireMode_RBV 03/11/22 09:01:23.572226245 Single
S28IDFE-XBPM:CM3ds:AcquireMode 03/11/22 09:01:23.572245721 Continuous
S28IDFE-XBPM:CM3ds:AcquireMode_RBV 03/11/22 09:01:34.876944669 Continuous
S28IDFE-XBPM:CM3ds:AcquireMode 03/11/22 09:01:34.876973666 Multiple
after caput AcquireMode_RBV.PROC 1:
S28IDFE-XBPM:CM3ds:AcquireMode_RBV 03/11/22 09:06:33.097901171 Single
// caput caused _RBV to update to the (correct) value of Continuous
S28IDFE-XBPM:CM3ds:AcquireMode_RBV 03/11/22 09:06:42.683848695 Continuous
S28IDFE-XBPM:CM3ds:AcquireMode 03/11/22 09:06:42.683874661 Continuous
S28IDFE-XBPM:CM3ds:AcquireMode_RBV 03/11/22 09:06:44.284941724 Multiple
S28IDFE-XBPM:CM3ds:AcquireMode 03/11/22 09:06:44.284974097 Multiple
S28IDFE-XBPM:CM3ds:AcquireMode_RBV 03/11/22 09:06:45.876836770 Single
S28IDFE-XBPM:CM3ds:AcquireMode 03/11/22 09:06:45.876854823 Single
This is the first time I've built this on a RHEL 8 machine for what that's worth.
Any thoughts?
Thanks,
John