The way we verify is that the o_PreTreatmentButton is only enabled when they are so testing that it is first enabled then mouse click the button then from fw send the td.td_Treatment_Parameters_Validation
It should no longer be called from OperationModes.c because we are deleted the TxParams mode (delete from enum and any switch statements in OperationModes.c).
I believe any related view could have provided a timer since they are inherited from QObject. That is fine for now but consider using our C++ view codes for such a thing.
EXPORT_LOG_TEXT constant belongs to Service Export Logs feature test script and may be needed to take after the translation by changing constant values
move into VInstitutitonal and create model there and read config file inside and populate. Change VTreatmentranges to Vinstitutional and add origignal macro
The view classes are QObject, and they already have an internal timer that you can start and use in the timer event. Therefore, this block of code needs to be moved to the timerEvent.
I have created a story as an enhancement to the date and time for the following:
Since the SW Board is the only reference for the clock, we now need to send the date and time to both the TD and DD every second as a broadcast message
That message should be on a general channel so both get it instead of two separate messages.
If SW won't update the TD every second, and with a different epoch, TD will raise an alarm
We only need to know, but SW does not need to do anything about it
The Alarm infrastructure will automatically handle it
If disconnected, TD will play the alarm sound and turn on the alarm light.
While we are sending the epoch as broadcast every second, and TD will raise an alarm if we don't, we need to get rid of the two requests, response messages, and send that epoch every second broadcast.
As has been mentioned above, we need to update the disabled date and time on NTP
When switched to NO NTP, stop updating.
A timezone needs to be added to the Date and time screen, since we already have NTP, so that we can update by timezone.
Another comment: don't the datetime conversion, 'toString' function is slow, and that we can pass integer values instead, since we are going to use it every second?
The test steps should reflect and match the sections on the generated report https://diality.atlassian.net/browse/LDT-1456. Please Update to align test outline with the sections to report and please upload a new report.
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)
