ModeTreatment.h

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
it will be adjusted when I merge latest staging

it will be adjusted when I merge latest staging

not required anymore, forgot to remove

not required anymore, forgot to remove

I think a comment here is needed. Keep it and maybe mention rinseback alarm responses too.

I think a comment here is needed. Keep it and maybe mention rinseback alarm responses too.

Maybe this should be handled in OperationModes exec since it applies to all confirmations (not just alarm related ones).

Maybe this should be handled in OperationModes exec since it applies to all confirmations (not just alarm related ones).

There will be confirmations that are not handled here (e.g. power off). So we shouldn't fault in default - we should do nothing.

There will be confirmations that are not handled here (e.g. power off). So we shouldn't fault in default - we should do nothing.

Shutdown would be handled somewhere else (buttons.c probably). It's not related to alarms.

Shutdown would be handled somewhere else (buttons.c probably). It's not related to alarms.

Is this still possible since we're not returning to TxPaused from rinseback anymore?

Is this still possible since we're not returning to TxPaused from rinseback anymore?

Is rinseback completed an indication that we've done a blood prime following a temporary break? If so, I guess this makes sense, but we have to do more than increase the UF volume. We have to adjus...

Is rinseback completed an indication that we've done a blood prime following a temporary break?
If so, I guess this makes sense, but we have to do more than increase the UF volume. We have to adjust the UF rate so that we will reach the new (larger) UF volume when the treatment completes.
We also need to add RB volume to UF volume in pre-tx when treatment parameters are given/validated (for the final rinseback which we will always have so we should just plan for it before treatment starts).

What if multiple confirmations pending? Which ID will this function return?

What if multiple confirmations pending? Which ID will this function return?

Align comments. Should substitution pump data be moved down to 0xBA instead of commented out?

Align comments.
Should substitution pump data be moved down to 0xBA instead of commented out?

LEAHI-TD-FIRMWARE-LDT-4040_Rinseback - FW Implementation - 3/10:
LEAHI-TD-FIRMWARE-LDT-4040_Rinseback - FW Implementation - 3/10:
Bamboo Commit: Updated the Copyright section and replaced tabs with 4 spaces

  1. … 21 more files in changeset.
LDT-4013: Merge latest staging into LDT-4013, resolved merge conflicts and addressed CR comments

  1. … 12 more files in changeset.
Should this check be moved to the fluid bolus exec function?

Should this check be moved to the fluid bolus exec function?

LDT-4013: Refactored and updated logic.

  1. … 6 more files in changeset.
Maintain alphabetical order.

Maintain alphabetical order.

Eliza says we do allow multiple iso UF sessions in a treatment. So do we still need this else if, but looking at <= iso UF elapsed session time?

Eliza says we do allow multiple iso UF sessions in a treatment. So do we still need this else if, but looking at <= iso UF elapsed session time?

What about HDF?

What about HDF?

Once UI software sends the volume and/or duration change request and once we change them, the UI software will send another request to confirm the displayed settings to the user and that is what is...

Once UI software sends the volume and/or duration change request and once we change them, the UI software will send another request to confirm the displayed settings to the user and that is what is being handled in this function.

return result;

return result;

Keep local result and set to TRUE or FALSE with a ternary.

Keep local result and set to TRUE or FALSE with a ternary.

Which setting does this message confirm (duration or volume)?

Which setting does this message confirm (duration or volume)?

Align comment.

Align comment.

where are we calling an alarm? i think we are only sending event change data in completeBolusToCumulative() right?

where are we calling an alarm?
i think we are only sending event change data in completeBolusToCumulative() right?

do we need this block?

do we need this block?