TEST_CONFIG_DD_FP_ENABLE_BETA_1_0_HW = 0, ///< Test configuration DD & FP enable Beta 1.0 hardware TEST_CONFIG_FIRST = TEST_CONFIG_DD_FP_ENABLE_BETA_1_0_HW, ///< Test configuration first configuration. TEST_CONFIG_DD_DISABLE_BC_PRESSURE_ALARMS, ///< Test configuration DD disabling BC pressure alarms TEST_CONFIG_DD_ENABLE_DRY_BICARB, ///< Test configuration DD to use dry bicarb TEST_CONFIG_DD_ENABLE_4WIRE_RINSE_PUMP, ///< Test configuration DD enable 4-wire rinse pump. TEST_CONFIG_FP_SKIP_PRE_GEN_FLUSH, ///< Test configuration FP skip pre-gen flush TEST_CONFIG_DD_ENABLE_DIENER_1000_PUMP, ///< Test configuration to use diener 1000 pump for D48 TEST_CONFIG_DD_ENABLE_D79_PWM_CONTROL, ///< Test configuration to switch to PWM control for D79 TEST_CONFIG_DD_ENABLE_SPENT_CHAMBER_H_FILL, ///< Test configuration DD enable spent chamber H fill TEST_CONFIG_DD_DISABLE_CONDUCTIVITY_ALARMS, ///< Test configuration to disable DD conductivity alarms TEST_CONFIG_FP_DISABLE_CONDUCTIVITY_ALARMS, ///< Test configuration to disable FP conductivity alarms TEST_CONFIG_DD_ENABLE_DOSING_OPEN_LOOP_CONTROL, ///< Test configuration to switch to open loop control for concentrate dosing TEST_CONFIG_DD_ENABLE_UF_TEMP_COMPENSATION, ///< Test configuration for enabling UF temperature compensation NUM_OF_TEST_CONFIGS ///< Number of test configuration.
When flag is true and Drain complete , it remains in the DRY_BICART_FLUID_DRAIN_END_STATE, when it is cleared, it go back to DRY_BICART_DRAIN_START_STATE Its fixed now
I think cal data and count should be retrieved by same function and possibly needs some interrupt protection to ensure data and count stick together. If these functions are called from general task, we could have situation where data is retrieved, then priority task updates fpga, and then counter is retrieved with wrong (incremented) counter. If these two functions are being called from a driver that is executed in priority task, then we don't need to worry about this situation, but still ought to add a constraint/warning comment in function headers noting that these functions should only be called from priority task.
Are we sure about the reversing of states here? If we had this backward, I would think the Systems team would have had a much bigger complaint. The description of their issue suggests that the 8 BC valves were correctly commanded to requested state except for the one they separately commanded earlier. If we had this backward, I would think they would have said that all 8 valves did the wrong thing.
Obviously not. You were reminding me about backwards compatibility. This variable and class ensures that even with this major refactor to the enum structure, the current codebase remains working.
You are running release
CR4.8.14
FE4.8.14
(20240111091859 2024-01-11 09:20),
please report your release number when reporting bugs.
