Vary a manipulated variable upper bound during a simulation.
Define the plant, which includes a 4-second input delay. Convert to a delay-free, discrete, state-space model using a 2-second control interval. Create the corresponding default controller and then specify MV bounds at +/-2.
-->The "PredictionHorizon" property of "mpc" object is empty. Trying PredictionHorizon = 10.
-->The "ControlHorizon" property of the "mpc" object is empty. Assuming 2.
-->The "Weights.ManipulatedVariables" property of "mpc" object is empty. Assuming default 0.00000.
-->The "Weights.ManipulatedVariablesRate" property of "mpc" object is empty. Assuming default 0.10000.
-->The "Weights.OutputVariables" property of "mpc" object is empty. Assuming default 1.00000.
Create an empty mpcmoveopt
object. During simulation, you can set properties of the object to specify controller parameters.
Pre-allocate storage and initialize the controller state.
-->Integrated white noise added on measured output channel #1.
-->The "Model.Noise" property of the "mpc" object is empty. Assuming white noise on each measured output channel.
Use mpcmove
to simulate the following:
Reference (setpoint) step change from initial condition r = 0 to r = 1 (servo response).
MV upper bound step decrease from 2 to 1, occurring at t = 10.
As the loop executes, the value of options.MVMax
is reset to 1 for all iterations that occur after t = 10. Prior to that iteration, options.MVMax
is empty. Therefore, the controller's value for MVMax
is used, MPCobj.MV(1).Max = 2
.
Plot the results of the simulation.
From the plot, you can observe that the original MV upper bound is active until t = 4. After the input delay of 4 seconds, the output variable (OV) moves smoothly to its new target of r = 1. reaching the target at t = 10. The new MV bound imposed at t = 10 becomes avtive immediately. This forces the OV below its target, after the input delay elapses.
Now assume that you want to impose an OV upper bound at a specified location relative to the OV target. Consider the following constraint design command:
This is a horizon-varying constraint. The known input delay makes it impossible for the controller to satisfy an OV constraint prior to the third prediction-horizon step. Therefore, a finite constraint during the first two steps would be poor practice. For illustrative purposes, the above constraint also decreases from 0.4 at step 3 to 0.2 at step 5 and thereafter.
The following commands produce the same results shown in the previous plot. The OV constraint is never active because it is being varied in concert with the setpoint, r.
-->Integrated white noise added on measured output channel #1.
-->The "Model.Noise" property of the "mpc" object is empty. Assuming white noise on each measured output channel.
The scalar value r + 0.4 replaces the first finite value in the MPCobj.OV(1).Max
vector, and the remaining finite values adjust to maintain the original profile, i.e., the numerical difference between these values is unchanged. r = 1 for the simulation, so the above use of the mpcmoveopt object is equivalent to the command
The use of the mpcmoveopt
object involves much less computational overhead, however.