An outside Library (from PreScan) requests 200 Hz while my control plant model needs to run at 100 Hz. Therefore, my question is that how can I coordinate these two activities? My concern is that if I use 200Hz in Simulink, it may compromise my control plant’s fidelity.
Is it possible to set simulink time step as 1/100 while keep the outside library to run at 200Hz?
Simulink works perfectly happily with multi-rate models. The thing (it appears) that you don't understand is the difference between the overall model sample rate - i.e. the settings of your solver - and the sample rate of individual blocks within your model.
It's very typical to have some blocks in your model sampled at say 100Hz, while other parts of your model sampled at 200Hz. In this case you would choose a discrete solver and give it a sample time of 200Hz. The 200Hz blocks would get executed at every solver time step, while the 100Hz blocks would get executed every second solver time step.
You should look at the Sample Times in Systems section of the documentation.
You can use both explicit and implicit rate control in Simulink.
Sample Time
To set the fundamental sample time go to: Configuration Parameter>Solver>Fixed-step size. You can also use the Simulink API:
get_param(bdroot, 'FixedStep')
set_param(bdroot, 'FixedStep', '0.005') % 200Hz
Colors
To activate the Sample Time colors go to: Display>Sample Time>All. The Sample Time Legend will help you understanding how the implicit rate control works.
Sample time Option
You can control the tasking and sample time options via: Configuration Parameter>Solver>Tasking and sample time options.
At the beginning you can activate the automatic handling of rate transition for data transfer. Then you shall analyse what colors your model elements are and place the Rate-Transition blocks on the data signal lines between the model elements with different sample rates.
Now the rate control is implicit. If you use the function calls to explicitly call your subsystems at a required rate by involving a predefined scheduler, than the rate control is explicit.
You can open build in Simulink examples to see how it works:
sf_ladder_logic_scheduler
sf_loop_scheduler
Related
I am struggling with a little project I decided to tackle. I am trying to replicate an example I found on a book using matlab simulink but I have no experience with simulink and control theory (I do understand the principles etc.).
The control block diagram is given but I do not understand some blocks and how to add my input (sine wave block on simulink)?
Here are the details:
Example I wish to reproduce
Schematic of the converter and desired control block diagram
If anyone could give me a little insight or direct me to some examples from which I could build on an understanding would be great!
Thank you in advance.
The portion entitled controller is the closed-loop feedback control for the system. K(s) would typically contain some type of PI control. In a more complicated control system, the structure of K(s) may be a little different, but will usually always contain an integration in order to ensure that the system eventually settles at the desired value.
The input Iref is your current command. In this case you would inject your sinusoid here which would produce a current waveform matching your desired output. If your desired output.
Output m is the modulating waveform produced by the controller. Everything inside the half-bridge converter section is a representation of the converter and everything that it is interfaced to (voltage sources).
The feedforward filter here is also a very important component. Since Vs contains an alternating waveform, the feed forward filter allows the system to respond to changes in Vs without relying on feedback compensation K(s). This helps to decouple current regulation from changes in voltage VD.
To start with the project, you can probably build the half bridge converter as shown. You can inject 400*cos(377t - pi/2) as VD.
For the feedback compensator K(s) you can feed the input into two gains (Ki and Kp) which you will select values for later. At the output of Ki insert an integrator (1/s) then sum the output of Kp and the integrator together.
For the feed-forward filter, you should probably just use a low pass filter with a gain of 1 at DC. The low pass filter prevents noise from entering the system. In this case you are running a simulation, so there will be no noise. However, the filter will eliminate any algebraic loops, which can cause warnings or errors in the simulation.
You can input your control signal at Iref.
I am new to Simulink and try to achieve the following:
I have a signal which simulates output power of an engine. I now want to be able to change this power output to a new value.
My question: How do I implement a linear adjustment from the current output to the newly requested output? Linear in the sense of a constant rate of change, e.g. x Watt/second.
Thanks!
The simplest way to handle this is probably the Rate Limiter block.
If you cause a step-change in the demand, the rate limiter will take the demand as an input and produce an output with the rate of change limited to the rate specified in its dialog parameters.
There is a dynamic version if you want the maximum slew rates to be specified via signals.
How to use rate limiter with square signal and variable step size in Simulink?
Here's a screenshot of the model I'd like to set up:
model:
I feed a customized rectangular signal to a rate limiter to avoid vertical slopes.
Unfortunately that doesn't seem to work. I'm using ode15s, it's a requirement. Here's the error message Simulink throws:
Error: Input signals to Rate Limiter '.../Rate Limiter' are neither
discrete nor continuous sample time signals. Only discrete or
continuous input signals are supported
Quite surprisingly I found a workaroud by adding an integrator directly followed by a derivative. This works:
workaroud:
But it's ugly and I'm getting some very annoying stability issues in some cases. And I doubt very much that it is considered "good practice".
So how is one supposed to use this rate limiter block in such a situation?
John
Thank you both for your answers.
I forgot to say I had already checked the sample time with the colour display. It was "Fixed-in-Minor-Step".
Actually it was quite simple. If I get it right, the sample time was not specified or specified in a wrong way in my subsystem. Specifying Continuous in the rate limiter dialog box solved the problem!
thewaywewalk, I'll keep your suggestion in mind. Since I'm using steps a lot it might be useful.
Try displaying the sample time colours in your model to check what sample times your signals are using.
Introducing an integrator block will force the signal to become continuous, hence why it works. Maybe using a Signal Specification block or a Rate Transition block with a sample time of [0, 0] (for continuous signal, see Specify Sample Time in the documentation) will achieve the same thing and be slightly more elegant (using the derivative block is not considered good practice).
I believe I am doing something fundamentally wrong when trying to import and test a transfer function in Simulink which was created within the System Identification Toolbox (SIT).
To give a simple example of what I am doing.
I have an input which is an offset sinusoidal wave from 12 seconds to 25 seconds with an amplitude of 1 and a frequency of 1.5rad/s which gives a measured output.
I have used SIT to create a simple 2 pole 1 zero transfer function which gives the following agreement:
I have then tried to import this transfer function into Simulink for investigation in the following configuration which has a sinusoidal input of frequency 1.5rad/s and a starting t=12. The LTI system block refers to the transfer function variable within the workspace:
When I run this simulation for 13 seconds the input to the block is as expected but the post transfer function signal shows little agreement with what would be expected and is an order of magnitude out.
pre:
post:
Could someone give any insight into where I am going wrong and why the output from the tf in simulink shows little resemblance to the model output displayed in the SIT. I have a basic grasp of control theory but I am struggling to make sense of this.
This could be due to different initial conditions used in SimuLink and the SI Toolbox, the latter should estimate initial conditions with the model, while Simulink does nothing special with initial conditions unless you specify them yourself.
To me it seems that your original signals are in periodic regime, since your output looks almost like a sine wave as well. In periodic regime, initial conditions have little effect. You can verify my assumption by simulating your model for a longer amount of time: if at the end, your signal reaches the right amplitude and phase lag as in your data, you will know that the initial conditions were wrong.
In any case, you can get the estimated initial state from the toolbox, I think using the InitialState property of the resulting object.
Another thing that might go wrong, is the time discretization that you use in Simulink in case you estimated a continuous time model (one in the Laplace variable s, not in z or q).
edit: In that case I would recommend you check what Simulink uses to discretize your CT model, by using c2d in MATLAB and a setup like the one below in Simulink. In MATLAB you can also "simulate" the response to a CT model using lsim, where you have to specify a discretization method.
This set-up allows you to load in a CT model and a discretized variant (in this case a state-space representation). By comparing the signals, you can see whether the discretization method you use is the same one that SimuLink uses (this depends on the integration method you set in the settings).
I have a Simulink xPC target application that has blocks with discrete states at several different sample rates and some sections using continuous states. My intention on keeping the continuous states is for better numerical integration.
What creates the problem: One block is reading a device at a very fast rate (500 hz). The rest of the application can and should run at a slower rate (say, 25 or 50 Hz) because it would be overkill to run it at the highest rate, and because the processor simply cannot squeeze a full application cycle into the .002 secs of the faster rate. So I need both rates. However, the continuous states run by definition in Simulink at the faster discrete rate of the whole application! This means everywhere I have continuous states now they're forced to run at 500 Hz when 25 Hz would do!
Is there a way to force the continuous states in xPC target to a rate that is not the fastest in the application? Or alternatively, is there a way to allow certain block to run at a faster speed than the rest of the application?
You are thinking about continuous solvers in the wrong way - continuous doesn't only mean that it's run as fast as possible - it uses a fundamentally different algorithm to solve the equations than discrete. Due to this, they must be run at least as fast as the discrete solvers.
From Using Simulink:
Continuous solvers use numerical
integration to compute a model's
continuous states at the current time
step from the states at previous time
steps and the state derivatives.
Continuous solvers rely on the model's
blocks to compute the values of the
model's discrete states at each time
step.
Mathematicians have developed a wide
variety of numerical integration
techniques for solving the ordinary
differential equations (ODEs) that
represent the continuous states of
dynamic systems. Simulink provides an
extensive set of fixed-step and
variable-step continuous solvers, each
implementing a specific ODE solution
method (see Solvers).
Discrete solvers exist primarily to
solve purely discrete models. They
compute the next simulation time step
for a model and nothing else. They do
not compute continuous states and they
rely on the model's blocks to update
the model's discrete states.
So the upshot is that no it's not good enough to have the continuous run more slowly than the fastest discrete solvers - otherwise they are, by definition, not continuous. You should reconsider why you are specifying them as continuous.
What are you trying to accomplish by slowing down the continuous solvers? Is this a simulation time/performance issue?
-Adam
My take on this is that it cannot be done. One way to approach this is to replace the continuous states by discrete ones (perhaps at an intermediate rate, say 100 Hz), and cross my fingers that the loss of precision is bearable.
Maybe it's possible to isolate a block and run it separately at a faster rate somehow, but I don't know.
Truly continuous computation is impossible in a digital processor such as your computer's.
What MATLAB/Simulink means by "continuous" is "I will (dynamically) try to guess what discrete step size is small enough so that discretization error is very small in your application".
If you already know, by knowing your application, that 20ms (50Hz) would be small enough, then use discrete - 50Hz.