Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
BatteryStatusData is an input.

BatteryStatusData is an input.

fpgaPersistentAlarmGroup is an input.

fpgaPersistentAlarmGroup is an input.

Are all available ALARM_IDs being removed?

Are all available ALARM_IDs being removed?

OK, I see what you wanted. I have a couple of questions: Is logging of the 3 values (remaining charge, battery status, charger status) in a separate message every 750 ms correct? If so, could that ...

OK, I see what you wanted. I have a couple of questions:
Is logging of the 3 values (remaining charge, battery status, charger status) in a separate message every 750 ms correct?
If so, could that be done by calling the publishBatteryStatusData function when the 3rd value (charger status) is read?

Restore alarm when done.

Restore alarm when done.

I think we should just be calling one function to do a single read at a time. If you try to read multiple times back-to-back, the bus reports busy and the read fails. I would keep call to getBatter...

I think we should just be calling one function to do a single read at a time. If you try to read multiple times back-to-back, the bus reports busy and the read fails. I would keep call to getBatteryManagementData() function with the large switch statement as it was with everything there and remove getBatteryStatusData() function altogether.

Keep multiple reads of remaining capacity and status in the switch as before.

Keep multiple reads of remaining capacity and status in the switch as before.

Keep read for battery charger status here before end of list.

Keep read for battery charger status here before end of list.

Dong fixed this.

Dong fixed this.

Need to save data to dataPtr so calling function gets the data.

Need to save data to dataPtr so calling function gets the data.

I think the enum from commit fbb6603 was fine as it was. I still think we should be doing only 1 read per 250ms interval and I think the one function with the large switch statement based on these ...

I think the enum from commit fbb6603 was fine as it was. I still think we should be doing only 1 read per 250ms interval and I think the one function with the large switch statement based on these enums was the way to achieve that - with the multiple status1..5 and remaining capacity1..5 enums spaced out to get them read more frequently.
And I think the individual cases for the higher frequency registers could just call the high frequency broadcast function whenever a new value is read for those registers. And so the slower broadcast could stay at end of list in that switch statement.

Update function header.

Update function header.

Do we want this checked into staging?

Do we want this checked into staging?

These are defined in the Code Composer project for DG and HD firmware respectively. You can only have one defined and you must have one defined.

These are defined in the Code Composer project for DG and HD firmware respectively. You can only have one defined and you must have one defined.

What is the purpose of this "no event" event?

What is the purpose of this "no event" event?

What is the purpose of this "no event" event?

What is the purpose of this "no event" event?

No stop property for a high priority alarm? PRS 754 says dialysate temperature alarms are low priority. Temp too low = rank 902. Temp too high = rank 901.

No stop property for a high priority alarm?
PRS 754 says dialysate temperature alarms are low priority. Temp too low = rank 902. Temp too high = rank 901.

Why no stop?

Why no stop?

Why no stop?

Why no stop?

For DG faults, let's be consistent. DG fault = TRUE Clear Immediate = TRUE (alarm condition moot because DG going to fault mode) Stops = TRUE (HD pauses treatment for alarm) No Clear = FALSE (so HD...

For DG faults, let's be consistent.
DG fault = TRUE
Clear Immediate = TRUE (alarm condition moot because DG going to fault mode)
Stops = TRUE (HD pauses treatment for alarm)
No Clear = FALSE (so HD can clear alarm when user selects option)
No Resume = TRUE (cannot resume treatment w/o functioning DG)
No Rinseback = FALSE (no reason to prevent patient getting their blood back just because DG failed)
No End Treatment = FALSE (should try to end treatment as normally as possible w/o DG - won't be able to drain reservoirs though)
No Blood Recirc = FALSE (why not recirc blood?)
No Dialysate Recirc = TRUE (may not be possible depending on what's wrong w/ DG)
Clear Only = FALSE

Faults (HD and DG) should probably be consistent on clear immediate concept. I think faults should be TRUE on clear immediate (going to fault mode anyway, so alarm condition isn't relevant after th...

Faults (HD and DG) should probably be consistent on clear immediate concept. I think faults should be TRUE on clear immediate (going to fault mode anyway, so alarm condition isn't relevant after that).

No stop property for a high priority alarm?

No stop property for a high priority alarm?

It seems correct to me.

It seems correct to me.

No this line is a temporary line until the pump control is fixed so the 100 mL/min can be achieved.

No this line is a temporary line until the pump control is fixed so the 100 mL/min can be achieved.

It is a const because we want it to be calculated upon compilation and be kept in memory. #define does the calculations every time it is called.

It is a const because we want it to be calculated upon compilation and be kept in memory. #define does the calculations every time it is called.

Both cannot be and are not defined at the same time.

Both cannot be and are not defined at the same time.

It is up to date.

It is up to date.

It is up to date.

It is up to date.

Done.

Done.

Done.

Done.