Is it possible to comment out the block in Simulink like it is possible in any programming languages ? I mean, using logic, I can disable the block. but its not the best solution all the time.
I would rather disable / comment out the part of the block in my Model to test individual modules in Simulink.
I just wanted to add that in Simulnk 2012b, it is now possible to explicitly comment out blocks. Simply right-click on the block and select the option "Comment Out".
When run, the model will act as if the commented out block is not there at all. This means that input/output signals to/from this block are essentially just left open. So for example, if you commented out a gain block, the input signal would not simply pass through to the output signal.
I found a potentially useful solution in the matlab central forums.
A good way to "comment out" Simulink blocks is to use a switch block
whose control port is driven by a global constant value (parameter).
Say PARA=1 if you want to have this Simulink block in your code and
PARA=0 if you want to comment it out. Choose the threshold of your
switch w.r.t the value of PARA. The first branch of the switch should
pass the original signal to the Simulink block you want to have. The
other should end at a terminator block. In this case, no code is
executed for the Simulink block you want to comment out. And if you
use a code generator, the code generator can decide in advance,
whether you want to generate code for this block or not (depending on
the value of PARA).
Original Source
Hopefully that will work for you as well.
Matlab / Simulink r2018A:
1) Select a simulink block.
2) Edit -> Comment Out:
Related
I am using Simulink to model a waste recycling plant out of a number of masked blocks that I created, representing sorting steps, buffers etc. Each module (that is, a masked block) has a failure probability, modeled using Discrete Events. If a failure event occurs, a triggered subsystem calls an Interpreted Matlab Function ("outside" of simulink). This function is supposed to set a parameter status of the masked block representing the module that failed as well as the upstream modules' status to 0 (because obviously, everything upstream has to stop as well or the material will just pile up).
`set_param(gcb, 'status', num2str(status));
PortConnectivity = get_param(gcb,'PortConnectivity');
sources = PortConnectivity.SrcBlock;`
Basically, this will be looped until I reach a block with no own Source Block.
This all works quite well, except for one problem: The gcb command gives me the block path to the last block I highlighted manually, and not to the block that called the Interpreted Matlab function. Is there any way to get the calling block's handle (which I would use with it's Parents parameter to access the Mask's status)? (A similar question has been asked here, with no results...)
I hope you get my problem - I'll be happy to elaborate if anything's unclear; I am not claiming to be a Simulink expert, so sorry for maybe using wrong terminology.
Ok, for everyone stumbling upon this:
For the mask that contains the caller of the Matlab Interpreted Function, in the mask editor I define a parameter 'this_block' (turn visibility off), that I initialize in the Initialisation pane using
parent = get_param(gcb,'Parent');
set_param(gcb, 'this_block','Parent')
Since this masked block (responsible for modelling the failure and its upstream communication) is itself used in another masked block also present in the library (responsible for modeling the module's behaviour), I also had to check "Allow library blocks to modify it's contents" in the mask editor Inititlization pane of the parent's mask. The parameter 'this_block' is then handed over as one of the input arguments of the called function (in my case, status_communication(u, this_block)).
I have a sample model(shown below) which consist of a from workspace block. It contains a workspace variable variable1(timeseries signal). I am changing the data of variable1 during simulation but model is not updating the current value of variable1. It's update only when I stop and restart the simulation but I want it to update during runtime only. Can anyone help me in handling this problem?
This is not really how Simulink is designed to work, so there's no easy way to do this. Simulink only checks only checks the workspace for values during model initialization at the start of the simulation. The best thing to do is to use set_param, as in:
set_param('untitled/From Workspace',' VariableName','variable1'); % put the correct path to your block
This is not changing anything in how the block is parameterised, but forces Simulink to parameterise the block with the new values of variable1. Because variable1 is a timeseries object, I am not sure how well this will work, but it's worth a try.
For more details, see this discussion on MATLAB Central.
I am currently working on a tool written in M-Script that executes a set of checks on a given simulink model. This tool does not compile/execute the model, I'm using find_system and get_param to retrieve all the information I need in order to run the routines of my tool.
I've reached a point where I need to determine whether a certain block has direct-feedthrough or not. I am not entirely sure how to do this. Two possible solutions come to mind:
A property might store this information and might be accessible via get_param. After investigating this, I could not find any such property.
Some block types have direct-feedthrough (Sum, Logic, ...), some other do not (Unit Delay, Integrator), so I could use the block type to determine whether a block has direct-feedthrough or not. Since I'm not an experienced Simulink modeller, I'm not sure if its possible to tell whether a block has direct-feedthrough by solely looking at its block type. Also, this would require a lookup table including all Simulink block types. An impossible task, since additional block types might get added to Simulink via third party modules.
Any help or pointers to possible solutions are greatly appreciated.
after some further research...
There is an "official solution" by Matlab:
just download the linked m-file
It shows that my idea was not that bad ;)
and for the record, my idea:
I think it's doable quite easily. I cannot present you some code yet, but I'll see what I can do. My idea is the following:
programatically create a new model
Add a Constant source block and a Terminator
add the Block you want to get to know the direct feedthrough ability in the middle
add_lines
run the simulation and log the states, which will give you the xout variable in the workspace.
If there is direct feedthrough the vector is empty, otherwise not.
probably you need to include some try/catch error catching for special cases
This way you can analyse a block for direct feedthrough by just migrating it to another model, without compiling your actual main model. It's not the fastest solution, but I can not imagine that performance matters that much for you.
Here we go, this script works fine for my examples:
function feedthrough = hasfeedthrough( input )
% get block path
blockinfo = find_system('simulink','Name',input);
blockpath = blockinfo{1};
% create new system
new_system('feed');
open_system('feed');
% add test model elements
src = add_block('simulink/Sources/Constant','feed/Constant');
src_ports = get_param(src,'PortHandles');
src_out = src_ports.Outport;
dest = add_block('simulink/Sinks/To Workspace','feed/simout');
dest_ports = get_param(dest,'PortHandles');
dest_in = dest_ports.Inport;
test = add_block(blockpath,'feed/test');
test_ports = get_param(test,'PortHandles');
test_in = test_ports.Inport;
test_out = test_ports.Outport;
add_line('feed',src_out,test_in);
add_line('feed',test_out,dest_in);
% setup simulation
set_param('feed','StopTime','0.1');
set_param('feed','Solver','ode3');
set_param('feed','FixedStep','0.05');
set_param('feed','SaveState','on');
% run simulation and get states
sim('feed');
% if condition for blocks like state space
feedthrough = isempty(xout);
if ~feedthrough
a = simout.data;
if ~any(a == xout);
feedthrough = ~feedthrough;
end
end
delete system
close_system('feed',1)
delete('feed');
end
When enter for example 'Gain' it will return 1, when you enter 'Integrator' it will return 0.
Execution time on my ancient machine is 1.3sec, not that bad.
Things you probably still have to do:
add another parameter, to define whether the block is continuous or discrete time and set the solver accordingly.
test some "extraordinary" blocks, maybe it's not working for everything. Also I haven implemented anything which could deal with logic, but actually the constant is 1 so it should work as well.
Just try out everything, at least it's a good base for you to work on.
A famous exception is the StateSpace Block which can have direct feedthrough AND states. But there are not sooo much standard blocks with this "behaviour". If you also have to deal with third party blocks you could get into some trouble, I have to admit that.
possible solution for the state space: if one compares xout with yout than one can find another indicator for direct feedthrough: if there is, the vectors are not equal. If so, than they are equal. Just an example, but I can imagine that it is possible to find more general ways to test things like that.
besides the added simout block above one needs the condition:
% if condition for blocks like state space
feedthrough = isempty(xout);
if ~feedthrough
a = simout.data;
if ~any(a == xout);
feedthrough = ~feedthrough;
end
end
From the documentation:
Tip
To determine if a block has direct feedthrough:
Double-click the
block. The block parameter dialog box opens.
Click the Help button in
the block parameter dialog box. The block reference page opens.
Scroll
to the Characteristics section of the block reference page, which
lists whether or not that block has direct feedthrough.
I couldn't find a programmatic equivalent though...
Based on a similar approach to the one by #thewaywewalk, you could set up a temporary model that contains an algebraic loop, similar to,
(Note that you would replace the State-Space block with any block that you want to test.)
Then set the diagnostics to error out if there is an algebraic loop,
If an error occurs when the model is compiled
>> modelname([],[],[],'compile');
(and you should check that it is the Algebraic Loop error that has occured), then the block has direct feed though.
If no error occurs then the block does not have direct feed though.
At this point you would need to terminate the model using
>> modelname([],[],[],'term');
If the block has multiple inports or outprts then you'll need to iterate over all combinations of them.
The Gain block and continuous block in Simulink require the user to specify a gain. This can be a workspace variable. But I want to vary this gain during runtime. I can't seem to get a solution for this. This idea is simple but I can't believe it is so difficult to implement.
I have tried using another block to write to workspace, but found out that the 'to workspace' block only writes to the workspace after the simulation ends or pauses.
I can store the variable in a data memory block, but I don't know how to specify the gain value(s) for the gain/PID block in this case.
If you have Inline Parameters turned off (it's on the Optimization page of the Configuration Set), you can just open the gain block dialog and change the value. If you want to use a workspace variable, then you can change the value of the workspace variable and do an Update Diagram (^D) while the simulation is running.
There's also a block called the Slider Gain which allows you to change the gain value using a slider UI.
May be it'd be helpful at some point: try using the MATLAB Function Block (Matlab user-defined function that can be used directly in Simulink).
As a command-line alternative, you can use the SET_PARAM function to change the Gain value of the block during model simulation.
For example, the following code would change the Gain value of a block named "My Gain" at the top level of a model called "my_model.mdl" to a value of 20:
set_param('my_model/My Gain','Gain','20');
Note, however, that only Tunable Parameters can be changed with SET_PARAM at runtime.
in order to simulate some processes I have a problem with getting a predefined working order of my self modeled blocks.
How can I be sure, that for example Block A must be finished before Block B and C start working?
The problem is, that some Blocks shall work after some others and some shall not. I must admit I have not much experience with Simulink in order of doing time-depending things (althought basic knowledge of simulink is available).
For instance this scenario shall be realised:
A -> B, C -> D, E, F
The main thing is, that all blocks A-F have no logic correlation to each other, they all do several things. My aim is to make B and C start working, after A has finished. And D/E/F after B AND C have finished.
In this case, the word "parallel" was the wrong word, this does not have to be calculated really parallely. Just making sure, that this complies with a predifined steady order.
Edit:
My new idea is to use the matlab workspace als buffer, so my block A can push its results to workspace (by the "to workspace" block). But now I have to make sure, that block B and C may read the results (with "From workspace") of A AFTER A pushed its information to workspace...how to do this?
Edit2:
Here's a screenshot which should make some thinks clearer:
As the documentation of "Sorted order" refers, the set up seems to be ok (including the subsystems timing). But unfortunately problem still exists. The variable "simin" is loaded from workspace, before it was written :( As you see, the display shows "1", which it shouldn't do. In the very first run of the simulation I get an exception, that the variable "simin" does not exist.
It would be nice, if you can help me with my issue.
Greets, poeschlorn
So in your example, if you have Block A connected with the same wire to both B and C, when Block A is finished, Block B and C will work in parallel.
EDIT:
I am using the same blocks as you are, but it works for me. I think you are over complicating things. The way you are setting block priorities is no different than how Simulink runs the blocks without them. Below you can see my setup and the output on both binary displays.
The error you see on the first run is due to Simulink not creating the variable until the first time step is being executed. When Simulink builds the simulation it sees that the variable used as input from the workspace is not created.
If the connection between the block are not enough to set the order, you can use block priorities.
A tip to test the execution order is to add an "embedded Matlab block" with a disp command displaying the name of the block.
It's not really clear what you're asking. When you say that Block A must be finished, do you mean the Output function? The way simulation works in Simulink is that the blocks are run serially, so Block B and C would never run until Block A finished it's Output function.
I don't know of any obvious way of running blocks B and C in parallel currently in Simulink.