Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.

Mis-spelled "Stabilized".

Mis-spelled "Stabilized".

I think you can do this in 1 line of code using the RANGE macro in Common.h.

I think you can do this in 1 line of code using the RANGE macro in Common.h.

LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
What should trimmer heater be doing in these spent/bicarb chamber states?

What should trimmer heater be doing in these spent/bicarb chamber states?

I would think this would be enabled by default.

I would think this would be enabled by default.

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

  1. … 10 more files in changeset.
fixed. Removed ifdef as well as it is no longer applies here since we are retrieving the data from the monitor which has the #ifdefs for teensy.

fixed. Removed ifdef as well as it is no longer applies here since we are retrieving the data from the monitor which has the #ifdefs for teensy.

I think using filtered values for alarms makes sense.

I think using filtered values for alarms makes sense.

we need filtered values for various applications in the system. My question is should we be checking dialysate temperature using a filtered value or a sample point? This version showed that we want...

we need filtered values for various applications in the system. My question is should we be checking dialysate temperature using a filtered value or a sample point? This version showed that we want a sample point.

in Denali, looks like the HD got the filtered temperature value from the DG for checking dialysate temp alarms. Are we upholding that same design of using a filtered value for leahi dialysate temp?

I don't see fix. Did you push fwcommon?

I don't see fix. Did you push fwcommon?

Restore this blank line.

Restore this blank line.

Remove all of these blank lines please.

Remove all of these blank lines please.

Removed the ifdef here as these overrides still be used without breaking the teensy driver. I can add it on request. Unsure if teensy will be tested long enough for them to use those overrides. In...

Removed the ifdef here as these overrides still be used without breaking the teensy driver.
I can add it on request. Unsure if teensy will be tested long enough for them to use those overrides.

In the meantime,

MSG_ID_DD_FILTERED_COND_SENSOR_READINGS_OVERRIDE_REQUEST and MSG_ID_FP_FILTERED_COND_SENSOR_READINGS_OVERRIDE_REQUEST are still available to override the monitor/filtered data.

fixed.

fixed.

fixed.

fixed.

Not here. This include was not in the right spot as we want the two drivers to be separated. the include is in the monitor

Not here. This include was not in the right spot as we want the two drivers to be separated. the include is in the monitor

Temperature monitor only has getter's for d4 and d50 at the moment. It looks like that hasnt been refactored to consider all temp sensors.

Temperature monitor only has getter's for d4 and d50 at the moment. It looks like that hasnt been refactored to consider all temp sensors.

for Teensy it is done at the driver as it is a part of the initialization sequence. See TEENSY_CMD_GET_EEPROM_DATA cmd.

for Teensy it is done at the driver as it is a part of the initialization sequence. See TEENSY_CMD_GET_EEPROM_DATA cmd.

Not at the moment. This feature isnt expected to on the V2's. The v2's arent going to have ALY_LINEAR as that is one specific to the teensy sensors.

Not at the moment. This feature isnt expected to on the V2's. The v2's arent going to have ALY_LINEAR as that is one specific to the teensy sensors.

#ifdef TEENSY for these new functions.

#ifdef TEENSY for these new functions.

Only needed for TEENSY, right? So #ifdef should be applied.

Only needed for TEENSY, right? So #ifdef should be applied.

No model selection for V2 sensor?

No model selection for V2 sensor?

Teensy driver doesn't need overrides too?

Teensy driver doesn't need overrides too?

Probably shouldn't have "TEENSY" in the name. Non-teensy driver will probably need this too, so can be generic.

Probably shouldn't have "TEENSY" in the name. Non-teensy driver will probably need this too, so can be generic.