Comments on: Advanced Maneuvers using Mux and Demux

By: Seth

Seth — Tue, 27 Apr 2010 19:27:03 +0000

@Jorge – I am glad you found what you needed!

By: Jorge

Jorge — Tue, 27 Apr 2010 14:12:34 +0000

Well, Seth, you saved my day and spared me loads of rework! I’ve always complained that one could not have different initiators for a function-call subsystem and it turns out that I was wrong, thank God! Keep up with the good work.

By: Seth

Seth — Tue, 21 Jul 2009 16:44:16 +0000

@Pat – I don’t think I understand your question. The conditional execution is possible with function call subsystems or any kind of conditional control in Simulink, but I don’t understand the requirement to call a block given the “name of the function”. Are you doing this from MATLAB code? If that is the case, I think you will be able to use the string handling functions to set a flag or input variable that determines which system executes. Good luck.

By: Pat

Pat — Wed, 10 Jun 2009 08:32:45 +0000

Hi Seth
always love your small tutorial thanx.

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

By: Seth

Seth — Tue, 26 May 2009 18:00:00 +0000

@Balaji Kalluri - The behavior you are looking for is provided in the MERGE block. Essentially, outputs from conditionally executed blocks can be routed together onto the same signal line. You can see this in the model mergedemo.mdl

>> mergedemo

By: Balaji Kalluri

Balaji Kalluri — Mon, 25 May 2009 14:58:24 +0000

Hi All
I would be highly obliged, if someone can show me a route to model a typical 2-to-1 Multiplexer, the way we have read & understood it.I want to translate behavior of typical digital 2-to-1 Mux works like this into SIMULINK model.

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

By: Hans-Werner

Hans-Werner — Wed, 09 Apr 2008 11:08:38 +0000

Thank you for your hints on mux and demux blocks and function calls. Concerning function call subsystems there is one problem I´m struggling with. You can´t use function call subsystems or triggered subsystems for multirate systems. Instead of this you have to use if-action or switch subsystems.

By: tami

tami — Tue, 08 Apr 2008 16:16:53 +0000

hi seth,

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.

By: Seth

Seth — Sat, 05 Apr 2008 17:29:46 +0000

@Hans Geerligs – Your questions about bus signals are right on target, and each deserves a good post to help frame the discussion. My next post will be about bus objects and nonvirtual bus signals. Regarding unification of vectors and buses, the changes to bus signals over the past few releases have actually moved away from unifying the concepts. It turns out that there are too many edge cases that really complicate mixing of these concepts. I am planning to post about the Concatenate Block, and I hope to include some of the history behind mux and bus to give some clarification.

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!

By: Paul J.

Paul J. — Fri, 04 Apr 2008 22:43:49 +0000

Seth,

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