MUX blocks and RTW code generation

In a model we are trying to build for rapid prototyping bypass we have a mux block that has a bunch of signals going to it. Whenever we try to make the output signal of the mux block have a storage class and build it we get the following error:

The signal attribute {StorageClass = 'ImportedExtern'} specified on the line originating from the output port 1 of HVM_model/Function-Call Subsystem/VaVITC_U_HV_BatCellVolt/Mux is invalid because the individual signals contained in this line are mapped to different memory locations. The StorageClass for this line must be set to 'Auto'

But if we place a convert block after the mux then make the signal after the convert imported_extern it is able to build.

It also seems that this mux block is messing with the values of the incoming signals. We checked the outputs of several ehooks read blocks and verified that the signal is being read in properly but when all of these signals are put together with a mux all of the valuesare changed to a static value ogf 66, which is very wrong. Any insight on why this is happening would be greatly appreciated.

Answer 1

[Guy Rouleau]

Good question!

The Mux block is virtual. The line coming out of the Mux block is just a visual representation. This is why you receive an error saying "the individual signals contained in this line are mapped to different memory locations".

When placing a Signal Conversion block after, the input signals stored in different memory locations are all copied into one contiguous piece of memory.

If you are looking for a block that combines the signal both visually AND in memory, you might want to use the Vector Concatenate instead.

For your last problem, I am not sure. My best guess is that it has something to do with Signal Reuse. Try disabling this optimization option and see if this helps.

[Michael Joslin]

Thanks for the advice! I'll try what you suggested and see if it works.

[Michael Joslin]

I used your suggestions and my model is working! Now I just need to convince all of my coworkers to stop using mux blocks......

[Guy Rouleau]

In my opinion, one can leave without Mux by using either buses or vector concatenate, depending on the context. The diagnostics I mention in this post can help avoiding confusions:

http://blogs.mathworks.com/seth/2010/11/19/bus-signals-past-present-and-future/

I am not saying that you should avoid Mux blocks at all costs... but if you want, you can make it disappear from the Simulink Library Browser using an sl_customization:

http://www.mathworks.com/help/toolbox/simulink/ug/br1calz.html#br1caqo

This is really simpler than it looks. Of cours,e this does not cover against Mux blocks already in a model, but since it disappears from the library, chances that it is added in new models are very low.