This is a list of all comments for HD-DENBUG-298-1. Review Summary: No summary ---------------------------------------- File: AlarmDefs.h Revision Comment by Sean Nash on 21 March 2025, 10:33 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21823 These alarms we're demoting from HD fault should have their ranks demoted to 110 (like DG faults). Reply by Sean Nash on 25 March 2025, 09:33 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 18 March 2025, 13:31 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21771 Change to "available" properties (e.g. priority low). ---------------------------------------- File: firmware/App/Modes/ModeTreatment.c Revision Comment by Sean Nash on 07 March 2025, 11:16 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21695 Probably not this simple. We need to consider how much UF volume we've done so far and how much Tx time is remaining. So rate = ( presMaxUFVolumeML - collectedUFVolumeML ) / treatmentTimeRemaining. I made up var names for all but the first in equation above, but just showing how the calculation should go. You can look at UF volume change (where we are changing UF rate to accomodate the change) for reference. Reply by Dara Navaei on 07 March 2025, 13:21 > Done Reply by Sean Nash on 07 March 2025, 14:13 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 07 March 2025, 11:21 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21696 Do we need to set presUFRate here (instead of volume)? Reply by Dara Navaei on 07 March 2025, 12:56 > Done Reply by Sean Nash on 07 March 2025, 14:14 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 04 April 2025, 12:37 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21894 Bad practice to have two calls to same function here. Possible that 2nd call will return different result. Should call function once to assign value to a local var prior to if statement and then reference the local var in the if statement. Reply by Dara Navaei on 04 April 2025, 12:47 > Done Reply by Sean Nash on 04 April 2025, 12:50 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 26 March 2025, 09:21 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21835 2 blank lines above/below test banner. Reply by Dara Navaei on 26 March 2025, 17:52 > Done Reply by Sean Nash on 28 March 2025, 10:25 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: firmware/App/Modes/Dialysis.c Revision Comment by Sean Nash on 14 March 2025, 09:45 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21738 Remove function prototype. Reply by Dara Navaei on 14 March 2025, 09:57 > Done Reply by Sean Nash on 18 March 2025, 08:53 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 14 March 2025, 16:31 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21746 Is this condition right? What if we're in wait for pumps stop state? What state will saline bolus exec be in when we're done? Idle, right? Shouldn't we wait for that? Reply by Dara Navaei on 17 March 2025, 10:52 > Changed the code. Reply by Sean Nash on 18 March 2025, 08:54 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 14 March 2025, 09:48 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21739 Are we removing maximum saline bolus volume limit? Reply by Dara Navaei on 17 March 2025, 10:52 > Yes, it is removed. Reply by Sean Nash on 18 March 2025, 08:55 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: firmware/App/Modes/SalineBolus.c Revision Comment by Sean Nash on 20 March 2025, 09:06 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21812 Why doesn't treatment stop publish saline bolus (like dialysis)? Reply by Sean Nash on 21 March 2025, 08:41 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 20 March 2025, 09:07 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21813 Also reject if in treatment stop state and recovering from blood leak alarm. Reply by Dara Navaei on 20 March 2025, 14:17 > Done Reply by Sean Nash on 21 March 2025, 08:43 > Condition is not right. Blood leak recover is only > relevant in treatment stop state, so we shouldn't care > about that state if we're in dialysis. Reply by Sean Nash on 25 March 2025, 09:37 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 25 March 2025, 09:36 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21829 Last condition is wrong (dialysate recirc blocked). Should be no rinseback. Reply by Dara Navaei on 25 March 2025, 09:41 > Done Reply by Sean Nash on 26 March 2025, 09:28 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 20 March 2025, 09:09 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21814 I think it would be better to reject here if the saline bolus exec is IDLE (indicates there is no saline bolus in progress to abort). I don't want to pend an abort flag (and open pressure limits) when no bolus in in progress. Reply by Dara Navaei on 20 March 2025, 14:17 > The saline bolus state is checked in the below else if Reply by Sean Nash on 21 March 2025, 08:50 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: firmware/App/Modes/TreatmentStop.c Revision Comment by Sean Nash on 20 March 2025, 09:04 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21811 Do we reject saline bolus request if blood leak recovery is in progress? I think we should. I don't want a saline bolus requesting pending while blood leak recover is happening. Reply by Dara Navaei on 20 March 2025, 14:19 > Done Reply by Sean Nash on 21 March 2025, 08:53 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 14 March 2025, 13:36 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21743 What are we doing here? Reply by Dara Navaei on 14 March 2025, 14:52 > The rest of the conditions will be filled up. Reply by Sean Nash on 14 March 2025, 16:45 > Need to check to see if start bolus signal (request) is > pending. As written, we will always go to saline bolus > state from any other state. Reply by Sean Nash on 18 March 2025, 09:11 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: firmware/App/Services/SystemCommMessages.c Revision Comment by Sean Nash on 28 March 2025, 10:54 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21839 For other confirmations, an executive (e.g. alarm mgmt monitor or standby mode exec) is responsible for checking confirmation status and we don't call specific handlers from here. Why can't we follow that design pattern for this confirmation? Reply by Dara Navaei on 28 March 2025, 13:15 > Moved it to OperationModes Reply by Sean Nash on 28 March 2025, 13:17 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: Compatible.h Revision Comment by Sean Nash on 18 March 2025, 13:30 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21770 Execute TODO. Reply by Sean Nash on 01 April 2025, 08:34 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: HDDefs.h Revision Comment by Sean Nash on 03 April 2025, 09:00 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21885 Are these permanent? Reply by Dara Navaei on 04 April 2025, 10:54 > Yes. I think we should have these events to information. Reply by Sean Nash on 04 April 2025, 12:26 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: firmware/App/Modes/Rinseback.c Revision Comment by Sean Nash on 18 March 2025, 10:45 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21764 Update comment to remove max. Reply by Dara Navaei on 18 March 2025, 10:46 > Done Reply by Sean Nash on 18 March 2025, 10:56 > RESOLVED in CODE WALKTHROUGH. Revision Comment by Sean Nash on 18 March 2025, 10:46 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21766 Did you remove this reject reason enum? Reply by Dara Navaei on 18 March 2025, 10:49 > Yes Reply by Sean Nash on 18 March 2025, 10:52 > RESOLVED in CODE WALKTHROUGH. ---------------------------------------- File: firmware/App/Modes/OperationModes.c Revision Comment by Sean Nash on 28 March 2025, 13:17 https://devapps.diality.us/cru/HD-DENBUG-298-1#c21842 Add comment explaining what we're doing here. Reply by Sean Nash on 31 March 2025, 09:05 > RESOLVED in CODE WALKTHROUGH. --- ID: HD-DENBUG-298-1 https://devapps.diality.us/cru/HD-DENBUG-298-1 Title: HD-DENBUG-298_User Unable TO Deliver Saline Bolus During Alarm Conditions Where The Blood Pump IS Recirculating Statement of Objectives: State: Closed Summary: Author: Dara Navaei Moderator: Dara Navaei Reviewers: (4 active, 2 completed*) Sean Nash (*) Michael Garthwaite (*) jpaguio Vinayakam Mani amanesh Daniel Ho