Added

Updated

Add a blank line after declarations.

What I meant was that we don't care which blood prime state we're in - what we care about is that we are in treatment mode and priming blood - otherwise this message doesn't make sense and we should reject it because we're not in the right state.
if ( ( MODE_TREA == getCurrentOperationMode() ) && ( TREATMENT_BLOOD_PRIME_STATE == getTreatmentState() ) )

Removed

Added

Yes, Updated

Replaced

This should be invalid state (or something like that).

These are the correct min/max values, but we can't use literals like this. Our coding standard calls these "magic numbers". What we want to do is call getU32TreatmentParamLowerRangeLimit() and getU32TreatmentParamUpperRangeLimit() functions from the TxParams service.

I think what matters is that we are in Treatment: Blood Prime state. I think any of the 3 blood prime states is ok for this message.

I think result and accepted are essentially the same. We should just have one flag and only set to TRUE if everything is correct.

Updated

Still need to range check the rate, reject if out of range, accept and assign if in range.

I should have said "before test messages" instead of "first". But where you put them is fine so I will resolve.

Updated

Assigned to local variable

Updated to else part

I’ve updated the logic to explicitly set bloodPrimeResumeState when transitioning out of ramp (including flow change), so resume will always return to the correct prior state.

Updated

Actually, I think we should have the local variable to copy the payload into, then we should range check it (and potentially reject it if out of range), and if it is in range, only then should we assign new rate to your static variable.

I think this can just be an else since resume is the only remaining possibility.

Should we set resume state here? I know it's initialized to ramp state already, but in case we come back to ramp it may be safer to set it here.

You moved it, but didn't change anything. The comment says it's a timer counter but the variable name suggests it is actually a flow rate. I want you to fix the comment.

I think system messages (non Dialin (test) functions should come first in this table so that they are found faster.

Added

Updated