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.

I meant that you should move this function up, not init function down.

Change to initDrySelfTests() and move to top (should be first function).

prime state not yet implemented. comment this out w/ TODO comment and add an assignemtn to Rx state here for now.

Why is this commented out?

Remove blank line.

Move this transition function call to the transitionToPostTreatmentMode function below.

Invalid payload length shouldn't be a reject reason, it should cause a s/w fault (because it suggests the UI and TD software are not compatible versions).

Still not what I had in mind. Let's discuss this.

We can set bolus volume here now. These functions should be moved to TxParams where all of these settings exist and can be updated.

Why does confirm msg have duration again? If UI resends duration, we have to validate it again. If UI just sends confirmation of previously sent duration, we don't have to validate it again.

These are already in TxParams I believe.

Should these be moved to Services\TxParams?

Change 1 to TRUE

Agree with name change, but I think BOOL was the correct type. And BOOL is equivalent to U32 anyway so compiler won't care.

I think these message handlers for editing treatment parameters should be moved to Services\TxParams.