I am struggling to see how I could implement the following, I suspect I might have to use function call or the like but I am simply not sure how and what to do.

let suppose I have a subsystem compose of 2 independant block
the first block implements a simple addition int<-mysum(int, int) and the second block implements sqaring int<-mysquare(int). I want to be able to call the execution of one of this block by given the name of the function to call and arguments using simulink

Thank a lot for any hints

pat

>> mergedemo

if(sel==0)
out = in1;
elseif (sel==1)
out = in2;

i am interested in learning how TeX format can be used in the “documentation” tab of a subsystem. it does not seem to work and i have been told that functionality is not available now, but it sure would be great to add that in.

Rate transitions are a big topic. I plan blog on this. Thank you for the great suggestions.

@Paul J. - Specifying dimensions is a must for root level inports. The Model Advisor incluses “Check root model Inport block specification” which reports this message:

Your model contains root-level Inport blocks with undefined attributes, such as dimensions, sample time, or data type. If you do not explicitly define these attributes, Simulink will use back-propagation from downstream blocks to assign values to the attributes when updating the model. This can lead to undesired simulation results. To avoid this, fully define the attributes of all of your model’s root-level Inport blocks.

I see specifying root Inport information as being good modeling style. For subsystems, it is optional, but it really depends on how you are treating the subsystem. If the subsystem is a utility from your library and it is designed to handle any width vector input, it makes sense to leave the size inherited (-1). When the subsystem is a functional unit (atomic subsystem) and you can define it’s interface, I think this is the time to include dimensions and even type information. If you are only using subsystems to group blocks, and simplify your model (virtual subsystems), specifying sizes is unnecessary.

Function call subsystems are going to be a future blog topic. Thanks for adding your voice to the community!

I’d be interested in more discussion on when it’s a good idea, or a requirement, to specify the dimension and/or sample time of Inports either at the root level or in subsystems. Also, more discussion, with examples, on the use of function call subsystems would be interesting.

Thanks,
Paul

firstly, kudos for your blog. Nice to read about mental models, as this is the way I face Simulink.

Some remarks/questions:
* is any unification of vectors and buses foreseen? One might consider buses as “hierarchical named grouped vectors”
* I checked on the “bus selection mode”: it is possible to feed one scalar into a demux with bus selection mode=on. According to the documentation it should not be possible. Is this by design or accidentally?
* are there any plans to break compatibility between buses and vecors, as enabled by the bus selection mode?
* I would be interested in more explanation on virtal/nonvirtual buses. Is this in the pipeline for your blog?

A little off-topic: I am also interested into the relation between asynchronous rate transitions (various setups for this), the simulation of it and the code generation for it. Any plans to blog on this?