I have a Simulink model that includes the following subsystem.
The bm_train_adapter block will call a MATLAB function of the same name, passing all the input arguments in a single vector.
The subsystem has been given a sample time of 900 (secs), which is why all the signals are colored in red (for discrete signals).
However, in the debugger I have observed that the bm_train_adapter function gets called twice at each simulation timestep. This yields horribly wrong results since the function includes side-effects.
Why is Simulink calling my interpreted MATLAB function more than once per timestep? How can I prevent this?
I think this is because of your solver setup. In your Configuration Parameters window, check out the Solver Options pane.
I believe the discrete and ode1 solvers will call once per timestep. ode2 will call twice per timestep, ode4 will call 4 times per timestep, etc.
This behavior is very helpful for simulating continuous dynamics, but it can be confusing when interacting with discrete elements.
The reason was that my model had algebraic loops caused by unit delay blocks in subsystems. To solve these loops, the solver had no choice but to evaluate some blocks more than once.
The solution was to move out all unit delays from their subsystems.
Related
I have a Matlab function (created by me) that must be evaluated only at a given rate. I would like to sample the value of a signal, give to this function (discrete values) and then, the calculated output must be hold until the next value is available. Is there a way in simulink to do this? All answers I have found use quantizer + ZOH but in this case I still get "a continuum" (or almost it) of points to be evaluated by thsi function which is really slow. Changing the rate of simulink's solver is also not an option as the result of this function will be given for a continuous time system.
Any help will be highly appreciatted!
Thank you
Assuming by Matlab function you mean a MATLAB Function block, then it sounds as if all you need to do is make the block discrete. Do that by right-clicking on the block, going down to Block Properties and then in the resulting dialog enter your required sample time.
The block will then sample its input and generate an output (which is held between sample times) at each sample time.
Assume that you have a Simulink simulation. You run it twice and consider a plot of a certain signal in time. Is it possible that there are small differences between the two signals?
A possible cause could be a variable-step solver.
Assuming all simulation parameters are the same between runs, if your simulation is complex, and uses custom blocks, such a thing is possible, if there is a bug in the initialization code.
With S-Functions, for example, you can chose if and how to reset internal state between simulation runs. With C code, it is easy enough to forget to reset something altogether, and end up with some uninitialized variable that contains garbage.
Another possibility is that something gets written into the workspace from the simulation, and is fed back into the simulation when it is initialized the next time.
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'm trying to build a Simulink model containing a "s-function block" simulating a continuous process with a "Matlab Function Block" that use the input and output from s-function.
But I need the input to the "Matlab Function Block" with differents values of the same signal over time. That is, a vector with different sampling times for each input to "Matlab Function Block". This will be needed for testing identification techniques.
How could I do this?
Thank you
Assuming you are using a fixed-step discrete solver, and that you don't have too many values of the same signal to hold, you could use Unit Delay blocks to get the value of the signal at previous time steps. You can then mux all these signals together to form your vector input. Obviously, the practicality of it is limited by how many values of the signals you need to have (and buffer).
I am trying to run my simulink file which have pid controller connected to s-function block.
When i set three values parameters of pid which are proportional, integral and derivatives it takes too long to run the whole process. Why this is happened?
In the dialog box of my pid diagram, for porportional value, its equal to the value which correspond to the constant amplitude oscillation.
Then for integral, its equal to Kcu/Ti. Ti is the ultimate period(Pu)/2 and
lastly for derivatives, its equal tu Kcu*Td and Td is Pu /8. This is refer to ziegler nichols method. and again my question is why it takes too long to running this file?
MATLAB S-functions are slow because they run in the MATLAB interpreter. Consider implementing it using Simulink blocks or using a "Embedded MATLAB Function" (pre-R2011a) or "MATLAB Function" (R2011a+) block.
Read Guy and Seth's thoughts on Simulation performance.
#Nzbuu is right about the Matlab S-functions.
But I think the problem here could be somewhere else: #Syarina are you saying that the Simulink simulation gets slower after you set the proportional coefficient for the controller? If you simulate the plant alone, in this case the S-function, do you notice a significant difference in the execution speed? If it is really so, I suppose the PID controller makes the ODE system stiff. This means that the different states of the ODE system have really different dynamics - some are very fast, some are very slow. Using an ode-solver that is not suited for stiff equations you will find the simulation much slower (actually you would have luck if it converges at all).
My suggestion is try to change the solver - for example ode15s.