Comment Search

fixed thanks

It looks like you have this as a T/F response from UI. UI should not be determining whether the modality matches - that's our job. UI should be telling us which type of tubing set was installed (HD or HDF type). Then when we get this response msg from UI, we will compare the type to the user selected modality (from TxParams) to see if it matches.

Put this one back to NUM_OF_BATTERY_DEVICES.

yes . but need to change from fill water state to IDLE state , and Vent state to IDLE state, implement common in a function and call from both state

Add comment.

this will always pass please use the lambda way..The updates to this test case are included in this branch. code review https://devapps.diality.us/cru/#LEAHI-TESTSUITES-LDT-3814-1CFR-86614

Can we revert all the changes to this branch and just use the other one to avoid conflicts

Yes,I Added the Dial-in override function for the publish interval.

Where are we updating the bpResults?

updated

Yes, these are low-priority alarms

fixed. thanks!

UPDATE INST GETTERS WITH

#define RANGEINSTSET()

RANGESET ()
READONLY( vTYPE , vVARIABLE##OrgMin, vDEFVALUE )
READONLY( vTYPE , vVARIABLE##OrgMax, vDEFVALUE )
READONLY( vTYPE , vVARIABLE##OrgDef, vDEFVALUE )

Remove this comment.

Rename to CanChannels

Use generic confirmation functions/messages.

Same here adding 'bicarbChamberPregenFillRequested' flag.

please remove this test case from this branch and review as its not part of this feature

Align the indent

Done.

Done.

Done.

That suggests that our coefficient(s) are too aggressive (in situations where it looks unstable). Not directly due to max step size, so we shouldn't reduce it for this reason. I believe 25 will negatively impact our responsiveness in situations where our error is larger than 25 mL/min.
So instability could be due to:
1) coefficient(s) are too strong or
2) may need more than one set of coefficients (e.g. coefficients need to change according to Qd or state or ... because the relationship between output and feedback changes)

These are redundant information from level and pressure module, we may remove them.

Done.

We will move towards 200 RPM being the minimum speed with updated Maxon controller. So, there is no need to maintain two different minimum RPM going forward.