I'm trying to simulate some electronics stuff in Simulink. Current mode PWM, so I need to compare MOSFET current with constant.
I tried to use "Relational operator" and "Compare to zero" with the same result.
In Continuous simulation mode, it reacts all over the place, like +-5e-6 sec and it is no help when the PWM signal is 20e-6 sec period.
When I run it in Discrete mode on 5e-8 sec sample time it works all right.
In tutorials, all electronics simulation runs in continuous mode, and calculating blocks seem to work right but not those blocks. Are there some settings for this?
The system is based on Simscape / Electrical / Specialized Power Systems blocks
Like this example: https://www.mathworks.com/help/physmod/sps/ug/boost-converter.html
Related
Thanks in advance,
I am having a simple Simulink model, that takes in a 32-bit number in the IEEE-754 format and adds the same number, which gives the output again in the 32-bit wide IEEE-754 format. I used MATLAB's HDL CODER add-on and generated the Verilog HDL code for the same. When I wrote a testbench for the same, I found the latency I get from this code is 100ns. But is there a way I can reduce this to even further, say some 10ns.
Below I am attaching the Simulink model I used to generate the Verilog HDL code, along with the generated Verilog files. Also, I am attaching a screenshot of the simulation in case you don't want to waste your time running the scripts
Link to download the files
my point is how to use pipeline settings before conversion
I am assuming that "pipeline settings" is a MATLAB HDL generator parameter.
Basically what you do is "try": use a pipeline setting and synthesize the code. If you have slack you can:
Reduce the number of pipeline stages.
or
Increase the clock frequency.
(For negative slack you use the inverse methods)
Now here is where things get tricky:
Most of the time you can't really speed things up. A certain functionality needs a time to calculate. Some algorithms can be sped up by using more parallel resources but only up tot a limit. An adder is good example: you can have ripple carry, carry look-ahead and more advanced techniques, but you can not speed up infinitely. (Otherwise CPUs these days would be running at Terra Hz)
I suspect in the end you will find that it takes T time to do your IEEE-754 adder. That can be X clock cycles of an A MHz. clock or Y clock cycles of B MHz. But X times A is about the same as Y times B.
What you can do is pump lots of calculations into your pipe so a new one comes out every clock cycle. But the latency will still be there.
I am new to Simscape. I would like to find a minimalist way to display voltage and current at various points in a circuit. Ideally just floating text labels with no 'wires' or connections visible. For example "Vbe 0.4v" or "Ic 20mA"
Currently I am using 3 standard blocks to achieve this and the circuit looks cluttered.
Is there a way to do what I want with some coding?
Currently, you have several options, some involve more work. Here are two ideas:
A) If your circuit is 3-phase, you can use the Busbar block and enable Frequency and Time solver in the Solver Configuration block, to display the initial voltages (and also power flows). This uses the Load-Flow Analysis feature starting R2019b. Check out this simple example.
B) Connect Voltage Sensor blocks to the nodes you want to sense voltage on, and connect the voltage PS output to a Simulink Display block, which will display the numerical value in real-time.
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
I am working on my simulation model in Simulink, where I am using "NN Predictive controller" module. I am trying to display the output of the NN Controller in Scope 2.
As you can see in the picture I have 2 signals from workspace. Both are discrete signals (sampling frequency 360 Hz) - both are vectors of 3600 rows.
In NN Predictive controller I have trained neural network to signals of the same size and set the sampling interval to 0.1.
When I run this simulation it runs approximately for 10 hours. Is there any way to minimize the simulation time without increasing the sampling interval in NN Controller? My second question: Why it takes so long?
If you need additional inforation about this model please let me know.
Thank you
Picture:
Use Accelerator Mode or Rapid Accelerator Mode in SL. You can switch the mode in the drop-down list where currently normal is selected.
In the Accelerator Mode part of the Modell is compiled. In the Rapid Accelerator Mode additionally all scopes are deactivated. For data evaluation you than need to store to the workspace and/or file and analyse it later.
See: http://de.mathworks.com/help/simulink/ug/how-the-acceleration-modes-work.html
and: http://de.mathworks.com/company/newsletters/articles/improving-simulation-performance-in-simulink.html
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.