How to retrieve the library block path once a block is created in Simulink?

Hi,

I am wondering how to retrieve the library block path that we use for block creation after the element has been created.

If we want to create a new Scope Block that can be found through the model browser in the following path: 'simulink/Sinks/Scope', we execute programmatically the following in the MATLAB console:

scope = add_block('simulink/Sinks/Scope','model/ScopeName');

to get the block type we can use:

scopeBlockType = get_param(scope, 'BlockType')
% answ = 'Scope'

To my knowlege, there is no parameter we can ask to the recently created block to retrieve the original "simulink/Sinks/Scope" which is required for creation. For some use cases e.g. if we want to automate the creation extracting information from already existing blocks, this information would be indispensable.

What complicates things is that for some blocks the BlockType property does not match the name of the block on the path used for creation. For example, when we create a Stateflow Chart block, we call:

chart = add_block('sflib/Chart','model/MyChart');

which returns a different BlockType

chartBlockType = get_param(chart, 'BlockType')
% answ = 'SubSystem'

This complicates when we search for blocks of a given type, which must be specified through the use of 'BlockType' as follows:

list = find_system(model, 'BlockType', 'SubSystem');

which returns blocks that have the same 'BlockType' property but could have been created with different block signatures (e.g. 'sflib/Chart' or 'simulink/Commonly Used Blocks/Subsystem'). To my knowledge, there is no way, other than naming conventions or block-specific properties, to tell them apart or to get the signature used for creation.

I have also tried the following without any success:

libinfo(handle)

I would appreciate if you could tell me if I am missing a method or property which returns this information or to consider implementing this functionality.

Answer 1

[TAB]

Its not possible to retrieve the source of model blocks which are from built-in library.

But you can search the in the Simulink library for using properties of block used in model.

% Your block in model
scopeBlockType = get_param(scope, 'BlockType');

% To find the source, simply used find_system
open_system('simulink');
blkPaths = find_system('simulink', 'BlockType', 'Scope');

blkPaths = 
     'simulink/Commonly Used Blocks/Scope'
     'simulink/Sinks/Floating Scope'
     'simulink/Sinks/Scope'

But in my opinion this is not required.

All library block paths are always fixed. So in your automation script you can just use the table of hardcoded paths and use that table to find the source path of the block;

For example:

blkPaths = {'Inport', 'Scope';  %BlockType/Name etc
            'simulink/Sources/In1', 'simulink/Sinks/Scope' %Corresponding block paths};

[Beatriz Sanchez]

Thanks @Tabrez, this is certainly useful to build a map of the block types and library block paths e.g. through the following snippet

load_system('simulink')
simulinkLibraryPaths = find_system('simulink', 'Type', 'Block')
simulinkLibraryBlockTypes = get_param(libraryPaths, 'BlockType')

However, I disagree that this functionality is not required. The fact that we can build a map does not help on the retrieval of the original library block path from an instanced block.

Take the following scenario as an example. We may be working on an analysis or validation script executed on an already existing model. We are not creating blocks but rather retrieving already created blocks (e.g. through find_system). In this scenario we want to analyze or perform an action on blocks created from a specific library block e.g. 'sflib/Chart' which is of 'SubSystem' block type. The problem arises when the model being analyzed has not only many 'sflib/Chart' instanced library blocks but also many 'simulink/Commonly Used Blocks/Subsystem' ones. The blocks created with the latter library block path share the same block type as the Chart blocks (i.e. 'SubSystem'). How can we make the distinction other than through naming conventions or specific property values?

If no function exist to link the original library block to an instanced one, we can only guess. I believe there should be an inherent block property which references the library block path used at instantiation.

Answer 2

[Robert]

At least in the serialised form of a model (a model file) there is no history of all the editing actions that have been applied to the model in the past. So if you actually want to analyse such kind of history, you can't be helped, because it's simly not there.

This is not to be confused with a library link that consists of a reference to a subsystem in a library (And many "blocks" you will find in the simulink library are actually masked library blocks)

But if you want to do a functional analysis of the model, only block types and parameters are of interest, as they define the functional behaviour. If you want to get a list of (built-in) block types available in your version of simulink, you can use the code:

hSlLib = load_system('simulink');
hSlLibBlks = find_system(hSlLib, 'LookUnderMasks', 'all', 'Type', 'Block');
unique(get(hSlLibBlks, 'BlockType'))

(Assuming all available block types are contained at least once in simulinks standard library 'simulink').

Note that stateflow blocks are not builtin blocks, but rather S-Functions that are not easy to find out about, as with different versions of simulink they behave differently in conjunction with the simulink API. See some solutions in this thread: https://au.mathworks.com/matlabcentral/answers/156628-how-to-recognize-stateflow-blocks-using-simulink-api-get_param