We need to look for user request to resume from pause where we would restart BP (at last rate we were at before pause) and re-open art/ven pinch valves and transition back to either ramp or run state (whichever state we were in when we paused).
These are the correct min/max values, but we can't use literals like this. Our coding standard calls these "magic numbers". What we want to do is call getU32TreatmentParamLowerRangeLimit() and getU32TreatmentParamUpperRangeLimit() functions from the TxParams service.
Level.c is a higher level abstracted functions and should not implement the HW dependent details in this file. this details should be pushed to FPGADD. and single function should handle all the cases instead of multiple functions.
# handler for messages from UI to FW
def handle_patient_vitals_request( message, timestamp = 0.0):
"""
Called when the user requests to firmware from UI
@return: None
"""
global vitalsrequest
vitalsrequest = True
The intent is to synchronize. If the user clears either the popup Rx or the pretreatment create Rx then only that instance was clearing before. Not both. So now when we initiate the clear (when back to standby "onStandbyChanged" or when the "Clear All" option is selected in prescription ) the order is (Q_INVOKABLE call ) vTreatmentCreate.doClear() -> (c++ signal) emit didClear() -> (slot in qml) onDidClear() -> (QML method) _root.clear(). The _root.clear() is inside the PreTreatmentCreateContent so all instances of it will get cleared at the same time synchronizing them and this removes that stack dependency linking all those clear methods down to the same _root.clear
Thanks for the clarification. No need for any extra notification, that would be redundant then. Although it is not used, since its pair (pass) is used, let's keep the fail signal. RESOLVED.
move this to the Variables to make sur the same is typed always and use the code completion qml checks. keep the qsTr in the Variables.qml definitions.
Or define in here (same qml) if not used anywhere else.
We shouldn't request op mode until we're sure we're happy with the whole thing. Need to determine whether we are already in the op mode being requested. If so, no need to request it again - just request new sub mode if not already in it. If not, the currentSubMode checked below is not relevant (applies to current mode, not the requested mode) and we need to request new op mode and signal that new op mode that we will want to start in a specific sub mode.
Just a heads up that all message handling functions in Leahi have the same prototype - just different function names (i.e. BOOL funcName( MESSAGE_T *message)) and that includes all Dialin command message handlers like these.
Yes, without checking the changes in this file, I pushed it. It is OK when I merge the code. There is no option to correct since my local branch shows 28.its auto generated and it will take next version during the merge with staging.
Now updated to first Standby then click on Settings menu, then Service Mode as already logged with password before, then click on feature configuration option td_simulator.td_operation_mode(TDOpModes.MODE_STAN.value, 0) headerbar_container = waitForObject(names.o_mainMenu_MainMenu, 3000) mouseClick(utility.findChildByText(headerbar_container, config.SETTINGS))
Could you use update instead of sync, for consistency, since it has not been used anywhere for that purpose, and also sync is mainly used for cloud data communications? For all the accuracies <Sync>All, Synchronize, sync, .....
Michael Garthwaite: Can we remove the M4 valve controls (across) in DD and keep it only as part of the IO/FP? So that the M4 valve actuation is done by one entity.
