Dashboard

Added comments

Removed Denali reference

    • -12
    • +12
    /leahi_dialin/dd/dialysate_delivery.py
    • -10
    • +10
    /leahi_dialin/dd/modules/alarms.py
    • -12
    • +12
    /leahi_dialin/dd/modules/blood_leak.py
    • -11
    • +11
    /leahi_dialin/dd/modules/concentrate_pump.py
    • -11
    • +11
    /leahi_dialin/dd/modules/conductivity_sensors.py
    • -10
    • +10
    /leahi_dialin/dd/modules/drybicart.py
    • -10
    • +10
    /leahi_dialin/dd/modules/gen_dialysate.py
  1. … 61 more files in changeset.
Do we not need the module error alarm?

Do we not need the module error alarm?

This is not an atomic assignment, so we have to consider thread safety. If this driver is running from General Task (I believe it is since ModeTreatment's exec will be calling the BPModule's exec w...

This is not an atomic assignment, so we have to consider thread safety.
If this driver is running from General Task (I believe it is since ModeTreatment's exec will be calling the BPModule's exec which calls this driver's exec) and if the caller to this function will also be running from General Task (I believe it is since BPModule controller is the caller), then there is no thread safety issue and we should mention in the function header brief that this function should only be called from within the General Task.
If another task is involved (e.g. Priority Task is calling this function), this function could be interrupting the get data state while it is populating bpResults with new results and the caller would get a mix of old and new results (we would not want that).

LDT-3215-measured-venous-pressure-decreases

LDT-3215-measured-venous-pressure-decreases

    • -10
    • +39
    /firmware/App/Controllers/AirPump.c
LEAHI-COMMON-LDT-2004_Dialysate Composition - DD
LEAHI-COMMON-LDT-2004_Dialysate Composition - DD
LEAHI-COMMON-LDT-2004_Dialysate Composition - DD
LEAHI-COMMON-LDT-2004_Dialysate Composition - DD
LEAHI-FWCOMMON-LDT-2004_Dialysate Composition - DD
LEAHI-FWCOMMON-LDT-2004_Dialysate Composition - DD
LEAHI-DIALIN-LDT-2004_Dialysate Composition - DD
LEAHI-DIALIN-LDT-2004_Dialysate Composition - DD
same.

same.

same.

same.

Just like driver state machine, we should only set a request flag to TRUE here and let the state machine handle the transition.

Just like driver state machine, we should only set a request flag to TRUE here and let the state machine handle the transition.

How do we get out of Idle state?

How do we get out of Idle state?

This should be called in all states (so in controller's exec function).

This should be called in all states (so in controller's exec function).

I don't think we want to zero this count here.

I don't think we want to zero this count here.

We need to call the driver exec function from this exec function - either before or after the switch statement.

We need to call the driver exec function from this exec function - either before or after the switch statement.

LDT-1886: Update event related code

We need to call this from ModeTreatment transition function.

We need to call this from ModeTreatment transition function.

We need to call this function from ModeTreatment exec function.

We need to call this function from ModeTreatment exec function.

Remove blank line.

Remove blank line.

LDT-4456 Edit Treatment Parameters During Treatment - SW - 01 - Integration - R&I - 05: DEV - Feature Implementation

update venous window ranges

s/w fault needs alarm data. See other examples.

s/w fault needs alarm data. See other examples.

Why do you have { here?

Why do you have { here?

For init function, just say "BPModule variables initialized."

For init function, just say "BPModule variables initialized."

The driver has one of these too. Does the controller need to store the results when it can ask the driver for them?

The driver has one of these too. Does the controller need to store the results when it can ask the driver for them?

I'm not sure we need these "Detected" functions. I would expect that when this controller gets new readings, it will check for these alarm conditions in the check state and trigger alarm if appropr...

I'm not sure we need these "Detected" functions. I would expect that when this controller gets new readings, it will check for these alarm conditions in the check state and trigger alarm if appropriate. So if we are triggering alarms in this controller, there is no need for outside code to ask if these alarms are detected.

I think these will eventually be coming from institutional settings, so maybe put a TODO comment to remove these when institutional settings are available.

I think these will eventually be coming from institutional settings, so maybe put a TODO comment to remove these when institutional settings are available.