fwcommon

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
DEN-6200: Align variables

With the new design of persistent alarm, we no longer need to keep a separate list of persistent alarm id. Therefore, these have been deleted.

With the new design of persistent alarm, we no longer need to keep a separate list of persistent alarm id. Therefore, these have been deleted.

The first part of dialysate prime actually waits for reservoir 1 to be complete and become active.

The first part of dialysate prime actually waits for reservoir 1 to be complete and become active.

Why and where were these persistent alarm moved to?

Why and where were these persistent alarm moved to?

Remove extra spaces before = sign.

Remove extra spaces before = sign.

Do we need to wait until we're done with first part of dialysate prime (or at least check to make sure it's already done) before we switch reservoirs?

Do we need to wait until we're done with first part of dialysate prime (or at least check to make sure it's already done) before we switch reservoirs?

Is half fill appropriate for both reservoirs? I think we need a TODO here to determine the fill volume we want for each reservoir and I believe they will be different in the end so we probably need...

Is half fill appropriate for both reservoirs? I think we need a TODO here to determine the fill volume we want for each reservoir and I believe they will be different in the end so we probably need two #defines here.

What if DG does not go to drain mode (e.g. DG rejected drain command)? We will get stuck in this state. Let's discuss DG command handling - we may need to add more to DG response so HD can handle t...

What if DG does not go to drain mode (e.g. DG rejected drain command)? We will get stuck in this state. Let's discuss DG command handling - we may need to add more to DG response so HD can handle these types of issues.

I think we want to be broadcasting priming progress (% complete or maybe est. time (in secs) countdown) during prime (really prime+wet self-tests) so UI can show progress. Peter may have already de...

I think we want to be broadcasting priming progress (% complete or maybe est. time (in secs) countdown) during prime (really prime+wet self-tests) so UI can show progress. Peter may have already defined a msg for this. Consider what else may need to be broadcast during prime for Dialin purposes.

I know, but the clearing occurs before the mode gets this signal (see signalAlarmUserActionInitiated() in AlarmMgmt.c). So you don't need to clear it again here.

I know, but the clearing occurs before the mode gets this signal (see signalAlarmUserActionInitiated() in AlarmMgmt.c). So you don't need to clear it again here.

Where is alarmIsActive[] input in the code?

Where is alarmIsActive[] input in the code?

Done.

Done.

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.

I think the flow rate out of range alarm should be handled by the RO pump driver.

I think the flow rate out of range alarm should be handled by the RO pump driver.

I think this wrapper should stay with DG or HD, so they can have their own implementation.

I think this wrapper should stay with DG or HD, so they can have their own implementation.

I think we want to drain reservoir all the way now that we're moving away from the straw concept. Let's discuss this.

I think we want to drain reservoir all the way now that we're moving away from the straw concept. Let's discuss this.

I think clearing off alarm is handled when user chooses an action (resume, ACK, end Tx, ...). I don't think you need to clear these alarms here.

I think clearing off alarm is handled when user chooses an action (resume, ACK, end Tx, ...). I don't think you need to clear these alarms here.

Why only this one alarm? I think wherever possible, we want to be more general about alarm user actions. If user chooses to end treatment in response to any alarm that didn't block that option, we ...

Why only this one alarm? I think wherever possible, we want to be more general about alarm user actions. If user chooses to end treatment in response to any alarm that didn't block that option, we should allow it.

Add more constraints. Should not accept start treatment request if we haven't completed all pre-treatment steps through to patient connection at the end.

Add more constraints. Should not accept start treatment request if we haven't completed all pre-treatment steps through to patient connection at the end.

Do we need to broadcast anything during pre-treatment mode? I think sub-mode states are already broadcast elsewhere, but think about any Dialin needs.

Do we need to broadcast anything during pre-treatment mode? I think sub-mode states are already broadcast elsewhere, but think about any Dialin needs.

Maybe just call init function above in case other inits get added there?

Maybe just call init function above in case other inits get added there?

TODO?

TODO?

Do you think this function should be moved to PersistentAlarm.c?

Do you think this function should be moved to PersistentAlarm.c?

Updated logic flow to make variable name easier to understand and less confusing.

Updated logic flow to make variable name easier to understand and less confusing.

DEN-6200: Make start time more clear and fix spelling error

errorOccurredStartTime is confusing name considering how it's being used.

errorOccurredStartTime is confusing name considering how it's being used.

Added HD_ prefix.

Added HD_ prefix.