This is allowed only here: dc-data is valid (i.e. check for E255 was
sucessfull).
This method sub_componentAssessment() will check all criteria of
dc-module conditions.
- handle E255 in previousMachineEventSet (because machineEventSet will
be cleared regularely)
- do not call finishDiag() on E255 because this will interscect
previous- with current machineEventSet and thus remove all Errors/
Warnings because machineEventSet was cleared and includes only E255!
This states are rather meta infos about dc condition. Therefore the
where created and sent outside of superviseSystem()-method.
This commit should ensure that:
- this states are sent to ISMAS
- this states are inserted in machineEventSet in order to enable
a reset in next diagRun
- O000 is not a direct result from DC
- O000 is constructed in DCDiag, if no Error EXXXX and no Warning WXXXX
ocurred
-> O000 must not be part of machineEventSet (e.g. O000 can not be
reset)
... this is an DC-Plugin internal data-structure which can be
transformed to an ATBMachineEvent and sent to ISMAS.
DCMachineEvent is in fact a couple ot DeviceController::State and a
QString eventID.
Thi eventID is necessary to send a state-reset to ISMAS. ISMAS needs
same enventID for set- and reset Events.
- start BackgroundTask on first data not valid
- in any case of E255/data-no-valid: try to restart diag;
This is because there were only 'returns' without initiating
something, so that next check/restart carun happened first on next
wokeup.
... this prevents sending Operate "O000" in case of an opend door and
enables sending Operate "O000" after closing all doors because
'lastResult' has not changed.
Reading dc-fw-version is somehow complicated ...
Id does not work reliable on startup, so we do read it also on every
diagRequest().
Version string is then stored in persistent data.
This data can be used e.g. by other tools to show the
device-controller-firmware-version.
