How to solve this error

Complex signal mismatch. Input port 3 of 'modelling/powergui/EquivalentModel1/Sources/Mux' expects a signal of numeric type real. However, it is driven by a signal of numeric type complex

I have attached my simulation model and the subsystem where its showing error. I couldnt figure out how the mux data type mismatch can be solved.can anyone suggest if i should do type casting or if possible how to change data type to double

[Walter Roberson]

It looks like the 3rd signal is complex for some reason. Notice the (c ) in after the double marking.

You did not happen to include enough information for us to guess why the signal became complex.

[Walter Roberson]

We cannot tell what the sources are for the 5 signals that enter the mux. I suspect that you have some GoTo inside the two masked subsystems.

[Athulya MS]

yeah..its output of a controlled current source

[Walter Roberson]

I think we might need your slx to debug this.

[Athulya MS]

Its basically a V2G system. I have to do voltage regulation of grid using EV. For that I have used dq control and the blocks associated with it.

[Walter Roberson]

I will not look at this until after I wake up and get back to my desk.

[Athulya MS]

Still facing the same issue

[Sina Ibne Ahmed]

Hey Athulya,

I am facing the same problem. Did you eventually find out the solution?

Please let me know. My email id is [e-mail]

Answer 1

[Walter Roberson]

Look at your top level, modelling, and focus on the upper-right block, not labeled, but the one that has the three connections on the left side of it . Open that.

Inside the subsystem look in the lower center, where there is a block labeled Load with an output labeled PQ . Open that block.

In the Load block, look near the left side, and see that the second last activity before the output PQ is a MUX block with two inputs, so the output PQ is a mux of two double. One of them is derived from load, and the other is derived from Power Factor. Power Factor has to do with phased electrical signals, so we can interpret that Load is outputing a complex-valued (phased) electrical signal in the form of a mux of 2 doubles.

Now pop out of Load back to the subsystem and observe that the output PQ goes into a demux that then feeds the two parts in as Re and Im to a complex() block, giving a complex output. That complex output then feeds into the x block near the label S = 3*(V*I')/2 so we have to uneerstand that the output I1 of that /* block is complex valued. It feeds into the 2/3 gain block so that is complex valued. That feeds into the conj() block so that is complex valued. That then feeds into Break Alg. Loop 1 so open that subsystem.

Break Alg Loop 1 feeds in the complex value from the right hand side, splits it into real and imaginary parts, runs the parts independently through the same transfer function, and puts the result back together through a complex() block. [This block is adding a logical delay in order to break an algebraic loop.] So the output Out of Break Alg. Loop 1 is complex valued.

Now pop back out of Break Alg. Loop 1 and see that the (complex-valued) output feeds through a gain block that is labeled a^2 . Open that gain block and observe that the gain factor is exp(-j*2*pi/3). The effect of that is not to square the output -- that is, it is not converting complex values into real values. The a^2 label is indicating that it is multiplying by a^2 . The effect of the gain block is to multiply by (-1)^(-2/3) which is -0.5 - 0.866025403784439i which leaves a complex result. The un-multiplied output I1 is sent to [la] and the multiplied block labeled a^2*I1 is set to [lb]

Now look back further towards the center, up a couple of places above the Load subsystem, and observe there that the complex-valued [la] block becomes the S input to the Controlled Current Source block. This is possibly appropriate taking into account the documentation at https://www.mathworks.com/help/physmod/sps/powersys/ref/controlledcurrentsource.html which says,

The Simulink input signal must be a complex value (phasor) when you are using the Controlled Current Source block in a phasor simulation, because in this case, Simscape™ Electrical™ Specialized Power Systems software does not automatically convert the input signal from time-domain into complex (phasor) signal.

Likewise, the complex-valued [lb] becomes the S input to the Controlled Current Source to the right of that.

So, what is the problem?

This:

You have configured powergui (in the modelling pane to Discrete modeling, and Controlled Current Source can only accept complex-valued signals if you have configured powergui to Phasor modeling.

If you change the powergui setting to Phasor then you can get past this error.

... You then promptly run into a similar error, but in reverse, a complaint that you have a real signal driving a block that needs a complex signal. This has to do with the other subsystem in the upper right of the modelling pane, the one that has the three connections coming out of the top of it. Open up that subsystem and observe that it has Controlled Current Source blocks, similar to the first subsystem we looked at, but that this second subsystem does not have the Load blocks and other items that are creating complex signals. Notice the S inputs to the Controlled Current Source blocks come from la and lb

Pop up a level back to the modelling pane, and look in the middle a bit closer to the left hand side, to the left of the powergui block but one group below it, to the section that has the signals labeled la and lb . Notice these is la not [la] -- the [la] that we looked at is a different and complex signal. The la and lb that we are looking at now are the ones that become the inputs la and lb of the Controlled Current Source blocks in the second subsystem (the one that does not have the Load subsystem). When we switched powergui to phasor mode, then all of the Controlled Current Source blocks in the model switch to expecting complex inputs, so la and lb must be complex to get the Controlled Current Source blocks in the second subsystem to work.

la and lb are outputs of a Mux that is coming rom the block to the left of it, the one labeled dq0 at the upper left and abc in the right middle. That is a dq0 to abc convertor block, https://www.mathworks.com/help/physmod/sps/ref/inverseparktransform.html and the dq0 and wt inputs to that convertor block are both real-valued double -- which is what is expected by that block. The conversion that the block does takes separated direct and quadrature components on the dq0 input, and converts to separated phase outputs that are real-valued. The demux is being used to separate out two of the three real-valued output components, a and b, and the c output is being thrown away, and the a and b are routed over to the subsystem as la and lb . But they are real-valued and under Phasor mode for powergui they need to be complex valued.

So... you have a problem.

You need to decide whether you are going to work in Phasor mode or in Discrete mode. If you are working in Phasor mode then you need to decide how you are going to convert the abc framework into phasor framework . If you are working in Discrete mode then you need to decide how you are going to convert the phasor signals [la] and [lb] into non-phasor signals.

When I look at the model, I get the impression that it would be easier to convert the first subsystem to use non-phasor signals than to convert the rest to use phasor signals.

[Naghme]

Hello Mr. Roberson. I'm simulating a tonpilz transducer in simulink. I had stuck in an algebraic loop for days and finally I removed it by using IC block. but the input signal that drives the IC block is complex and I'm getting error " complex signal mismatch ".

and there is no options in the IC block parameters to change the signal type. could you please help me with this?

[Walter Roberson]

@Naghme

Sorry, I have not been feeling well enough lately to get into the kind of detail that I was able to handle when I responded to the above Question.