SystemComm.c

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'DEN-8103-dg-hd_dev-alarm-design' into develop

  1. … 5 more files in changeset.
Merge branch 'staging' into DEN-8103-dg-hd_dev-alarm-design

  1. … 25 more files in changeset.
DEN-8030 added messages and code to publish the status of the disinfects from DG

  1. … 9 more files in changeset.
DEN-7605: Local merge with staging.

  1. … 10 more files in changeset.
RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

Per Dara Navaei, we will need to implement this functions.

Per Dara Navaei, we will need to implement this functions.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

Good point. Test will need to be longer than 50ms anyway - FPGA ramps the sound and there is a ~250ms time constant in the electronics. But I will want the sound to at least get started immediately.

Good point. Test will need to be longer than 50ms anyway - FPGA ramps the sound and there is a ~250ms time constant in the electronics. But I will want the sound to at least get started immediately.

Should we call setAlarmAudio here? This test is running at 50 ms while the setAlarmAudio is running at 250 ms. The alarm audio might not be set when we switch to else part.

Should we call setAlarmAudio here?
This test is running at 50 ms while the setAlarmAudio is running at 250 ms. The alarm audio might not be set when we switch to else part.

The flag is latched by using OR with the local updated noNewTreatment status.

The flag is latched by using OR with the local updated noNewTreatment status.

But now in order to use the status flag, I think we can't allow that flag to go from TRUE to FALSE - need to latch it.

But now in order to use the status flag, I think we can't allow that flag to go from TRUE to FALSE - need to latch it.

Removed this extra flag and used alarm status noNewTreatment flag.

Removed this extra flag and used alarm status noNewTreatment flag.

Removed this extra flag.

Removed this extra flag.

Done.

Done.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

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.