it will be adjusted when I merge latest staging

not required anymore, forgot to remove

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).

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.

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 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?

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

What alarm is this? It doesn't look like you've added a new alarm. This is one of the reserved (unused) alarms that UI s/w might use.

Do we really need these setup functions for each state? They all look very simple - just 1 or 2 lines of code.

I believe the SyringePump controller will trigger this alarm at end of seek operation.

Syringe pump should already be stopped if preload is done. Do we need to call this here?

This is called from preload state. Not needed here I think.

Don't put comments on function prototypes. Doxygen gets details of functions from the function header.

Why (void)?

Where is this being called? Should be called from pre-treatment init I think.

Confirmation signal sounds like a message handler from UI. Message handlers must accept a message as parameter and return BOOL. They must also be added to the message handler table in Messaging.c.

Why are we signaling syringe load confirmed here?

Do these states need to be public?

Move up one row to alphabetize.

I would keep blank line between library includes and regular includes.

We can't have 2 alarms with ID 196. The enum only has the empty saline bag alarm. Looks like alarm 197 is duplicate of this 196 alarm you've added.
I think you should just remove this new alarm 196 that you've added here.

· /AlarmDefs.h	(-2, +2)	| History	| Source	| Diff
· /MsgDefs.h	(-2, +2)	| History	| Source	| Diff
· /TDDefs.h	(-1, +1)	| History	| Source	| Diff

]]> Thu, 02 Jul 2026 15:06:54 -0700 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-2 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-2 Vendor - TEL - Jashwant Gantyada and Sean Nash finished reviewing LEAHI-TD-FIRMWARE-LDT-4013-2 LEAHI-TD-FIRMWARE-LDT-4013_Fluid Bolus - FW Implementation - 2/4: ]]>