-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue2884 pid autotuning #2957
base: master
Are you sure you want to change the base?
Issue2884 pid autotuning #2957
Conversation
Buildings/Controls/OBC/CDL/Continuous/Validation/AMIGOWithFOTD.mo
Outdated
Show resolved
Hide resolved
Buildings/Controls/OBC/CDL/Continuous/Validation/AMIGOWithFOTD.mo
Outdated
Show resolved
Hide resolved
Buildings/Controls/OBC/CDL/Continuous/Validation/AMIGOWithFOTD.mo
Outdated
Show resolved
Hide resolved
Buildings/Controls/OBC/CDL/Continuous/Validation/PIDWithAutoTuning.mo
Outdated
Show resolved
Hide resolved
Buildings/Controls/OBC/CDL/Continuous/Validation/PIDWithAutoTuning.mo
Outdated
Show resolved
Hide resolved
Buildings/Resources/Scripts/Dymola/Controls/OBC/CDL/Continuous/Validation/PIDWithAutoTuning.mos
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SenHuang19: This requires considerable more work. Please also see the email I sent.
…OBC.Utilities package
Issue2884 pid autotuning
…/modelica-buildings into issue2884_PID_autotuning
<p> | ||
<b>Note:</b> If an autotuning is ongoing, i.e., <code>inTunPro.y = true</code>, | ||
a new request for performing autotuning will be ignored. | ||
In addition, the set point should not be changed during the autotuning process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happen if the setpoint is changed during the tuning process? I see that you have a assert blockassMes3
. The assertion will give a warning not the error, so the tuning/simulation will not stop. So, should the tuning stop?
If the intention is to use the setpoint value at the moment when the tuning request becomes true, you may use the sampling value (sam_u_s.y
) as input for the tuning process. If during the process the setpoint changes, it would give warning, but the tuning still use the old setpoint value. However, the question still is, should we allow the setpoint change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we could stop the tuning once the setpoint changes. However, I am not sure if changing setpoint is the only reason for the square root negative number. Thus, the current implementation stops the tuning once the square root negative number occurs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I am assuming that when there is setpoint change during the tuning process, current implementation will stop the tuning process (no matter if or not the setpoint change causes the negative square root number)?
However, when check the result of Buildings.Fluid.HeatExchangers.Examples.WetCoilCounterFlowPControlAutoTuning
, the variable con.inTunPro.y
has following profile:
It shows that although the setpoint con.u_s
is changed at 2400 seconds, but the con.inTunPro.y
keeps being true
till to 2493.84 seconds, meaning that the tuning process does not stop at 2400 seconds. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the confusion.
In the current implementation,
- The tuning doesn't stop if the setpoint changes. A warning will be triggered.
- When the tuning stops, we will check if the tuning has been completed successfully or not. If not, we will use the control gains before the tuning.
- The flag that determines whether the tuning completes successfully or not will be false when the negative square root number occurs.
In my previous reply, I was saying we could change the current implementation into:
- The tuning stops if the setpoint changes. In this case, we will use the control gains before the tuning.
But my concern is that we cannot handle the case where the negative square root number is caused by other reasons.
Let me know if we need to have a quick call to discuss it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
08/26/2024 meeting note:
- Need to stop the tuning process once the setpoint changes. In this case, we will use the control gains before the tuning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes have been made in #3987 to stop the tuning process if the setpoint changes. In such a case, control gains will not be changed. If the setpoint is constant during the tuning, the tuning will be processed without interruption. We will check if the negative square root number occurs once the tuning is completed. If so, the tuning is considered to fail and control gains will not be changed.
This merges the PID autotuning to the master.