I had as primary objective to make a controller for the transfer function (5.551* s^2), using root locus I made the controller shown below. Analyzing the step response in the Workspace using the step () function I had a satisfactory answer but when I try to transfer this answer to Simulink the response behaves differently, at steady state for example I wish to have the smallest possible error as it was obtained in Workspace but in Simulink there is a big error and for some reason at 8 seconds time (Simulink simulation time) there is a "jump" as shown on the display and when I change the simulation time there is a change in this "jump" too and I do not know why these changes between one environment and another.
Step response in Workspace
Step response in Simulink with 8s of simulation
Step response in Simulink with 12s of simulation
Simulink controller
Simulink transfer function
I expected to make a controller that has an error less than 5% and an overshoot smaller than 25%, so I first made a controller with two integrators to nullify the effects of zeros on the source, after that I added two more integrators on the source to try decrease the error, the zero at -0.652 I used the angular condition for this and the gain of 0.240251 I used the modular condition.
I wasn't expecting the most optimized behavior possible, just that it has minimum conditions that satisfy the imposed conditions, so I didn't worry for example about the four integrators at the source.
I tried use the sisotool() command thinking that I had done something wrong, but the result changed a lot when I was simulating Simulink so I discarded this option and kept the controller I made using root locus.
Your MATLAB code and your Simulink model are not the same, and hence the different results.
MATLAB allows you to define the non-causal plant model P_ball, then form the causal closed loop CL, which can have its step response generated.
Simulink does not allow you to model non-causal blocks (even if the overall model is causal) and hence will not allow you to implement s^2, which I assume is why you have used two differentiation blocks. But a numerical differentiation is not the same as a Laplace s operator.
You would have to make the plant causal by incorporating two poles that are large enough to not adversely effect the overall simulation. So your plant model needs to be something like 5.551*s^2/((s/1000 + 1)(s/1000 + 1)) which can be implemented using a Transfer Function block with a numerator of 5.551*1000*1000*[1 0 0] and a denominator of [1 2*1000 1000*1000].
Alternatively you could just implement PID * P_ball (where you manually do the 2 zero/pole cancellations) which is causal.
Related
I am trying to simulate the flow in pipes between reservoirs. I have created my own pipe component (based on Modelica.Fluid) and it works fine when I simulate from one tank to another as shown below.
However, when I try to connect two pipes in series, as shown in the picture below, the model does not work. When I check my model, I'm told my model is balanced and has 402 equations and 402 variables.
However, when I try to simulate I get the following error message:
An independent subset of the model has imbalanced number of equations (143) and variables (144)
Any ideas where this error message originates from? How is it possible that a balanced system becomes unbalanced when simulating, and how could it work with one pipe, but not two in series?
The problem is something like:
model M
Real x,y;
equation
x = sin(x);
x = 3.0;
end M;
Where the total number of equations are balanced, but there is something causing some part of the system to be unbalanced (like forgetting a variable in the equations). OpenModelica internally partitions everything into sets of equations/variables that reach each other, which can give the error-message above. For the trivial cases like the one above, there is usually a different error-message though.
I've had to create the Simulink Diagram after this picture:
My answer is this one:
I've gave some values to a, b and c (like 3, 4 and 5), but when I try to run it, it gives me the following warning:
Warning: The model 'ex2_2' does not have continuous states, hence Simulink is using the
solver 'VariableStepDiscrete' instead of solver 'ode45'. You can disable this diagnostic by
explicitly specifying a discrete solver in the solver tab of the Configuration Parameters
dialog, or by setting the 'Automatic solver parameter selection' diagnostic to 'none' in the
Diagnostics tab of the Configuration Parameters dialog
Warning: 'ex2_2/Unit Delay' is discrete, yet is inheriting a continuous sample time; consider
replacing unit delay with a memory block. When a unit delay block inherits continuous sample
time, its behavior is the same as the memory block. Unit delay block's time delay will not be
fixed and could change with each time step. This might be unexpected behavior. Normally, a
unit delay block uses discrete sample time. You can disable this diagnostic by setting the
'Discrete used as continuous' diagnostic to 'none' in the Sample Time group on the
Diagnostics pane of the Configuration Parameters dialog box. "
and the output (scope) it's just a step signal...
I don't know where I'm wrong here.
You've built the model correctly, but did not configure it correctly.
When running the model as-is, what will happen is the following:
The Step block is a continuous-time source by default (it's Sample Time setting is 0).
Simulink sees that the Step is connected to the Unit delay block, which is guaranteed to have constant output during minor steps (unlike Memory blocks)
According to the documentation on sample times:
[...] Simulink sets [Fixed-in-Minor step] as either an inherited sample time or as an alteration to a user specification of 0 (continuous). This setting is equivalent to, and therefore converted to, the fastest discrete rate when you use a fixed-step solver.
Continuous sample time degrades to Fixed-in-Minor-Step rather than Discrete-time in the context of Variable-step solvers. Variable step size is used to speed up simulations (larger steps are taken when accuracy allows it), but requires trickery to compute, for example, the exact time at which the step triggers (the "Enable zero-crossing detection" tick box in the Step block's options). So, Simulink's best way forward in this particular situation is to convert the sample time of the Step block into Fixed-in-Minor-Step, which is propagated forward and inherited by all other blocks in the model.
This is usually an awkward type of sample time, which is effectively not continuous-time, but still seen by all blocks as such. Therefore, the inherently discrete-time Unit delay will complain about being driven by a continuous-time signal (your 2nd warning), and Simulink itself will complain about the complete lack of "real" continuous-time blocks anywhere, while being instructed to use a continuous-time solver, ode45 (your 1st warning).
As usual in software development: it's always best to be explicit, about everything. In this case, the simplest way out of this is to explicitly specify a discrete-time, fixed-step solver in the model configuration dialog. That way, the continuous-time from the step will be automatically converted into discrete-time for the Unit delay.
The block diagram you want to implement is a discrete-time system. Since there are no Ordinary Differential Equations (ODE) but only their discrete counterpart (Finite-differences equations), you do not need an ODE solver as the warning 1 points out.
In discrete-time systems you have to specify your sample time in order to approach to a continuous-time representation where every single instant t is built up by the discrete integer n and its progressions (n+1, n+2, and so on) as t = nT where T is your sample time; Simulink basically expects that you respect this kind of logic, then asks for a sample time. By default Simulink sets it variable which may lead the result "out of track". This is what the warning 2 points out.
Solution: In the 'Model Configuration Parameters' menu, at the Solver tab, set 'Fixed-Step' as Type. The pane will change with a field related to the sample-time (Fixed-step size); set then a Sample time in seconds different than "auto" (e.g. 0.01). This will solve the warning 2. Still in the Solver menu, set also 'Discrete (no continuous states)' instead of any other useless solver. This will solve the warning 1.
I'am trying to speedup my simulink project and want to use the Accelerator-Simulation mode.
The aim of my project is to control a cyclic process and is structured as followes:
matlab-script, where all parameters and a feedforward control with
parameter estimation is implemented. Also it starts simulating the
simulink model for each iteration.
simulink model, where the dynamic system and the feedforward control (basically a lookup-table) together with a feedback control
is implemented. Parameters of all blocks are set by workspace variables/structs generated by the script.
The feedforward control variable is calculated and parameter are estimated from the simulated data after every simulation pass. Then the model is simulated again. The model is not changing during the iterations, but still it is compiling at every cycle. From the first: Is this solution appropriate for using the Accelerator mode?
I tried to follow theses proposed steps to determine, why it is built at every iteration: mathworks
If i run it with the Accelerator-Mode (referring to the documentation of this function, it now compiles for simulation), I still cannot reproduce why it is compiled at every iteration.
csdet1.ContentsChecksum.Value ~= csdet2.ContentsChecksum.Value
is true, but the proposed code does not find any details.
csdet1.InterfaceChecksum.Value ~= csdet2.InterfaceChecksum.Value
is also true, the proposed code outputs that
UserDefinedTypesChecksum
is different. What does that mean and how can I resolve this?
Sidefact: When I run Simulink.BlockDiagram.getChecksum() with the Model opened in Simulink and Normal-Mode chosen, I get this error:
Continuous update specified for this chart chartname This is not
supported for RTW."
But this chart is a Matlab-Function block, not a stateflow chart?!
how to import a bitsream form binary vector from workspace into simulink.Actually I have found that I can use simin block or In block but my binary vector is independant of time. I tried to use Const block and it works but afer that when I wanted to put my output in the Buffer block in simulink, it didn't work because the input is continuous and not discrete. So I am asking if it's a way to add time to my binary uni-dimensional without having any influence on the result?and how can I do it?
Or is there another way to import this date to avoid this problem with Buffer block?
Your screenshot shows your constant block to have a sample time of Inf. As the error message suggest, you need to change that to a discrete sample time. In addition, you should also:
check your model is using a fixed-step solver
check what time step you are using for your chosen fixed-step solver (ideally the same as your constant).
You can have multi-rate models, but you need to manage the rate transitions with Rate Transition blocks. For more details on sample times, see the documentation, in particular how to view sample time information in a Simulink model. You should probably also have a quick look at the Choose a Solver section.
I have been wondering this for some time now and was curious about the most logical implementation for simulating block diagram based time-domain models.
I don't know if that term is correct, but if you know Simulink you know what I mean.
There reason I am wondering is is that I have made some simulation models myself now, but I always get stuck when I am creating feedback loops. Most of the time this is not a problem when I am working with blocks that I can translate to the state-space domain, but when I get more complex elements this becomes a problem.
Practically I can not seem to get my head around how Simulink solves this.
I had thought that practically for every timesample every block calculates it current state and passes that to the connected blocks for the next timesample, however when you have:
->A->B->C->D
^-----|
4 blocks with a feedback to A and an input to A, it takes 3 timesamples to reach C, after which C will start emitting to A again. Before that C would have been emitting it's initial value. It takes 4 timesamples to reach D.
When A,B,C,D are simple laplace-like elements this is easily combined in a state-space or transfer function from A to D, however the results will be monumentally different. Because it will take 1 timesample from A to D and from C to A. I know that when the transfer function requires you, in general, to specify the initial conditions, but these conditions are not translateable (or I can not see it) to the block diagram solution.
How do you tackle this problem in a generic way?