I have a series of ToFile blocks in my Simulink model that each have a unique filename (e.g. "Pulse.mat". I want to store the results of my simulation in timestamped folders based roughly on when I hit the run button / use the sim command.
My solution was to write two scripts, one called during the InitFcn callback and one for the StopFcn/CloseFcn callback (and PreSaveFcn callback).
The InitFcn callback would find all ToFile blocks and change the filename from "Pulse.mat" to something like "../runs//Pulse.mat", and the StopFcn/CloseFcn/PreSaveFcn to revert them to their original ".mat" names. This worked on my small test model, however when I attempted to integrate it into my actual model I receive the following error:
Error evaluating 'StopFcn' callback of block_diagram '<model_name>'.
Caused by:
Cannot change parameter 'Filename' of '<ToFile Block>' while simulation is running. The block was made virtual as it was optimized for simulation
From my research I discovered that the StopFcn actually executes before the simulation is "done" (for whatever reason), but why did it work in my initial test model? Do my ToFile blocks in my actual model have some property set that causes this error to occur?
The block has been virtualised in your larger model; which seems to be changing the execution point. One option might be to untick 'Block Reduction' in the 'Optimisation' pane of the model configuration parameters dialogue.
Alternatively, there might be another approach that you could try -
Setting the model properties 'StartFcn' to something like :
evalin('base','resultTimTag = datestr(clock, ''yyyymmdd_HHhMM'');')
and setting the model properties 'StopFcn' to :
targetDir = evalin('base','resultTimTag');
mkdir(targetDir);
outputs = dir('*.mat');
for i=1:length(outputs)
movefile(outputs(i).name,targetDir);
end
evalin('base','clear resultTimeTag');
It's possibly a little more brute-force than your approach, but seems to work quite nicely...
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 simulink model which takes Bus signal as input. I have passed the bus signal data using Configuration->Data import/export ->input
Now I want to vary this signal from workspace when model is running and see the output during runtime.
But model is taking new data from workspace only when you stop the model and run again. Is there any way to feed the input to model during runtime?
By default Simulink looks in the Workspace for data at initialization, not at every time step. Hence the behaviour you are seeing.
To make it look in the workspace during the simulation you need to force it to do so. This can be done by using set_param to change a dialog parameter.
Once you've made a change to the variable in the workspace, in your case, something like set_param(gcs,'ExternalInput',get_param(gcs,'ExternalInput')) should work.
This is just getting the string that is in the dialog box and poking the (same) string back into the dialog.
This tells Simulink that something has changed and it'll go and re-read the variables.
I've been having this issue since I started using this Simulink model. No matter what I try, Simulink rebuilds the model every time I run it. I've taken a look at the checksums using the following procedure:
>> [cs1, cs1det] = Simulink.BlockDiagram.getChecksum(<model name>);
>> (Here I hit run on the model without changing anything)
>> [cs2, cs2det] = Simulink.BlockDiagram.getChecksum(<model name>);
>> cs1 == cs2
1
1
1
1
Why would Simulink rebuild the model if the checksums are the same? I did create another model with some simple logic in it and after compiling once I was able to run it multiple times without Simulink recompiling it.
Additionally, when I hit run when in Rapid Accelerator mode I notice that an asterisk pops up next to the model name in the title. Since this means that the model has unsaved changes, could running it cause any changes to be made? I've checked the callback methods and there's nothing being run when the sims starts (in fact there's nothing in any of the callback methods).
Is there some kind of basic compilation / initialization / build that Simulink runs through before it runs every time? I'm trying to run my model in Rapid Accelerator mode without having it recompile since it takes roughly 45 minutes to compile every time.
Have I overlooked some configuration parameter of the model? Is there some global MATLAB/Simulink variable I need to change?
Is it building or is it updating?
Typically, when you hit the Run button, MATLAB has to propagate signals, check your model for errors, initialize variables . . .
It may seem like building, but to actually confirm it is building, check to see of you have yourmodelname.c file in the folder.
Also check File Menu preferences, and go through the functions there and see if something is getting called.
Could you try to set Configuration Parameter -> Code Generation -> Interface -> Code replacement library to None (In case that your demand is not related to GNU library ...) on reference model?
By the way, it is working for me.
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.
I am looking to set up a test set for an existing Simulink model. Ideally I could take full control of the model, explicitly stepping it and measuring the state of any signal on any bus in the model.
As might have been gleaned, this is the precursor of a unit testing system for the model. Being so, I can't really justify changing the model to suit the test, the test must accommodate the model as-is.
The furthest I've got so far is using load_model() to return a handle to the model. From there there seems to be a quite obscure set of functions for accessing the model. I can't see any that relate to accessing states and can't see any further commands that relate to accessing a loaded model.
The easiest way is to use the Data Import/Export function within the Simulink Preferences.
Set the checkbox States and it will store every state of your system for every time step in your workspace, also when you pause the simulation or execute it step by step.
Be aware not to set Save simulation output as single object, in this case the access would be more complicated and you need to follow the instructions here.
To add to the other answer, you probably want to check this page in the documentation: Control Simulation Using the set_param Command. Of interest are the following commands:
set_param(<model_name>, 'SimulationCommand', 'start')
set_param(<model_name>, 'SimulationCommand', 'pause')
set_param(<model_name>, 'SimulationCommand', 'WriteDataLogs')
set_param(<model_name>, 'SimulationCommand', 'continue')
Replace <model_name> by the path to your model file.