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.

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.”
———————

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?

@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 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.

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.

Best Regards