dd-firmware

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
LDT-3223-dialysate-flow-rate---dd---mode-tel-dev-test : Updated test cases asper peer review findings for BalancingChamber.c file

LDT-3223-dialysate-flow-rate---dd---mode-tel-dev-test : Committed vcm and tst file for concentratepumps file

LDT-2004-3 Limits execution to one active dry bicart state machine at any given time

    • -15
    • +148
    /firmware/App/Controllers/DryBiCart.c
Done.

Done.

Done

Done

Since trimmer heater is enabled, no need of temp compensation. only for testing purposes, temp compensation is needed. Hence by default, temp compensation is disabled.

Since trimmer heater is enabled, no need of temp compensation. only for testing purposes, temp compensation is needed. Hence by default, temp compensation is disabled.

For spent chamber fill, we don't know how low the liquid level is ( in Chamber H) and hence decided not to turn on the trimmer heater for safety reasons. For bicarb fill, the dry bicart code should...

For spent chamber fill, we don't know how low the liquid level is ( in Chamber H) and hence decided not to turn on the trimmer heater for safety reasons. For bicarb fill, the dry bicart code should cover the actuators status. the current bicarb chamber fill code here should be updated with the newly implemented dry bi cart code changes.

LDT-1473 code review comments

Bamboo Commit: Updated DDCommon.h with build versions from Bamboo.

Merge branch 'LDT-2030-blood-leak-refactor---dd' into develop

Bamboo Commit: Updated DDCommon.h with build versions from Bamboo.

Bamboo Commit: Updated the Copyright section and replaced tabs with 4 spaces

    • -2
    • +2
    /firmware/App/Controllers/PermeateTank.c
LDT-3343 merged into staging

LDT-2030 removed static variables to update the values used by monitor and driver

    • -7
    • +9
    /firmware/App/Drivers/BloodLeakDriver.c
    • -1
    • +1
    /firmware/App/Drivers/BloodLeakDriver.h
Fixed it

Fixed it

LDT-2004-3 removing blank line

LDT-3343 added condition for DD to wait for FP to start preGen

LDT-3343 updated function header

Updated

Updated

Fixed

Fixed

LDT-3223-dialysate-flow-rate---dd---mode-tel-dev-test : Added testcases for ConcentratePumps file

I think cal data and count should be retrieved by same function and possibly needs some interrupt protection to ensure data and count stick together. If these functions are called from general task...

I think cal data and count should be retrieved by same function and possibly needs some interrupt protection to ensure data and count stick together. If these functions are called from general task, we could have situation where data is retrieved, then priority task updates fpga, and then counter is retrieved with wrong (incremented) counter.
If these two functions are being called from a driver that is executed in priority task, then we don't need to worry about this situation, but still ought to add a constraint/warning comment in function headers noting that these functions should only be called from priority task.

Remove extra blank line.

Remove extra blank line.

It is your comment, so please resolve it.

It is your comment, so please resolve it.

I think Dialin will need get (or UI proxy) commands to have us send cal, s/n, and versions.

I think Dialin will need get (or UI proxy) commands to have us send cal, s/n, and versions.

Do FP sensors have to be treated separately? I realize there needs to be separate messages as they will be coming from different Dialin classes, but can't we handle both messages with same function...

Do FP sensors have to be treated separately? I realize there needs to be separate messages as they will be coming from different Dialin classes, but can't we handle both messages with same function (assuming shared enum to index)?

General Dialin question - does it make sense to override temperatures at driver level where they are spread out over several drivers? I would think overriding at monitor level would be simpler wher...

General Dialin question - does it make sense to override temperatures at driver level where they are spread out over several drivers? I would think overriding at monitor level would be simpler where they are all in one place and could be indexed by enum with single command.

Do we need to say Value?

Do we need to say Value?