9 CommentsOldest to Newest
Thank you very much for your post.
Can you please explain how RTW generate code for composite signals?
Pretty good post. Hope to forward it on to a few people who’ve asked me about the difference between Mux and Bus.
With the section title “It started with mux” I was hoping to see a little history of the mux/bus confusion and source of the “Mux blocks used to create bus signals” diagnostic. I’m not entirely clear on this, having not used versions of Simulink without the Bus very extensively.
Also, in my mental model I think of the Bus Creator and Selector blocks disappearing and the bus being transformed into a bundle of lines. However, I don’t think of the Mux and Demux blocks in this way. And I think the reason for this is experience with how RTW generates code for muxed signals:
– I thought they showed up as arrays in the code
– I know I’ve had trouble routing individual elements from a Demux to separate root outports controlled by Simulink.Signal objects. The error is usally something like “The Simulink signal object specified on the line originating from output port 1 of ‘model/subsystem with demux’ is invalid because it cannot be uniquely mapped to a valid signal in the model.” In these situations we’ve dropped in a Signal Conversion block before the root outport.
Well, my first experience with Simulink was actually SimuLAB 1.1. There were Mux and Demux blocks, but no Selector blocks yet. I abandoned Simulink for SystemBuild (much more mature for what I needed to do at the time) and didn’t really come back to Simulink until R13 in 2002, at which time I discovered Buses.
I hope you get into bus objects in this series, since they are one of the most important parts of the whole bus concept: allowing you to lock down an interface. Maybe you can tell us why you can’t annotate bus elements with, say, units fields the way that you can signal objects. I would dearly like to document units and general free-form descriptions with my bus objects and bus elements but I can’t do this currently. I did turn in a bug report / enhancement request on this.
@Mansour – I plan to show some code generated from mux and bus as part of this series. Thanks for the request.
@Bob – I’m glad you liked the post. I have to admit, when I wrote that section title, I too was thinking about the history of the mux/bus… you are on to us. The two blocks have a shared and interesting past. I have been talking to some of the developers who were part of the team that made the early design decisions, and when I fill in more details I’ll post about it.
I’m intrigued by your Simulink.Signal error. Would you send me an example I can include in the blog? If I get a chance, I’ll take a shot at reproducing this. I think I have seen this before.
@KMR – Thanks for the comment. You are right on about the benefits of bus objects as an interface specification. We will be going into that. You are not the only one to ask for the ability to add documentation to bus elements. That would be an ideal way to further incorporate elements from an Interface Control Document (ICD) into the model… or better yet, allow the model to generate the ICD.
i just want to ask about serial to parallel and parallel to serial block in simulink communication blockset.
how to design it in simulink??
Very interesting your articles. I am new in Matlab and I need help about serial to parallel signal conversion in Matlab. Specifically convert 1 dimensional signal to 2 or more 1 dimensional signals. Could you help me?
I forgot to told you that I’m working in Simulink and in this context I need this help.
In my model, I have a bus creator composed by signals of different types. This bus passes through an enable subsystem to be discretized. This model raises the following error: “Input port cannot accept mixed data type”.
The help of the Inport block comments this error, as explained bellow. But I don’t understand why it is not possible. Will Mathworks improve this issue?
In Inport help:
“Signal elements connected to a subsystem input port can be of differing numeric and data types except in the following circumstance: If the subsystem contains an Enable or Trigger block or is an Atomic Subsystem and the input port, or an element of the input port, is connected directly to an output port, the input elements must be of the same type. For example, consider the follow enabled subsystem.”
I know that this is an older “blog”. Nevertheless, the idiosyncrasy one encounters when trying to demux a vector into individual signals entering outports remains. There ought not be a need to make a copy of a signal after you extract it from a vector. However, in order to satisfy the requirements of “Valid outport connections”, one is obligated to do so.
Two types of errors are encountered, depending upon the style of implementation.
One error has been cited in the text above. (“The Simulink signal object specified on the line originating from output port 1 of ‘model/subsystem with demux’ is invalid because it cannot be uniquely mapped to a valid signal in the model.”)
The alternate type of error is: “Warning: Invalid root Outport block connection in the referenced model ‘mdlName’. Only 1 element(s) of output port ## of block “contained libray block” drive the root Outport ###.
To be a valid connection, all of the signal’s
elements must drive the root Outport block to which it is connected. Simulink inserts a hidden Signal Conversion block (with the
‘Exclude this block…’ option enabled) before the root Outport block.”
Yet, the connections which promt this diagnostic are structurally quite similar to any of the demux illustations shown above.