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, .....
The approach of what this code does and the conversion module are similar in function but a differ on maintenance and flexibility. 1. The conversion module's bytearray to value methods work, but they require manual logistic around the indexing. It's the user's responsibility to handle where the reading starts and you need to code the handler for that (previous approach with MsgFieldPositions), It's inflating the method. I worked hard to remove the need for indexing where the value starts. Instead of the previous struct.unpack approach, where you needed to maintain the type, you will be needing to maintain the conversion methods that are being called, so it would be the same as before, you still need to mind the indexing, which was the main reason of changing from this approach.
2. In the current approach, you declare the type and pass it to a processor that dynamically handling the unpack type (based on the set datatype) and the indexing for that. This works much better and easier to maintain, as you can just insert a new value when it's added to the FW, and don't need to adjust all your indexes for the reading.
Example #1, changing build type from U16 to U08:
with the conversion approach, you need to change the function used, and update the starting index for all the following methods.
with the current approach you change the Datatype.U16 to Datatype.U08 and that's all you need to do.
Example #2: adding a new variable fpga_micro after fpga_minor, with U08 type:
with the conversion approach, you add the bytearray_to_byte, update the indexes for all the following reads.
with the current approach you insert an element after the fpga_minor with a value ('fpga_micro', Datatype.U08), and nothing more needed
You are running release
CR4.8.14
FE4.8.14
(20240111091859 2024-01-11 09:20),
please report your release number when reporting bugs.
