Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove extra blank line.

Remove extra blank line.

It is your comment, so please resolve it.

It is your comment, so please resolve it.

It is replied by Vinay , there is no need to maintain two different rpm. so we can close this.

It is replied by Vinay , there is no need to maintain two different rpm. so we can close this.

It will be fixed in Balancing chamber re-implementation

It will be fixed in Balancing chamber re-implementation

I would prefer to fix this in balancing chamber new algorithm implementation. That is why i didn't mark it as Unresolved.

I would prefer to fix this in balancing chamber new algorithm implementation. That is why i didn't mark it as Unresolved.

Merge branch staing into LDT-2004-drybicarb---dd

  1. … 17 more files in changeset.
fixed it

fixed it

fixed it

fixed it

This state machine running continuously. fill request is initiated for every 1 minutes of balancing chamber exec (since right now level sensor is not working ) //Increment counter for dry bicarb c...

This state machine running continuously. fill request is initiated for every 1 minutes of balancing chamber exec (since right now level sensor is not working )

//Increment counter for dry bicarb chamber fill
bicarbChamberPeriodicFillCounter += 1;
// Fill bicarb chamber once every 60secs.
if ( bicarbChamberPeriodicFillCounter >= BICARB_CHAMBER_PERIODIC_FILL_TIME )

Unknown macro: { setBicarbChamberFillRequested(); bicarbChamberPeriodicFillCounter = 0; }


The request is cleared here. for consistency I am moving to the end of the fill cycle

LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
Why is this flag set to FALSE here in start state while the other request flags are set to FALSE in their completed states?

Why is this flag set to FALSE here in start state while the other request flags are set to FALSE in their completed states?

Should there be any constraints to setting these request flags to TRUE? What if drain request is still in progress for example? Shouldn't drain finish before fill starts? This wouldn't be an issue ...

Should there be any constraints to setting these request flags to TRUE? What if drain request is still in progress for example? Shouldn't drain finish before fill starts?
This wouldn't be an issue if we combined the 3 state machines.

Complex conditional expressions can be avoided. Introduce temporary boolean variables instead. for example if ((elementNo < 0) || (elementNo > maxElement)|| elementNo == lastElement){ … } should b...

Complex conditional expressions can be avoided. Introduce
temporary boolean variables instead.

for example
if ((elementNo < 0) || (elementNo > maxElement)||
elementNo == lastElement)

Unknown macro: { … }


should be replaced by:
isFinished = (elementNo < 0) || (elementNo > maxElement);
isRepeatedEntry = elementNo == lastElement;
if ((isFinished == TRUE) || (isRepeatedEntry == TRUE))

its rate , pump speed in ml/min

its rate , pump speed in ml/min

Fixed.

Fixed.

When flag is true and Drain complete , it remains in the DRY_BICART_FLUID_DRAIN_END_STATE, when it is cleared, it go back to DRY_BICART_DRAIN_START_STATE Its fixed now

When flag is true and Drain complete , it remains in the DRY_BICART_FLUID_DRAIN_END_STATE, when it is cleared, it go back to DRY_BICART_DRAIN_START_STATE
Its fixed now

It looks to me like the state machine (drain for example) will keep running so long as the flag is true. I would think it should set the flag to false when drain is done.

It looks to me like the state machine (drain for example) will keep running so long as the flag is true. I would think it should set the flag to false when drain is done.

right now, only bicarbChamberFillRequested is cleared during the supply. dryBiCartFillRequested and dryBiCartDrainRequested has a Fill/Drain complete state and it remains in that state to check com...

right now, only bicarbChamberFillRequested is cleared during the supply. dryBiCartFillRequested and dryBiCartDrainRequested has a Fill/Drain complete state and it remains in that state to check completion state programmatically. an explicit clear request is required to start the next operation. Do I need to clear it ?

Where do these request flags get set back to FALSE after request is serviced?

Where do these request flags get set back to FALSE after request is serviced?

Why is drain request flag different (ends in "ed")?

Why is drain request flag different (ends in "ed")?

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.

quantity? Is this volume or rate or ...?

quantity? Is this volume or rate or ...?

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.