common

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fixed comment typo.

Fixed comment alignment.

DG-DEN-5980_Non Volatile Data Management (2 of 2)
DG-DEN-5980_Non Volatile Data Management (2 of 2)
Fair point.

Fair point.

Consider returning a OPN_CLS_STATE_T instead of BOOL for readability.

Consider returning a OPN_CLS_STATE_T instead of BOOL for readability.

What is this state? Where did it get set? Why aren't we going back to recirc state?

What is this state? Where did it get set? Why aren't we going back to recirc state?

Can this wait for door close be a state within the self-test no cartridge sub-mode? Also need to wait for user to open the door at the end of self-test no cartridge sub-mode or beginning of cartrid...

Can this wait for door close be a state within the self-test no cartridge sub-mode? Also need to wait for user to open the door at the end of self-test no cartridge sub-mode or beginning of cartridge install sub-mode and then close the door again at end of cartridge install sub-mode. I see that some of these sub-modes don't have states, but probably should or will eventually. The 3 self-test sub-modes can have their own state machines in SelfTests.c. I think Recirc and Cartridge Install sub-modes may need their own .c files (PreTreatmentRecirc.c and DisposableInstall.c?) with state machines of their own as well.

Move execPrime() to end - only if no door open and no alarm stop signal.

Move execPrime() to end - only if no door open and no alarm stop signal.

Check for door open before running self-tests. Really, self-test execution should go last and only if no door open and no stop signal.

Check for door open before running self-tests. Really, self-test execution should go last and only if no door open and no stop signal.

For no cartridge self-tests, all failures result in a fault because they are essentially POST tests.

For no cartridge self-tests, all failures result in a fault because they are essentially POST tests.

Are these the only two alarms possible in this state? Consider using the alarm stop signal here instead of checking specific alarm status.

Are these the only two alarms possible in this state? Consider using the alarm stop signal here instead of checking specific alarm status.

And if we fail self-tests? Where do we go? Are all failures a fault?

And if we fail self-tests? Where do we go? Are all failures a fault?

Should we check door before we run the self tests?

Should we check door before we run the self tests?

I think there are a few things that need to happen in patient connection sub-mode (e.g. get UF volume, get initial blood pressure reading, ...) before user should be allowed to start treatment. Nee...

I think there are a few things that need to happen in patient connection sub-mode (e.g. get UF volume, get initial blood pressure reading, ...) before user should be allowed to start treatment. Need to check which state in patient connection sub-mode we're in too - should the last state where we've done everything and waiting for user to start.

What is happening in this sub-mode that can be resumed?

What is happening in this sub-mode that can be resumed?

I think this function is too big. I generally prefer to have static functions to call for each case unless it's a one-liner to keep the switch state from getting too big.

I think this function is too big. I generally prefer to have static functions to call for each case unless it's a one-liner to keep the switch state from getting too big.

1) When we fail this test, we only alarm to let the user know and take action. 2) We should. The alarms activation will be moved into this function.

1) When we fail this test, we only alarm to let the user know and take action.
2) We should. The alarms activation will be moved into this function.

So in this dry test, I guess if any one of these is out of range we can say something is wrong with the way the cartridge was loaded. Should we try to distinguish between improperly loaded cartridg...

So in this dry test, I guess if any one of these is out of range we can say something is wrong with the way the cartridge was loaded. Should we try to distinguish between improperly loaded cartridge and no cartridge loaded (all 3 occlusions are < threshold)?

If the flow sensor is bad, we will go to fault. In this case, the calibration does not matter anymore.

If the flow sensor is bad, we will go to fault. In this case, the calibration does not matter anymore.

Capitalize state

Capitalize state

Is this a maximum? Also, add _MMHG to end to indicate units of pressure.

Is this a maximum? Also, add _MMHG to end to indicate units of pressure.

Is there no upper limit for arterial or lower limit for venous pressure?

Is there no upper limit for arterial or lower limit for venous pressure?

Add _MS to end to indicate units of time. Also, is this a self-test for blood pump occlusion sensor? If so, maybe replace "PRESSURE" with "OCCLUSION" to clarify.

Add _MS to end to indicate units of time. Also, is this a self-test for blood pump occlusion sensor? If so, maybe replace "PRESSURE" with "OCCLUSION" to clarify.

Add _MS to end to indicate unit of time.

Add _MS to end to indicate unit of time.

Add _ML_MIN to end to indicate units.

Add _ML_MIN to end to indicate units.

Name is too vague. Make it clear this minimum is for occlusion sensors. And also if this minimum applies to narrower scope(s) (like no cartridge or dry or wet) or is it general and should never be ...

Name is too vague. Make it clear this minimum is for occlusion sensors. And also if this minimum applies to narrower scope(s) (like no cartridge or dry or wet) or is it general and should never be less than this?

Same comment as in BloodFlow.c

Same comment as in BloodFlow.c

So if calibration is good but flow sensor is bad, we won't apply calibration? I think these two checks should be separated. Start test as passed. Then fail if either check is failed.

So if calibration is good but flow sensor is bad, we won't apply calibration? I think these two checks should be separated. Start test as passed. Then fail if either check is failed.

Any reason why pause state can't be part of patient connection state?

Any reason why pause state can't be part of patient connection state?

Why do we need this start state? For modes, we have the transitionTo...() functions that get called automatically before starting a new mode. For sub-modes and their states, the general approach sh...

Why do we need this start state? For modes, we have the transitionTo...() functions that get called automatically before starting a new mode. For sub-modes and their states, the general approach should be to handle transition logic at the same point the code changes the sub-mode/state. You can consider a separate transition state like this if there are a lot of states that could transition to this state or if the transition is very complex, but this one doesn't seem to fit either category.