search

ChimeraTK / ApplicationCore

Core library for creating applications based on the ControlSystemAdapter and DeviceAccess.
GNU Lesser General Public License v3.0
1 stars 2 forks source link

StatusAggregator and messages #329

Closed mhier closed 11 months ago

mhier commented 11 months ago

Note: Maybe review per commit will be easier... Merge by rebase, squashing NOT intended!

mhier commented 11 months ago

For the StatusOutput it will be (almost?) always undesired to have DataValidity=invalid.

Why?

The justification for the StatusAggregator to ignore the DataValidity of its inputs is that the same information will typically be seen by other means on another input (broken device causes some status to be invalid and the device status to go to faulty).

In case of an StatusOutput, the DataValidity adds the same type of information as for any other data outputs. If its DataValidity is invalid, it means the status is probably outdated or otherwise unreliable. We shouldn't hide the information at that level in my opinion.

killenb commented 11 months ago

I just saw that I am too late to the discussion, and I have no objections to merging. But it would be useful to have status outputs which are always valid, even if the inputs of the module are invalid. This should be specifiable when creating the output ('always valid' or 'follows module validity'). There are use cases for both.

mhier commented 11 months ago

I just saw that I am too late to the discussion, and I have no objections to merging. But it would be useful to have status outputs which are always valid, even if the inputs of the module are invalid. This should be specifiable when creating the output ('always valid' or 'follows module validity'). There are use cases for both.

That may be actually true for any type of variable, and we should probably foresee some mechanism for this.