Six-Phase PMSM FEA Block Working as Motor

Hello,

I work on dual three-phase PMSM simulation. Now, I have exported flux linkage LUTs as function of current and angle from Ansys Maxwell, and loaded them to my MATLAB workspace.

I would like to take benefit from this ready Mathworks example, which connects Motor-CAD data of 6-phase machine to Simscape simulation with the help of a customized Simscape block: https://www.mathworks.com/help/sps/ug/import-fem-motorcad-six_phase.html

But the problem is, that this customized block is implemented as a generator in this example! Can I still use it directly as a motor, just by applying voltages as input and reading mechanical quantities on outputs (i.e. by cchanging the energy flow)?? Or should I make changes on the core equations inside the block?? Maybe people who developed this example can answer me in the best way possible.

I appreciate any effort to help.

Thank you in advance,

Ali Bashabsheh

Answer 1

[Umar]

Hi @Ali,

Thank you for your detailed question about implementing the dual three-phase PMSM using the Motor-CAD import example. I understand you're looking to adapt the custom Simscape block from the six-phase machine example to work in motor mode with your Ansys Maxwell flux linkage LUTs. Let me address each of your concerns systematically.

Direct Usage as Motor vs. Generator

Yes, you can use the custom block directly as a motor without modifying the core equations. The fundamental electromagnetic relationships in the custom Simscape component are inherently bidirectional. The key difference between motor and generator operation lies in the energy flow direction and boundary conditions, not in the underlying flux linkage equations. Here's what you need to understand about the implementation:

Energy Flow Direction The custom block uses flux linkage tables (lambda= f(i,theta)) to compute electromagnetic torque and back-EMF. These relationships are physically bidirectional:

• Motor mode: Electrical power flows in → Mechanical power flows out
• Generator mode: Mechanical power flows in → Electrical power flows out

The block automatically handles this based on your simulation setup - specifically how you connect voltage sources and mechanical loads.

Practical Implementation Steps

1. Boundary Condition Changes Instead of modifying the block internals, simply change your simulation boundary conditions:

For Motor Operation: * Apply voltage inputs to the electrical terminals (rather than mechanical torque/speed) * Connect mechanical load to the shaft output * The block will naturally compute currents based on applied voltages and back-EMF

Current Generator Setup (from example): * Mechanical input drives the shaft * Electrical terminals see the generated voltages

2. Using Your Maxwell Flux Linkage Data The custom block expects flux linkage LUTs as functions of current and position angle - exactly what you have from Maxwell. You'll need to: * Replace the Motor-CAD flux linkage tables with your Maxwell data * Ensure your LUT format matches: lambda_abc = f(i_abc, theta_mech) * Verify the coordinate transformations align with your Maxwell model reference frame * Check units consistency (Wb-turns vs Wb, degrees vs radians)

3. Sign Conventions and Coordinate Systems Pay attention to the sign conventions in the custom block: * Positive torque typically indicates motor operation (counterclockwise when viewed from shaft end) * Current directions should be consistent with your Maxwell simulation setup * The mechanical angle reference should match between Maxwell and the Simscape implementation * Ensure phase sequence (ABC) matches your Maxwell model

Core Equations Remain Unchanged The fundamental equations in the custom block don't need modification because they represent physical relationships:

% Flux linkage from LUTs
lambda = f(i, theta)

% Electromagnetic torque
T_em = d(lambda)/d(theta) * i

% Voltage equation  
v = R*i + d(lambda)/dt

These equations are valid for both motor and generator modes - the sign of power flow determines the operating mode.

Recommended Implementation Approach

Phase 1: Direct Adaptation 1. Start with the existing custom block - don't modify the core equations initially 2. Replace the flux linkage data with your Maxwell LUTs 3. Change boundary conditions: Apply voltages instead of mechanical inputs 4. Run open-loop tests with simple voltage inputs

Phase 2: Validation Strategy To verify your motor operation is working correctly: * Compare no-load characteristics: Run the motor unloaded and compare speed vs. voltage relationship with Maxwell predictions * Validate torque production: Apply known load and verify steady-state torque matches Maxwell FEA results * Check flux linkage consistency: Monitor internal flux linkage values and compare with your Maxwell LUTs * Verify power balance: Ensure electrical input power = mechanical output power + losses

Phase 3: Control Integration Once validated, integrate with motor control: * The electrical terminals interface directly with voltage-source inverters * Current feedback is available for closed-loop control * Position/speed sensors connect to mechanical ports

Common Pitfalls to Avoid Data Format Issues * LUT extrapolation: Ensure your Maxwell LUTs cover the full operating range (current and angle) * Interpolation artifacts: Check for smooth transitions, especially near zero current * Saturation modeling: Verify high-current behavior matches Maxwell results

Simulation Setup * Initial conditions: Set realistic initial rotor position and flux linkage states * Solver selection: Use variable-step solvers for better accuracy during transients * Numerical conditioning: Watch for solver warnings related to flux linkage derivatives

Performance Considerations * Computational load: * Motor mode typically requires more iterations than generator mode due to voltage-driven operation * *Convergence: Start with lower bandwidth control to ensure stable operation

Dual Wye Configuration Specifics

Since you're working with dual three-phase windings: * Ensure your Maxwell flux linkage data accounts for both three-phase sets * The 30-degree phase shift between winding sets should be properly represented in your LUTs * Consider mutual coupling between the two three-phase systems if significant

Additional Recommendations

Control System Integration For typical motor drive applications, you'll want to: * Implement current controllers (PI or predictive) * Add flux-weakening capability for high-speed operation * Consider space vector modulation for the six-phase configuration

Model Validation Checklist

