phako
commented
5 years ago Fixed by 5df36e0445cad601ed06397e5dc9d747adb374c6 and https://github.com/ChimeraTK/DeviceAccess/commit/bc35e5edfcdd40e1da8b3ad8e6733dc49a4420e3
Closed mhier closed 5 years ago
phako
commented
5 years ago Fixed by 5df36e0445cad601ed06397e5dc9d747adb374c6 and https://github.com/ChimeraTK/DeviceAccess/commit/bc35e5edfcdd40e1da8b3ad8e6733dc49a4420e3
This is a child of ChimeraTK/ApplicationCore#10.
We need to propagate error states through ProcessArrays. Modify the interface of TransferElement in DeviceAccess, so it is possible to set a "data fault" flag in a write operation and to test for it in a read operation. The flag should just mark the data as faulty - the value is still being transferred.
"Faulty" in this context means that the data is either outdated or corrupted. The description should mention that DeviceAccess backends must not abuse this flag to mark communication errors of its transport layer (this should be done with ChimeraTK::runtime_error). It shall only be set inside the application to propagate erroneous states.
The interface change in DeviceAccess should be fully backwards compatible. Existing backends should not need any modification. Setting the data fault flag does nothing if the backend does not support it (the documentation should mention this). Reading the data fault flag will always return false (flag not set), if the backend does not support it (again this should be mentioned in the docu).
The implementation in the ControlSystemAdapter should just transport this flag together with the user data etc. by extending the Buffer struct. This is similar as the VersionNumber is handled.
DoD: