OperationModes.h

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-3749_Ability to set operation sub mode on DD subsystem
LEAHI-DD-FIRMWARE-LDT-3749_Ability to set operation sub mode on DD subsystem
LEAHI-DD-FIRMWARE-LDT-3627_[FP/DD VALVES] The valves sensed state values in the broadcast are always 1
LEAHI-DD-FIRMWARE-LDT-3627_[FP/DD VALVES] The valves sensed state values in the broadcast are always 1
That's a question for me, will that be required? Fault has sub modes(3), Standby has 1 sub mode(I am adding code for this as this might be required) Init don't have any and service is not defined yet

That's a question for me, will that be required?

Fault has sub modes(3), Standby has 1 sub mode(I am adding code for this as this might be required)
Init don't have any and service is not defined yet

Updated

Updated

Updated

Updated

Changed and left them as static, as we don't need these outside this unit

Changed and left them as static, as we don't need these outside this unit

You are right, (missed that while duplicating the functions)

You are right, (missed that while duplicating the functions)

if ( TRUE == result )

if ( TRUE == result )

Since both states require no special handling, remove breaks and group with default - all modes.

Since both states require no special handling, remove breaks and group with default - all modes.

Remove comment.

Remove comment.

Add comment that all of these states require no special handling.

Add comment that all of these states require no special handling.

I think these functions (validate and signal) should be "test" functions and moved down to Dialin test functions section below - for all modes.

I think these functions (validate and signal) should be "test" functions and moved down to Dialin test functions section below - for all modes.

Add comment that no action is required for these modes - defaulting to invalid request.

Add comment that no action is required for these modes - defaulting to invalid request.

I think this switch should be on requested mode - we haven't changed modes yet.

I think this switch should be on requested mode - we haven't changed modes yet.

We have 1 param (and probably should have 2 params - requested mode and submode).

We have 1 param (and probably should have 2 params - requested mode and submode).

currentMode is an input.

currentMode is an input.

I think this validate function needs to know the requested mode as well - should have 2 params.

I think this validate function needs to know the requested mode as well - should have 2 params.

Are we not supporting sub mode requests for these modes?

Are we not supporting sub mode requests for these modes?

if ( TRUE == testChangeSubMode )

if ( TRUE == testChangeSubMode )

I think these 2 functions are in support of Dialin only, so should be prefixed with "test" as well.

I think these 2 functions are in support of Dialin only, so should be prefixed with "test" as well.

See my comment above. We should return BOOL so Dialin request can be ACK/NAK'd.

See my comment above. We should return BOOL so Dialin request can be ACK/NAK'd.

No faults from Dialin commands - we never want Dialin to cause system to go to fault because it requested something invalid - we only NAK the invalid request. We should do whatever is needed (if an...

No faults from Dialin commands - we never want Dialin to cause system to go to fault because it requested something invalid - we only NAK the invalid request.
We should do whatever is needed (if anything) to start the mode normally in an else.
And we should return TRUE/FALSE in these signal functions so that when it's called from Dialin msg handler, the msg handler can return ACK/NAK to Dialin if sub mode is invalid.