@@ -30,7 +30,7 @@ If an input variable is in the error state, it sets the DataValidity flag for it
<b>2. The Flow</b>
- 2.1. The application always starts with all devices as closed and initial value for deviceError.status is set to 1. The DeviceModule takes care that ExceptionHandlingDecorators do not perform any read or write operations, but block. This must happen before running any prepare() of an ApplicationModule, where the first write calls to ExceptionHandlingDecorators are done.
- 2.1. The application always starts with all devices as closed and initial value for deviceError.status is set to 1 and a device.message is send that the device has not been opened yet. The DeviceModule takes care that ExceptionHandlingDecorators do not perform any read or write operations, but block. This must happen before running any prepare() of an ApplicationModule, where the first write calls to ExceptionHandlingDecorators are done.
- 2.2 In ApplicationModule::prepare() some initial values (and constants) are written. As the ExceptionHandlingDecorator must not perform the actual write at this point, it will put the value into the dataRecoveryAccesssor and report an exception to the DeviceModule.
...
...
@@ -66,7 +66,7 @@ If an input variable is in the error state, it sets the DataValidity flag for it
- writeWithoutErrorBlocking: just returns (*)
- 2.6 The exception is received in the DeviceModule thread
- 2.6.1 deviceError.status will be set to 1. From this point on, all ExceptionHandlingDecorators for this device must block new read and write operations from starting (see also 2.2 and 2.3.6).
- 2.6.1 deviceError.status will be set to 1. The first received exception message is send to device.message(). From this point on, all ExceptionHandlingDecorators for this device must block new read and write operations from starting (see also 2.2 and 2.3.6).
- 2.6.2 The device module waits until all running read and write operations have ended (*)
- 2.6.3 The thread goes back to 2.3.1 and tries to re-open the device.