Controllers

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
DEN-7605: disable syringe pump speed check if DISABLE_SYRINGE_ALARMS is defined.

  1. … 1 more file in changeset.
Addressed.

Addressed.

Addressed.

Addressed.

Compiler gives warnings with U32 casting, left code as is.

Compiler gives warnings with U32 casting, left code as is.

Addressed.

Addressed.

DEN-7860: Addressed code review comments

  1. … 1 more file in changeset.
Addressed.

Addressed.

Removed ADA/ADV bubble state test masks as there are no separate FPGA registers that output these variables.

Removed ADA/ADV bubble state test masks as there are no separate FPGA registers that output these variables.

Removed ADA/ADV bubble state test masks.

Removed ADA/ADV bubble state test masks.

v0.5.0.9036

  1. … 1 more file in changeset.
DEN-7605: Formalized several syringe pump changes.

  1. … 1 more file in changeset.
This seems to be conflict with FPGA_BLOOD_LEAK_ZERO_STATE_MASK if we are reading from the same FPGA gpio.

This seems to be conflict with FPGA_BLOOD_LEAK_ZERO_STATE_MASK if we are reading from the same FPGA gpio.

DEN-7605: Added syringe pump stall alarm.

DEN-7605: Fixes to retract stall check. Build switch for slower retract.

  1. … 1 more file in changeset.
Syringe pump retract stall handling. Will add to DEN-7605.

Syringe pump retract stall handling. Will add to DEN-7605.

Are we adding an alarm here later?

Are we adding an alarm here later?

It looks like you have not added these functions to SystemComm.c. They need to be added there otherwise the commands will not be handled.

It looks like you have not added these functions to SystemComm.c. They need to be added there otherwise the commands will not be handled.

Merge branch 'DEN-7605-hd_dg_dev-self-tests' into develop

DEN-7605: added build switch for flow sensor status check.

DEN-7605: Added check for syringe pump stall w/ retries.

  1. … 1 more file in changeset.
DEN-7860: Addressed part of code review comments

  1. … 3 more files in changeset.
I think this makes sense. We've done the same in other monitors/controllers like valves where there are several similar components handled in same driver.

I think this makes sense. We've done the same in other monitors/controllers like valves where there are several similar components handled in same driver.

Maybe cast the status params as U32 as well so there won't be an issue within the broadcast function (see my comment there for context).

Maybe cast the status params as U32 as well so there won't be an issue within the broadcast function (see my comment there for context).

For blood leak sensor, we didn't want to go to normal state until it was zeroed and self-tested. For bubble detector, do we want to be stuck in init state until self-test is requested? I think if w...

For blood leak sensor, we didn't want to go to normal state until it was zeroed and self-tested. For bubble detector, do we want to be stuck in init state until self-test is requested?
I think if we keep this state machine as is, we will want to request self-test in POST so that we can move on to normal state quickly. Then still request another self-test in each pre-treatment as we are now doing.

Should we broadcast both bubble detectors' data in one message?

Should we broadcast both bubble detectors' data in one message?

Same. Validate bubble param at top of function before using it. Then no need for else below.

Same. Validate bubble param at top of function before using it. Then no need for else below.

Should validate bubble param up top before you use it. S/W fault if invalid. Then don't need the else below.

Should validate bubble param up top before you use it. S/W fault if invalid. Then don't need the else below.

Initialize the other 3 fields of the override structure.

Initialize the other 3 fields of the override structure.

I agree we want to send the two status enums as a U32 over the CAN. I think it's better to assign w/ cast the two status to local U32s before memcpy into payload. That way, memcpy is given 4 bytes ...

I agree we want to send the two status enums as a U32 over the CAN. I think it's better to assign w/ cast the two status to local U32s before memcpy into payload. That way, memcpy is given 4 bytes to copy. As is, I worry compiler will only have 1 or 2 bytes for the enum passed into the function and we're forcing memcpy to copy 4 bytes - could corrupt the upper bytes of the two status fields in the message payload.