@@ -37,20 +37,20 @@ This specification goes beyond ApplicationCore. It has impact on other ChimeraTK
## D. Detailed requirements ##
1. All `NDRegisterAccessor` implementations (including but not limited to the `ProcessArray`) have the `DataValidity::faulty` flag set after construction for the receiving end. This ensures, all data is marked as `faulty` as long as no sensible initial values have been propagated. The sending end has `DataValidity::ok` after construction, so that the first written data automatically propagates the ok state by default. For bidirectional variables, this is the case for both directions separately.
2. All `NDRegisterAccessor` implementations have initially a `VersionNumber` constructed with a `nullptr`, which allows to check whether this variable is still at its "value after construction", or the initial value propagation already took place.
3. `ApplicationModule` (and `ThreadedFanOut`/`TriggerFanOut`) propagate the `DataValidity` of its outputs according to the state of all inputs. This behaviour is identical to later during normal data processing and specified in the \ref spec_dataValidityPropagation "Technical specification: data validity propagation".
1. All `NDRegisterAccessor` implementations (including but not limited to the `ProcessArray`) have the `DataValidity::faulty` flag set after construction for the receiving end. This ensures, all data is marked as `faulty` as long as no sensible initial values have been propagated. The sending end has `DataValidity::ok` after construction, so that the first written data automatically propagates the ok state by default. For bidirectional variables, this is the case for both directions separately. [ \ref testD1InitialValue_D_1 "T"]
2. All `NDRegisterAccessor` implementations have initially a `VersionNumber` constructed with a `nullptr`, which allows to check whether this variable is still at its "value after construction", or the initial value propagation already took place. [ \ref testD1InitialValue_D_2 "T"]
3. `ApplicationModule` (and `ThreadedFanOut`/`TriggerFanOut`) propagate the `DataValidity` of its outputs according to the state of all inputs. This behaviour is identical to later during normal data processing and specified in the \ref spec_dataValidityPropagation "Technical specification: data validity propagation". [ \ref testD1InitialValue_D_3 "T"]
4. (removed)
5. Control system variables:
5. Control system variables: [Testing should be done in control system adapter.]
1. Variables with the control-system-to-application direction are written exactly once at application start by the control system adapter with their initial values from the persistency layer. This is done before `ApplicationBase::run()` is called, or soon after (major parts of the application will be blocked until it's done). If the persistency layer can persist the `DataValidity`, the initial value have the correct validity. Otherwise, initial values always have the `DataValidity::ok`.
2. Variables with the application-to-control-system direction conceptually do not have an "initial value". The control system adapter implementation does not wait for an initial value to show up. The first value of these variables are written at an undefined time after the `ApplicationBase::run()` has been called. They might or might not be initial values of other modues. The control system adapter does not expect any specific behaviour. Entities writing to these variables do not need to take any special precautions.
6. Device variables:
1. Write accessors are written after the device is opened and the initialisation is done, as soon as the initial value is available for that variable. Initial values can be present through 5.a, 6.b, 6.c or 7.
2. Initial values for read accessors without AccessMode::wait_for_new_data are read after the device is openend and the initialsation is done.
3. Initial values for read accessors with AccessMode::wait_for_new_data are provided by the Device backend as the first value after the device has been opeend and asynchronous reads have been activated.
1. Write accessors are written after the device is opened and the initialisation is done, as soon as the initial value is available for that variable. Initial values can be present through 5.a, 6.b, 6.c or 7. [ \ref testD6_a1_InitialValue "T"]
2. Initial values for read accessors without AccessMode::wait_for_new_data are read after the device is openend and the initialsation is done. [ \ref testD6_b_InitialValue "T"]
3. Initial values for read accessors with AccessMode::wait_for_new_data are provided by the Device backend as the first value after the device has been opeend and asynchronous reads have been activated. [ \ref testD6_c_InitialValue "T"]
7. Outputs of `ApplicationModule`s:
1. Initial values can be written in `ApplicationModule::prepare()`, if the value does not depend on any input values (since input values are not available during `prepare()`).
2. Alternatively, initial values can be written in `ApplicationModule::mainLoop()` before calling any `read` function, if they depend on initial values of the inputs. Typically, to propagate the initial values of its inputs, an `ApplicationModule` will run its computations and write its outputs first before waiting for new data with a blocking `read()` and the end of the processing loop. The application author needs to take into account that the `ApplicationModule::mainLoop()` will only start after all inputs have their initial values available, which might depend on the avaialbility of devices.
1. Initial values can be written in `ApplicationModule::prepare()`, if the value does not depend on any input values (since input values are not available during `prepare()`). [ \ref testD7_1_InitialValue "T"]
2. Alternatively, initial values can be written in `ApplicationModule::mainLoop()` before calling any `read` function, if they depend on initial values of the inputs. Typically, to propagate the initial values of its inputs, an `ApplicationModule` will run its computations and write its outputs first before waiting for new data with a blocking `read()` and the end of the processing loop. The application author needs to take into account that the `ApplicationModule::mainLoop()` will only start after all inputs have their initial values available, which might depend on the avaialbility of devices. [ \ref testD7_2_InitialValue "T"]
3. Since in `ApplicationModule::prepare()` all devices are still closed, any writes to device variables at this point need to be delayed until the device is open. As the ExceptionHandlingDecorator takes care of this, the appciation module can just call write() on its output and does not have to do any special actions here (see \ref b_2_3 "Technical specification: Exception handling for device runtime errors B.2.3").
8. \anchor InitialValuesInputsOfApplicationCore_D_8 Inputs of `ApplicationModule`s [\ref testInitialValuesInputsOfApplicationCore "T"]:
1. Initial values are read by the framwork before the start of `ApplicationModule::mainLoop()` (but already in the same thread which later executes the `mainLoop()`).
...
...
@@ -62,7 +62,7 @@ This specification goes beyond ApplicationCore. It has impact on other ChimeraTK
1. The fan outs have a transparent behaviour, i.e. an entity that receives an initial value through a fan out sees the same behaviour as if a direct connection would have been realised.
2. \anchor initialValueThreaddedFanOut_D_9_b This implies that the inputs are treated like described in 8.b. [ \ref testInitialValueThreaddedFanOut_D_9_b "T for ThreadedFanOut"] [ \ref testInitialValueTriggerFanOut_D_9_b "T for TriggerFanOut"]
3. \anchor initialValue_d_9_3 The initial value is propagated immediately to the outputs. \ref initialValue_comment_d_9_3 "(*)"
1. Constant accessors only have one value, which is propagates as the intitial value. They conceptually behave like a process array that is written exactly once by the framework.
1. This implies that in case of `AccessMode::wait_for_new_data` the value can be read exactly once. This is enough to propagate the initial value. Any further read() to the variable will block infinitely.
2. Values are propagated before the `ApplicationModule` threads are starting (just like initial values written in `ApplicationModule::prepare()`)
