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.
Related
I have read the Mathworks documentation carefully and tried to find a solution on forums as well. However, I have not been able to find a solution to my problem yet.
I am using Matlab/Simulink to simulate the dynamics of a vehicle, which picks up an object during operation. The way I am planning to do this is to:
Simulate the motions of the vehicle by itself at the start of the simulation;
Stop the simulation, save the final state, update the model parameters (so that they now represent the vehicle and the object)
Initialize the simulation again starting from the end time of the previous run and using the previous final state as input state to the new simulation.
To do this, I have been using the options FastRestart, SaveFinalState, SaveCompleteFinalSimState and update. Unluckily, the simulation runs seamlessly, but the model parameters are not updated.
The dynamics of the vehicle and vehicle+body are modelled by the same C-coded S-function. This function receives the parameters of the dynamic equations (e.g. inertia, damping, etc.) as parameters to the S-function block. I think this is the main problem with my approach: even though I run the update command, the S-function does not recognize the update of the parameters in the workspace. Do I need to recompile it? I guess that is not feasible under Fast Restart mode, is it?
Any advise is really appreciated! Thank you!
I have a similar issue to this in a different situation. Trying to update the initial state target of a revolute joint, the fast restart option does not change the property.
I have had some luck updating the model in fastrestart with other parameters, however, using:
set_param('Model_Name','TunableVars','Variable Name')
Not sure if this will help in your situation, perhaps saving the final state as a variable and having the respective variables as initial parameters.
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...
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.
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.