AlarmDefs.h

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Yes, and we checked for DG restarted (after it has started by HD) in DGInterface. Sample water sub-mode has to check before DG started.

Yes, and we checked for DG restarted (after it has started by HD) in DGInterface.
Sample water sub-mode has to check before DG started.

Looks like you are latching the noEndTreatment status. Maybe we can have that status be latching so we don't need two flags.

Looks like you are latching the noEndTreatment status. Maybe we can have that status be latching so we don't need two flags.

Is this different than alarmStatus.noNewTreatment?

Is this different than alarmStatus.noNewTreatment?

Shouldn't this be checked more broadly (not just in water sample sub-mode)?

Shouldn't this be checked more broadly (not just in water sample sub-mode)?

Removed.

Removed.

I think rather than 37, these should be the lowest high priority rank (i.e. 49) so we can add new alarms and not have to renumber these. Also, I think the range for high priority alarms should have...

I think rather than 37, these should be the lowest high priority rank (i.e. 49) so we can add new alarms and not have to renumber these. Also, I think the range for high priority alarms should have room for more than 50 alarms. Maybe high priority could be 1..499, medium priority 500..599, and low priority 600..699.

Dara, do we need these handlers or not?

Dara, do we need these handlers or not?

We should delete this dead code as well.

We should delete this dead code as well.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

Changed to use treatmentTimeMS to increase the log time.

Changed to use treatmentTimeMS to increase the log time.

Removed. UI will be the logger, so the clock comes from only one source.

Removed. UI will be the logger, so the clock comes from only one source.

It took around 55 ms for the largest section (.text). I have imposed a maximum size per each CRC calculation, which takes around 7 ms each.

It took around 55 ms for the largest section (.text). I have imposed a maximum size per each CRC calculation, which takes around 7 ms each.

Done.

Done.

Done.

Done.

Removed.

Removed.

Done.

Done.

Change PERIOD to PERIODIC?

Change PERIOD to PERIODIC?

How long does this take? We may need to break this loop into smaller pieces and have ModeInitPOST call this function multiple times so that general task does not take too long (> 40ms or so). Other...

How long does this take? We may need to break this loop into smaller pieces and have ModeInitPOST call this function multiple times so that general task does not take too long (> 40ms or so). Otherwise, watchdog will not get pet within its ~50ms window and expire - and also other general and background operations will be blocked until this test is completed.