Simulink Matrix multiply error: unexpected scalar signal mismatch

I'm confused by a Simulink error relating to a "mismatched port size".

I have a scalar signal in a feedback loop -- the exact configuration isn't relevant (I think), but the point is that it's a number (not vector) as far as I can tell: I know this is a single number, because I can Display it as a single number, and/or Show Value of the wire during running.

If I insert a simple filter inline with this number output from the matrix multiply, I get an error of matrix multiply propagation error.

Here's what works:

I display dims on all signals, so no display means scalar.

This doesn't work:

SL is confused on dims for some reason.

Error:

Why? Isn't a matrix multiply output just a number, if the dimensions end up as 1x1?

What am I misunderstanding?

I haven't found any block options to force proper dims.

[Walter Roberson]

Why would the dimension end up as 1 x 1? Your second calculation appears to do matrix multiplication of two 1 x 2, which would be an error.

Or possibly your [Kx] is intended to be 2 x 1 -- but Simulink notes 2 x 1 differently than 2 .

If [Kx] is intended to be 2 x 1 your might need to put it through a reshape block.

[John]

@Walter Roberson "Why would the dimension end up as 1 x 1"

1x2 * 2x1 = 1x1

I thought the output dims is verified as 1 for the reasons in the original post... is my thinking wrong?

It also goes into a summing junction that is only scalar 1x1 values, so anything not 1x1 wouldn't work in the first place, even in the case without a filter, that I show does work:

"Simulink notes 2 x 1 differently than 2"

Ah -- interesting; I didn't know that. Kx is a 2-element vector obtained from a 4-element input, broken up like so:

Kd =
4.4954e+02   1.6826e-01   1.0000e+00  -1.6037e+05

Just to check, are you saying that Kx is not 2x1 as I thought it was?

"you might need to put it through a reshape block."

I see...i already thought it was 2x1, so how would I do that?

Answer 1

[Paul]

That block mutiplies the inputs from top to bottom as if they are left to right. So that block is really doing

xh * Kx,

when you want it the other way around. So make Kx go into the top port and xh into the bottom port.

Then, you need to make sure that Kx is truly a 1x2 vector (or xh is a 2x1). Does Kx source from a Constant block? If it does, make sure that in that block the "Constant value" parameter is a row vector and uncheck the 'Interpret vector paramters as 1D'.

[John]

@Paul "Does Kx source from a Constant block?"

It's a workspace variable input from a constant block that references the matlab workspace. See my answer to Walter's post on how I get Kx broken out from a 4x1 gain input from a constant block

"That block mutiplies the inputs from top to bottom as if they are left to right. So that block is really doing

xh * Kx, when you want it the other way around. "

Hmmm...just to understand more, why would I want it the other way around?

I thought it was supposed to be what i currently have:

xh(1x2) * Kx(2x1) = output(1x1), since 1x2*2x1 = 1x1 (scalar)

Or equivalently Kx(1x2) * xh (2x1) = 1x1 if i reversed the inputs and dimensions. Either is for an (ultimately) K*x feedback, which should give a 1x1 command signal u.

I don't believe I want a 2x2 as the output...if the order was reversed, wouldn't that give 2x2?

Also, the current configuration seems to work with I feed the output into a summing junction that includes other scalars? Since these inputs and outputs (and the output of xh * Kx as shown in the first post) are scalars since dims aren't listed on the wires, isn't it doing what I expect, which is outout a scaler?

It's clear I'm missing something, so just trying to understand more :)

[Paul]

Assuming that the 'Constant value' parameter is a row vector and its output is directly connected to that inport indicated by Kd, my suggestion is:

Uncheck the 'Interpret Vector Parameters as 1D" in the Constant block. The dimension of the output should be shown explicitly as [1x4].

Connect the Kd inport to single Demux block. For the 'Numer of outputs' parameter use [2 1 1]. The Mux block will have three outputs. The dimensions of the first output, Kx, should be shown explicitly as [1x2].

Make Kx the first input to the Matrix muliply block and xh the second to implement the standard K*x used for state feedback.

This all assumes nothing else in the model is mucking around with the dimensions of these signals.

[Paul]

Unless there's some other need for using the Constant block and distributing the elements from there via a Demux , a better solution, IMO, would be as follows.

Use Kd(1:2), Kd(3), and Kd(4) as the 'Gain' parameters in three separate Gain blocks, where you need them. The input to the first block with the parameter Kd(1:2) that is for the state feedback would have xh as the input signal. Set the 'Multplication' parameter in that block to Matrix(K*u) (u vector).

I think this approach will reduce clutter in the diagram and look more like a control system

[John]

Thanks @Paul.

"Use Kd(1:2), Kd(3), and Kd(4) as the 'Gain' parameters in three separate Gain blocks, where you need them."

The reason I'm doing it this way, is because the gains are inputs to a subsystem; so they need to be separate if the subsys is to be modular. Unless there's another way to do that...?

[Paul]

But why is it neccessary to have the gains as input signals to a subsystem in the first place? If that helps provide you visual clarity of the diagram, or if there is some other reason to structure the model that way, then doing it that way is fine.

All I was saying is that you don't have to do it that way. Instead you can just use Gain blocks where you need them inside the relevant subsystems and set the Gain parameters of those blocks to be the necessary elements of Kd. Doing it this way, the block diagram looks more like the control system you're modeling, IMO. I was just pointing this out in case you weren't aware that a Simulink block parameter can be any Matlab expression, like Kd(1:2); it doesn't have to be a Matlab variable name.

[John]

"All I was saying is that you don't have to do it that way. Instead you can just use Gain blocks where you need them inside the relevant subsystems and set the Gain parameters of those blocks to be the necessary elements of Kd. "

Yes, thanks :) I was aware of that, but appreciate you mentioning just in case.

"But why is it neccessary to have the gains as input signals to a subsystem in the first place? If that helps provide you visual clarity of the diagram, or if there is some other reason to structure the model that way, then doing it that way is fine."

It's so that i can have a common reference subsystem that i can use in multiples places, but have inputs that vary for each equivalent instantiation.