PMSM SMO rotor position calculation in Simulink

This is the rotor position calculation block of a PMSM_SMO simulink model.

This blcok is built based on the formula below:

MY QUESTION IS : WHY function arctan(u[1]/u[2]) is composed of u[1] = omega_c(cutoff frequency of the low-pass filter) and u[2] = omega_e_estimate(estimated instantaneous rotational speed)? WHY NOT arctan(u[2]/u[1])?(based on the formula above)?

Answer 1

[Umar]

Hi @Zhiyu,

I looked into this a bit and I think I found the source of the confusion. Based on the way the block is labeled (atan(u[1]/u[2])), this looks like it's the older Fcn block rather than the Trigonometric Function block's atan2 mode. The Trigonometric Function block only shows two separate input ports when you set it to atan2 — it doesn't let you write a custom expression like u[1]/u[2]. The Fcn block does: it treats its input as a vector u, and lets you index elements with u(1), u(2), etc. (the icon just displays that with square brackets). The important part is that u here is whatever vector comes out of the Mux right before it. And in Simulink, a Mux orders its output vector strictly by port position — top port becomes element 1, bottom port becomes element 2, regardless of which physical block is drawn higher or lower on the canvas.

So I traced the actual wiring into that Mux in your screenshot: the top port is fed by the branch coming off the "we" line (right after the 1/Flux gain), and the bottom port is fed directly by the "wc" constant (20000). That means: * u[1] = we, which is the estimated electrical speed * u[2] = wc, which is the cutoff frequency of the low-pass filter

So the block is actually computing arctan of (estimated speed divided by cutoff frequency) — which matches your formula: estimated angle equals the base angle plus the arctangent of estimated speed divided by cutoff frequency. In other words, I don't think there's an actual error in the model — it looks like the u[1]/u[2] assignment in the question might have gotten flipped when reading the diagram, which is an easy thing to do here since the "we" line bends down before entering the Mux while the "wc" line goes in almost straight across.

Worth double-checking directly in the live model to be 100% sure: click on each wire and it'll highlight its full path, or hover over each Mux input port and it'll show a tooltip with the signal name.

[Zhiyu WANG]

Thank you, Umar.The fact is that I flipped the Fcn to make the two signal lines parallel but Igot the same result.With the figure below, I am sure that the "u[1] = Wc and u[2] = We" hence "atan(u[1]/u[2]) = arctan(Wc/We)".In a word, it`s not a LINE MISMATCHING problem.Can you give me some other advice?

[Umar]

Hi @Zhiyu, Thanks for sending the updated screenshot — I traced it again carefully, and I want to walk back my earlier assumption. In this diagram, the wc (20000) line bends down into the top Mux port, and the we line (tapped after the 1/Flux gain) goes into the bottom port. Per Simulink's own Mux documentation, port order is strictly top-to-bottom, so that gives u[1] = wc and u[2] = we — meaning the Fcn block is computing arctan(wc/we), not arctan(we/wc). That's the reverse of what your formula calls for, and this time it doesn't look like a case of misreading a crossed wire like the first screenshot — the ports genuinely seem swapped. To be clear, this isn't the Mux behaving unexpectedly — it's following its documented port-ordering rule exactly. If there's a mismatch, it would be in how the two signals were connected to the ports when the diagram was built, not in the block itself. Since screenshots have tripped us up twice now, I'd push for a purely numeric confirmation rather than reading the diagram a third time. Force two very different test values into Ealpha/Ebeta so we comes out small (say ~50 rad/s) while wc stays at 20000, then put a Display right on the Fcn block's output: * If it reads ≈ 0.0025 rad (tiny) → u[1]=we, u[2]=wc, and the model matches your formula. * If it reads ≈ 1.57 rad (near 90 degrees) → u[1]=wc, u[2]=we, confirming the inversion. If you get the second result, the fix is simple: just swap which line feeds the top vs. bottom Mux port so we lands on top (u[1]) and wc on bottom (u[2]). That test will settle it for good, independent of how the wires look on screen.