Uncommented

Remove extra blank line.

Why is this service prefixed with "Tx"?
Also, Praneeth and I agreed to put these state machine services into a sub-folder of Services. See how he did it and do the same.

DrySelfTests unit.

DrySelfTests unit initialized.

Remove extra blank line.

.. handles dry self-tests execution for pre-treatment and treatment modes.

Should be in "", not <>. And should be placed alphabetically down before TxParams.h.

Calling signal function here seems circular (that's how we got here in the first place).
Shouldn't we set state to the install state here instead?

Put before TxParams.

I think Praneeth created a function for this. Make sure they're identical.

· /firmware/App/Services/TxDrySelfTests.c	(-1, +1)	| History	| Source	| Diff
· /firmware/App/Services/TxDrySelfTests.h	(-1, +1)	| History	| Source	| Diff

]]> Thu, 30 Apr 2026 14:19:30 -0700 Vendor - TEL - Varshini Nagabooshanam https://devapps.diality.us/changelog/td-firmware?cs=fc912ee48cf485f9ab861eb7ebc7d2f34533d76d https://devapps.diality.us/changelog/td-firmware?cs=fc912ee48cf485f9ab861eb7ebc7d2f34533d76d Vendor - TEL - Varshini Nagabooshanam committed fc912ee on branch LDT-2240-disposable-tube-set-self-test in td-firmware LDT-2240-disposable-tube-set-self-test

· /firmware/App/Modes/ModePreTreat.c	(-2, +1)	| History	| Source	| Diff
· /firmware/App/Services/TxDrySelfTests.c	(-2, +2)	| History	| Source	| Diff
· /firmware/App/Services/TxDrySelfTests.h	(-3, +3)	| History	| Source	| Diff

]]> Thu, 30 Apr 2026 13:36:23 -0700 Vendor - TEL - Varshini Nagabooshanam https://devapps.diality.us/changelog/td-firmware?cs=c8ea1e90f2ecdaffb0a8f6c909babc89e06f3cab https://devapps.diality.us/changelog/td-firmware?cs=c8ea1e90f2ecdaffb0a8f6c909babc89e06f3cab Vendor - TEL - Varshini Nagabooshanam committed c8ea1e9 on branch LDT-2240-disposable-tube-set-self-test in td-firmware LDT-2240-disposable-tube-set-self-test

· /firmware/App/Modes/ModePreTreat.c	(-3, +24)	| History	| Source	| Diff
· /firmware/App/Modes/ModePreTreat.h	(-0, +1)	| History	| Source	| Diff
· /firmware/App/Services/AlarmMgmtSWFaults.h	(-4, +5)	| History	| Source	| Diff
· /firmware/App/Services/Messaging.c	(-2, +1)	| History	| Source	| Diff
· /firmware/App/Services/TxDrySelfTests.c	(-0, +1222)	| History	| Source
· /firmware/App/Services/TxDrySelfTests.h	(-0, +55)	| History	| Source
· /firmware/App/Modes/StatePreTxDrySelfTests.c	(-1527, +0)	| History	| Source	| Diff
· /firmware/App/Modes/StatePreTxDrySelfTests.h	(-55, +0)	| History	| Source	| Diff

]]> Sun, 26 Apr 2026 15:41:53 -0700 Sean Nash https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-2240-1/#c28704 https://devapps.diality.us/cru/LEAHI-TD-FIRMWARE-LDT-2240-1/#c28704 Sean Nash replied to Vendor - TEL - Varshini Nagabooshanam in LEAHI-TD-FIRMWARE-LDT-2240-1

It looks like you deleted it instead of fixing it.

Need to request syringe pump to start a seek before we go to seek state. It's not implemented yet, so just put a TODO comment for now.

Need to check heparin bolus volume > 0 too.

Don't we need to check this too still?

Do we need to reset authStartTime here before we go to next state?

Put positive case first ( TRUE == ...), then alarm and reject cases.

No occlusion sensor in Leahi. Delete variable and references to it.

We should now send the scanned text to the UI s/w for authentication before we go to next state where we wait for UI response.

Remove extra l at end of flag name (mis-spelled). And why are we sending this flag with scan event? Seems like the Received flag is what you want here.

The barcode reader is under TD f/w control via the FPGA (not implemented yet). So asking UI s/w to do a scan doesn't make sense.

What is this flag for? And why is it only set here and not above where test passed.
Also, we are going to the loaded check state, but we are not requesting a scan first.

Local declarations should come first - move up above reset function above.

Leahi doesn't have occlusion sensor, so don't need this if statement. Not sure we need this start state. Maybe we can start in the wait for door close state.

start state function has same description as wait for door close state function. We shouldn't need 2 states to ensure door is closed.