Why alarm if above low temp? I think >42 or > tgt+4 should be two ways to get same non-safety high temp alarm. And I think <33 or < tgt-4 should be two ways to get same non-safety low temp alarm. Did Systems want to separate these? My understanding was not to separate.
Concern was originally just for retract due to highest speed. We ended up reducing retract speed to reduce likelihood of stalls. Still a good idea to check for it though and since retract, preload and seek all share same relatively high speed, these are the ops that have the check. For bolus and continuous, should not stall at these speeds and would catch with rate alarm if it did.
FALSE will be determined by our automagic script to be ACK_REQUIRED in the excel sheet. This will cause discrepancies between the readers of that sheet and what the FW does.
If you clear immediately, it will let you resume/clear alarm immediately (before temp comes back into range), but then alarm will re-trigger immediately (because temp is still out of range).
if we dont meet an expected condition. Later in the handler we will call a response message with the response message calling: serializeMessage( msg, COMM_BUFFER_OUT_CAN_DG_2_HD, ACK_REQUIRED );
2. sendAckResponseMsg( (MSG_ID_T)message->hdr.msgID, COMM_BUFFER_OUT_CAN_HD_2_UI, result );
a conditional based on?
Please review the FW_Message_list.csv within latest develop & staging builds to understand how the automated script is determining "ack requireness"
