Simulink Signals Data Types

I have a script which creates simulink bus creators and their relative input/oupt blocks programmatically from a simulink data dictionary.

In some cases it is needed to have the same signal as an input in different buses and i have not found a solution to reference the data dictionary signal multiple times across the project.

I would like to have diffent signal block names for the same signals, but only one reference entry in the data dictionary.

I was wondering if there is an explicit casting type for signals as the one for buses that would do the trick:

Pretty much allong the lines of: Signal: <signal name>

Answer 1

[Fangjun Jiang]

The best approach is to Create Duplicate Inport Blocks.

https://www.mathworks.com/help/simulink/slref/inport.html

To do it by script, I think you only need to set the duplicated port number.

"In2" and "In3" are block name, not signal name.

You can set the data type for the signal as long as the data type is defined. The data type could be those built-in, such as single, int8, etc. or defined in your data dictionary. Take a look at all the possible options in the "Output data type" dropdown list.

[Luca Ferro]

Duplicating blocks is a very good idea since they will retain the data type and all but i can't quite understand how to do that programmatically and what do you mean by 'set the duplicated port number'.

I badly formatted the sample screenshot (it's not from the code), the block name is the same as the signal name with an enumeration to differentiate them. Sorry about that.

I'll rephrase: I want to use my signal as a 'datatype' so that multiple input blocks can inherit the signal properties from the data dictionary.

I was already familiar with the documentation you linked, and;

I'm pretty sure i cannot use Value Type since singals are Handle types and not Value ones.

As per the Custom Data Type, i'm unsure about both the syntax to use and if it will really inherit from a Signal Object and not specifically a Custom Data Type Object.

[Fangjun Jiang]

Okay, I tried but I can't add duplicated Inport block through script, by setting 'Port' or 'PortName'. Please contact tech support to see if there is a way.

Regarding signal data type, what do you have in data dictionary for it, Simulink.Signal object or Simulink.AliasType or something else?

[Luca Ferro]

I really appreciate your help and effort by the way.

Simulink Signal Object.

A solution i was thinking was to create a carbon copy of each Signal Object to be a Custom Data Type Object and then cast that to the block. Not something i would like to do though, since it doubles the objects' number and i'm not really familiar on how to use those and where they are stored (in the data dictionary i guess (?)).

[Fangjun Jiang]

If it is a Simulink.Signal object, then the correct way is to check the signal line property 'Signal name must resolve to Simulink signal object' and specify the object name.

This should be done in only one signal line in the entire model, be it at the output signal line of a particular block, or at the output signal line of a root-level Inport block.

At everywhere else, such as the Inport blocks that you are working on, the data type should be set as inherit. Once these Inport blocks are connected, the correct data type will be propagated.

In some cases, you might want to set the data type of these Inport block separately. Then you can read the data type info from the Simulink.Signal object, and set it to the Inport block.

[Luca Ferro]

Unfortunately i didn't find the proper solution to what i was trying to do.

The closest i got was this:

oph=get_param(path2block,'PortHandles').Outport: %get block port handles

set_param(path2block,'SignalNameFromLabel',sgnName); %set block port label

set_param(oph,'MustResolveSignalObject','On'); %reference signal in workspace

This allows multiple references of the same signal (with definition in data dictionry and ported to workspace) from different inport blocks, but still creates some error in code generation.

[Fangjun Jiang]

The error must have been caused by the "multiple" references. The "resolution" can only be done at only one place, the true source of that signal. All other places are destinations, not soure. They inherit the signal data type.

[Luca Ferro]

For know i will workaround this issue by creating multiple clones of the same signal with a different naming convention in the data dictionary and reference them singularly. It is not as clean but it does the job pretty conveniently. If i somehow progress on the matter with the other method i will let you know here.