Before deploying in your main application: * No-load speed-voltage characteristic matches expectations * Torque-current relationship validated against Maxwell * Efficiency map reasonable compared to FEA predictions * Dynamic response (step torque/speed) behaves physically * Thermal behavior consistent (if included in model)

I recommend starting with the direct approach (changing boundary conditions only) and validate against a simple test case first. Begin with a basic R-L load to verify electrical behavior, then progress to mechanical loading.

The MathWorks development team designed this custom block architecture specifically to handle both operating modes seamlessly. Your Maxwell flux linkage data should integrate well with the existing framework.

Also, consider sharing your results with the motor drive community once you have a working implementation. Dual three-phase PMSM applications are growing, and your Maxwell-to-Simscape workflow could benefit other engineers facing similar challenges.

P.S. If you're planning to use this for real-time applications later, keep in mind the LUT size and interpolation requirements for code generation compatibility.

References

Import a Dual Three-Phase PMSM from Motor-CAD (Referenced example) 
https://www.mathworks.com/help/sps/ug/import-fem-motorcad-six_phase.html

[Ali]

Hello @Umar,

Thank you very mech for the detailed answer.

I have a couple of questions regarding the type of inputs and the core equations.

• When the block was configured as a generator, the input was a mechanical speed rotating the shaft and the outputs were the induced voltages. The equations inside the block were compatiable with that, which means the voltages are calculated using the inout torque, speed and fluxes from the LUT. The voltage equation were differential of flux.
• Inversly in the case of motor, I feed the voltages instead of computing them, and the block needs to calculate the output torque and speed. Shouldn't the equations be converted to the integral form?! Because I need to integrate the voltage over time in order to compute speed for example!

I know that the core equations stay the same, bit shouldn't we convert them form differential form to integral form?

Thank you in advance,

Ali

[Umar]

Hello @Ali,

Thank you for your follow-up question. This is an excellent observation that gets to the heart of how Simscape works. Let me clarify the fundamental principle that addresses your concern.

You do NOT need to convert the equations from differential to integral form.

Here's why:

Simscape Uses Acausal (Non-Causal) Modeling

Simscape uses a special approach called the "Physical Network" method, which is different from regular Simulink modeling. In this approach, each system is made up of elements that interact by exchanging energy through connection points that work in both directions. These connection points act like real physical connections - just like when you plug a motor into a power source, the connection doesn't care which direction the energy flows.

The key distinction is:

Causal Systems (Traditional Simulink):

• Works like: Input → Process → Output
• You must tell it: "This is the input, calculate the output"
• Equations must be rearranged to solve for outputs (e.g., speed = voltage / resistance)

Acausal Systems (Simscape):

• Physical connections work in both directions automatically
• Components that are connected share the same "across variables" (like voltage at a connection point)
• "Through variables" (like current flowing through the connection) are automatically distributed among connected components
• Equations describe relationships, not calculations
• The software figures out what to calculate based on what you've connected

How This Applies to Your Motor Block:

In electrical systems:

Across variable = Voltage (measured across two points) Through variable = Current (flows through a component)

When you write in the custom Simscape component: v = R*i + d(lambda)/dt

Where: * v = voltage * R = resistance * i = current * lambda = flux linkage * d/dt = rate of change over time

This equation is not saying "calculate voltage from current" or "calculate current from voltage." It's stating a constraint - a relationship that must always be true: voltage equals resistance times current plus the rate of change of flux linkage.

Generator Mode:

• You supply mechanical speed (shaft is being turned)
• Electrical terminals are connected to a load or left open
• Simscape solver thinks: "I know the speed → I can figure out how fast flux is changing → given the voltage equation and what's connected electrically, I'll solve for voltage and current"

Motor Mode:

• You supply voltage to the electrical terminals (power source connected)
• Mechanical load is connected to the shaft
• Simscape solver thinks: "I know the applied voltage → given the voltage equation and flux linkage tables, I'll solve simultaneously for current, flux linkage, torque, and resulting speed"

The Simscape Solver Handles the "Integration" Automatically

The variables associated with all energy flows form the mathematical model. The Physical Network approach with its bidirectional connections automatically figures out all the traditional problems with variables and which direction things flow.

When you apply voltage to the motor:

1. The solver sees the voltage you applied at the electrical connection 2. It simultaneously solves all the coupled equations:

Electrical equation: Applied voltage = Resistance × Current + Rate of change of flux linkage

Flux linkage: Flux linkage = your lookup table based on current and rotor angle

Torque equation: Torque = How flux linkage changes with angle × Current

Mechanical equation*: Torque = Moment of inertia × Angular acceleration + Damping × Speed + Load torque

Where: * Moment of inertia (J) = resistance to speed changes * Damping (B) = friction effects * Angular acceleration = how quickly speed is changing

The solver automatically integrates (sums up over time) or differentiates (finds rates of change) as needed to satisfy ALL relationships simultaneously.

Practical Implication:

You write the equations once in their natural physical form (usually showing how things change over time). The Simscape solver: * Automatically determines what needs to be calculated based on what you connected

• Performs necessary integration (summing over time) or differentiation (finding rates of change)

• Solves the complete system of equations all at once

Simple Analogy:

Think of it like a water pipe network: Causal approach: "I push water in here, tell me where it comes out" Acausal approach: "Here's how all the pipes connect. I'll figure out where water flows based on all the pressures and connections"

This is why the same block works as both motor and generator without changing the equations - Simscape automatically figures out the direction of energy flow based on what you've connected.

Hope this clarifies the fundamental principle behind Simscape's modeling approach!

[Ali]

Thank you @Umar for your great help. That has addressed my problem clearly.

Happy that Simscape language reached this mature nature.