I have a Simulink model that includes a lot of inter-connected subsystems. A lot of these subsystems are connected to the other with "goto" objects. For verification and documentation purpose, I need to get the complete list of inputs/outputs of each sub-system, and check that the subsystem are connected between them as expected. Checking manually each connection is really time consuming and I often make mistakes doing it. Is there a way (function/script/command) to obtain the list automatically? Thank you very much if you can help me.
Firstly, have you considered using the Simulink Model Advisor to do this? You can create your own custom checks.
Secondly, it is possible to determine which blocks a sub-system (or any other block is connected to)
Selecting a block manually in the model and then running the following, will give you a cell array of all the blocks that the current block is connected to.
connected_to = get_param(gcb,'PortConnectivity')
If the block has 4 inputs, then the connected_to variable will contain 4 items. You can get the Source Block name by doing
srcBlockName = connected_to(1).SrcBlock;
Typically you would work from the outports back through the model to the inports or other source blocks checking what is connected to each.
There is a subsystem in my model called 'addBlock'. Inside it, I generate InPorts during Mask Initialization based on the number of inputs that the user specifies. For example, if the user says there are going to be six blocks connecting to this subsystem, I generate 6 input ports.
Now, say I specified six inputs. The first time I double click the block and specify this it creates 6 inputs. However, if I double click the mask again and hit OK, it creates 6 more inputs numbered 7 through 12.
What I would thus like to do is to delete everything within the subsystem every time I open the mask and start creating blocks from scratch. Is there any way of getting a list of every block that exists within a subsystem?
Thanks in advance.
I found the answer for this, in case anyone in the future looks it up. The method is to use
Simulink.SubSystem.deleteContents(gcb);
The gcb bit returns the name of the current block, which would be the block you want anyway because you're in that block's mask. Also, note the different camelCases. The solution is a bit inelegant because the whole subsystem needs to be created from scratch, but it does the job.
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.
Simple question:
I've added some scales (sliders) to my window, and I want to call a method when you move the scale.
What is the signal name that I use for gtk_signal_connect?
ie I should be able to write something like:
gtk_signal_connect(GTK_OBJECT(my_scale), "scale_moved", (GtkSignalFunc)my_event, data);
or am I missing something here?
And more importantly - how do I find out in the future what the signal names are? for example - I googled 'gtk_signal_connect' but I didn't find a big list of different signals.
Similarly, I didn't find details about related signals in the GtkScale documentation. (Well, in this page, there is a single signal detail, but it relates to changing the displayed value format).
GtkScale inherits from GtkRange, and signals are inherited in GTK+. Therefore, you can connect to the value-changed signal exposed by GtkRange.
You're on the right track to find the signals exposed by a given GTK+ widget: besides the source code itself, the documentation is indeed the canonical resource, but you should also take the base classes into account in your search.
I'm trying to apply edge filter to an image using Xilinx blocks,
I used 5x5 buffer then I connected the 5x5filter to it.
But it keeps telling me:
Illegal Period, This blocks attempts to set period that is a non-integer multiple of the system rate
Error occurred during "Block Configuration".'
which I did not understand.
Similar such problem(with solution) is posted in Xilinx Forum. Go through the link given below:
http://forums.xilinx.com/t5/DSP-Tools/Can-any-1-help-me-regarding-FIR-implementation-in-system/m-p/33650#M1463
It means that the sample time of one of the block isn't an integer multiple of the model's minor timestep. Check the configuration parameters for the model and the parameters of your new blocks.
I don't think this has anything to do with the Xilinx blocks specifically.