dgfirmware

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'DEN-13834-dg_hd_dev-hd_dg_dvt-update-part-3' into develop

DEN-13834 updated the fault mode

Alarm for invalid loadCellID?

Alarm for invalid loadCellID?

Should there be an alarm if loadCellID is invalid?

Should there be an alarm if loadCellID is invalid?

Why the change?

Why the change?

Merge branch 'DEN-13834-dg_hd_dev-hd_dg_dvt-update-part-3' of ssh://dvm-linux02:7999/dg/dgfirmware into DEN-13834-dg_hd_dev-hd_dg_dvt-update-part-3

    • -19
    • +7
    /firmware/App/Controllers/LoadCell.c
DEN-13834: Fixed loadcell range check.

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

Merged DEN-13834

    • -11
    • +21
    /firmware/App/Controllers/Heaters.c
    • -63
    • +85
    /firmware/App/Controllers/LoadCell.c
    • -11
    • +21
    /firmware/App/Controllers/Switches.c
    • -2
    • +2
    /firmware/App/Modes/ModeHeatDisinfect.c
  1. … 3 more files in changeset.
Merge branch 'DEN-13834-dg_hd_dev-hd_dg_dvt-update-part-3' of ssh://dvm-linux02:7999/dg/dgfirmware into DEN-13834-dg_hd_dev-hd_dg_dvt-update-part-3

    • -18
    • +44
    /firmware/App/Controllers/LoadCell.c
DEN-13834 added self test alarms

    • -10
    • +18
    /firmware/App/Controllers/FlowSensors.c
    • -1
    • +1
    /firmware/App/Controllers/FlowSensors.h
    • -19
    • +7
    /firmware/App/Controllers/LoadCell.c
    • -16
    • +35
    /firmware/App/Controllers/Pressures.c
DEN-13834: Added additional override of load cell after calibration but before filter/tare.

    • -15
    • +42
    /firmware/App/Controllers/LoadCell.c
DEN-13834: minor change to logging data of LC drift alarm.

Do we still need this? If so, can we make a s/w config instead?

Do we still need this? If so, can we make a s/w config instead?

Is this resolved?

Is this resolved?

Why are we not checking payload length?

Why are we not checking payload length?

If this function is not yet needed, should we remove or at least put a #ifdef PHASE_1B build flag around it? Otherwise this is dead code right now.

If this function is not yet needed, should we remove or at least put a #ifdef PHASE_1B build flag around it? Otherwise this is dead code right now.

Why are we not enforcing payload length check?

Why are we not enforcing payload length check?

Can this declaration be moved to top of function?

Can this declaration be moved to top of function?

Why are we hiding this condition from Vectorcast?

Why are we hiding this condition from Vectorcast?

This comment should precede the if statement above.

This comment should precede the if statement above.

Is this 109?

Is this 109?

This looks like 104 (not 106). And we should be noting every 5th enum anyway.

This looks like 104 (not 106). And we should be noting every 5th enum anyway.

Is this resolved now? Can we un-comment this code?

Is this resolved now? Can we un-comment this code?

Remove isPOSTComplete.

Remove isPOSTComplete.

Can we remove "TODO" since implementation is not required at this time. Re-phrase comment to something like "If temp sensors require calibration, implement here."

Can we remove "TODO" since implementation is not required at this time. Re-phrase comment to something like "If temp sensors require calibration, implement here."

POST does nothing? If always in progress, do we get stuck in this test?

POST does nothing? If always in progress, do we get stuck in this test?

Remove blank line.

Remove blank line.

Can these declarations be moved to top of function?

Can these declarations be moved to top of function?

Lets get this question answered. I don't see the harm in having a max flow. I can't imagine we're ever seeing that much flow, so not sure why this has to be commented out while we sort out its exis...

Lets get this question answered. I don't see the harm in having a max flow. I can't imagine we're ever seeing that much flow, so not sure why this has to be commented out while we sort out its existence.