leahi-common

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Please add another sub condition for now that sub mode is in DD_POST_GEN_DIALYSATE_STATE_COMPLETE. Make sure you transition substate from Post gen start state to complete state for now to wait for ...

Please add another sub condition for now that sub mode is in DD_POST_GEN_DIALYSATE_STATE_COMPLETE. Make sure you transition substate from Post gen start state to complete state for now to wait for this request.

for now, keep this only related for disinfection cmds. for Post gen and standby. Follow the similiar messaging like pre-gen and gen dialysate requests and the reply back. ( but one message/handler )

for now, keep this only related for disinfection cmds.

for Post gen and standby. Follow the similiar messaging like pre-gen and gen dialysate requests and the reply back. ( but one message/handler )

are we rejecting this request for Aug Month demo, I guess, you still need to accept these requests and set the corresponding pending DD disinfect request flags.

are we rejecting this request for Aug Month demo, I guess, you still need to accept these requests and set the corresponding pending DD disinfect request flags.

Do we have a MSG_ID for the selection of disinfection? If not, lets rename and repurpose this one.

Do we have a MSG_ID for the selection of disinfection? If not, lets rename and repurpose this one.

MSG_ID_TD_DD_POSTGEN_STANDBY_REQUEST: to perform post gen and standby mode request transition.

MSG_ID_TD_DD_POSTGEN_STANDBY_REQUEST: to perform post gen and standby mode request transition.

Can we combine this state with prior state? Wait for DD response and mode change in same state?

Can we combine this state with prior state? Wait for DD response and mode change in same state?

Only need second condition I think.

Only need second condition I think.

This should be switch on requested selection and, in each case, we set next state to wait for disinfect state and set the appropriate command (if not skip) or set next state to wait for treatment (...

This should be switch on requested selection and, in each case, we set next state to wait for disinfect state and set the appropriate command (if not skip) or set next state to wait for treatment (if skip).

I think this should be more general start disinfection function that takes a specific disinfection command enum as a parameter.

I think this should be more general start disinfection function that takes a specific disinfection command enum as a parameter.

Shouldn't this be UI REQUEST message? Why would we need to receive/handle a message that we send?

Shouldn't this be UI REQUEST message? Why would we need to receive/handle a message that we send?

Do we need to send UI a response? Accept/reject?

Do we need to send UI a response? Accept/reject?

Is this a message handler? If so, parameter should be a message and option should be extracted from message payload.

Is this a message handler? If so, parameter should be a message and option should be extracted from message payload.

Does this command cause DD to transition to standby? It looks like the command to give when we transition into post treatment mode to tell DD to transition to post-gen dialysate mode.

Does this command cause DD to transition to standby? It looks like the command to give when we transition into post treatment mode to tell DD to transition to post-gen dialysate mode.

Switch not needed here. Just signal standby mode with the received selection.

Switch not needed here. Just signal standby mode with the received selection.

Should be disinfection selection type, not command type. Also, move this down into if statement scope.

Should be disinfection selection type, not command type.
Also, move this down into if statement scope.

Why are we signaling a command to standby mode? We should signal the selection that we received from UI. Standby mode (later when we get there) will then look at the selection and decide there whic...

Why are we signaling a command to standby mode? We should signal the selection that we received from UI. Standby mode (later when we get there) will then look at the selection and decide there which command to send to DD.

Remove blank line.

Remove blank line.

Won't this happen when we transition to auto-eject state? Why do it here?

Won't this happen when we transition to auto-eject state? Why do it here?

Shouldn't auto-eject state handle this BP homing?

Shouldn't auto-eject state handle this BP homing?

Why are we worried about "handled"? Once confirmed, should we just go to auto eject state?

Why are we worried about "handled"? Once confirmed, should we just go to auto eject state?

Why is this if statement separated from the one above? Why not just do this stuff in that if statement?

Why is this if statement separated from the one above? Why not just do this stuff in that if statement?

There should be function(s) in DDInterface to tell DD what we want (bypass, Qd, etc...).

There should be function(s) in DDInterface to tell DD what we want (bypass, Qd, etc...).

This publish code should be in a publish function and we just call that function here.

This publish code should be in a publish function and we just call that function here.

Add comment to right.

Add comment to right.

Why is this above the definitions banner?

Why is this above the definitions banner?

This signal function looks like a message handler. If so, it should take a message (like handlers below) and get the option from the message payload.

This signal function looks like a message handler. If so, it should take a message (like handlers below) and get the option from the message payload.

Needs comment to right.

Needs comment to right.

Is TD going to request active cooling or is it going to happen automatically after heat or heat+citric disinfection completes? You have an enum of heat disinfection commands, so why do we need sepa...

Is TD going to request active cooling or is it going to happen automatically after heat or heat+citric disinfection completes?
You have an enum of heat disinfection commands, so why do we need separate messages for each disinfection? Should just be 1 message to start a disinfection with a command enum as its payload.