LEAHI-DD-FIRMWARE-LDT-2004

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?

Add a blank line after public defs banner. Add a dox comment to the right. I believe they reserve space for 12 bytes, not 10. Not really for calibration - it's for s/n and versions.

Add a blank line after public defs banner.
Add a dox comment to the right.
I believe they reserve space for 12 bytes, not 10.
Not really for calibration - it's for s/n and versions.

Are these really going to be different types? I assumed they would all be floats.

Are these really going to be different types? I assumed they would all be floats.

Structures need a top level dox comment.

Structures need a top level dox comment.

enums need a top level dox comment.

enums need a top level dox comment.

I believe conductivity and temperature data will be F32s.

I believe conductivity and temperature data will be F32s.

Do we not need this anymore? I still see it in code all over the place and I don't think we're done w/ Teensy until Beta 1.9 units are obsolete.

Do we not need this anymore? I still see it in code all over the place and I don't think we're done w/ Teensy until Beta 1.9 units are obsolete.

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.

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 ?