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?!
Related
I am using Dymola 2020x to develop a thermal model and export the FMU to Simulink to simulate controllers.
For implementing advanced controllers, I require an iteratively run framework, which helps to initialize the states after every iteration to the values at end of every previous simulation. This can be done within Dymola through “import initial” and “Continue” commands in the Simulation tab of Dymola.
However, since I am designing the controller in MATLAB, I require a similar feature for that platform. The only way I know right now is to manually change the initial conditions in the FMU block, but since I have a lot of states, it would not be feasible to do it manually. Any scripting ideas are welcome as well.
All in all, I require a framework/method to be able to initialize states of my model through MATLAB/Simulink to the values I get after running a single iteration.
Some help would be appreciated.
Expose the initial conditions of the variables as parameters, and set them from MATLA Scripts with e.g.
FMIKit.setStartValue(gcb, 'step', 'true')
see https://github.com/CATIA-Systems/FMIKit-Simulink/blob/master/docs/fmu_import.md
Initialization could be very cumbersome and easily lead to divergence. A simple strategy is to run the simulation when building a part of the whole system and use the simulation results to modify guess values.
Here is what I got in the PPT from Francesco Casella and the book from Daniel Bouskela.
I found that I could use an option in Dymola as follows, but instead of using the initialization result, I wanna use the result when reaching a steady state. So I'd like to use a python script to extract the result from the .mat result file, then modify the iteration variables automatically. But the key problem is that I don't know when I add more components in my model, the iteration variable set of existing components would change, I don't know what kind of effect would this causes.
Anyone got opinion on this issue, welcome to answer this question.
So my question is where should I find the python
You can use the end values (= steady state) of the simulation result in order to create a new initialization (Dymola Manual 1, section 2.5.12) . If the component names are the same in the sub system model and the total model, you can run the script created in the subsystem model on the larger system model as well. But you have to check if your models have initial equations that hinder an initialization from the outside (see section 4.2 in https://2012.international.conference.modelica.org/proceedings/html/pdf/ecp12076927_KruegerMehlhaseSchmitz.pdf)
It should also be possible to initialize it steady state. Instead of providing initial values for a state x and fixing it, you can provide initial equations for the derivatives such as der(x) = 0;
With that setup activate Save Initial Results and you should be good to go.
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.
I've developed a controller in Simulink and am trying to export it as a pure C class using Simulink coder for deployment on our microcontroller. We are using a fixed step solver in simulation, however, when the exported code gets used on our actual plant, the actual step size may change depending on load of the processor.
My concern is this: say I have set the fixed time step as 0.05s in simulation (and therefore the exported code assumes it is being executed every 0.05s), but then the microprocessor sometimes executes after 0.1s, and sometimes after 0.03s, etc. I think this would cause some unwanted behaviour.
Is there a way to have Simulink coder create a variable for step-time that we can adjust during run time? That is, measure how long it has been since the last execution, and then fill in the variable during each execution.
For an analogy, in videogame programming the update functions usually include a dt parameter so we know how long its been since the last frame.
The only solution I can find is to manually search and replace the step size in all the integrator blocks after the code has been generated. This, however, seems error prone.
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.