I don't see any change here. How does this function get called? I don't see the function being used anywhere - nobody is calling it. I think it should be called by Messaging.c when a UI confirmation msg is received.

I thought we'd removed the first 3 states. Isn't install state the first state? Maybe Praneeth did that and it will show up when you merge staging into your branch.

171

Who is calling this function? Should be coming from UI, right? So should be a message handler (returns BOOL, takes a message as param, function is in table at top of Messaging.c).

Need to set state to preload state I think. Otherwise you will go to interrupted state.

Why did you remote call to init function here? Is it initialized somewhere else?

Use ternary operation to assign TRUE or FALSE explicitly.

This is at end of enum list above. So it should be at end of table here.

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.

Why are we signaling syringe load confirmed here?

Do these states need to be public?

Move up one row to alphabetize.

· /firmware/App/Controllers/AirPump.c	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Modes/ModeStandby.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/ModeStandby.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Modes/StateTxPaused.c	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/AlarmMgmtSWFaults.h	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/AlarmMgmtTD.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/StateServices/FluidBolus.c	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/StateServices/FluidBolus.h	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/StateServices/TubeSetAutoEject.c	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/StateServices/TubeSetAutoEject.h	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/StateServices/TubeSetInstall.c	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/StateServices/TubeSetInstall.h	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/SystemCommTD.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/TxParams.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/TDCommon.h	(-2, +2)	| 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: ]]> Thu, 02 Jul 2026 14:42:11 -0700 Sean Nash https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-2/#c30350 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-4013-2/#c30350 Sean Nash commented on LEAHI-TD-FIRMWARE-LDT-4013-2

Align =

Should modality be an enum type?

Align =

Should this be an enum type?

What is the 3rd modality?

Return type should be an enum (TREATMENT_TYPE_T).

Return type should be an enum (FLUID_BOLUS_MEDIUM_T).