It appears that there is an issue caused by the interaction between the variable inductor used in the VBR implementation and the SPICE solver. This has been identified as a bug and will be addressed in a future PLECS release.
As a workaround, in PLECS 5.0.4 you can still simulate your SPICE components together with the PMSM by using the Rotor Reference Frame (RRF) machine model instead of the VBR implementation.
Let us know if this workaround satisfies your current requirements.
I believe there are a number of issues in your model that should be addressed before worrying about the VBR versus RRF machine model implementations.
The model is quite complicated to follow, which makes debugging challenging. Here are a few quality-of-life improvements I would recommend:
Use Model References
This is a very useful strategy when you have repeated devices or repeated configurations of devices. It allows you to modify a single component and automatically propagate those changes to all referenced instances.
Reduce reliance on Electrical Labels and Global Signal Labels
While convenient, extensive use of labels can make a circuit difficult to follow. Consider updating your MOSFET and IGBT subsystems to expose:
Electrical ports for D/S (or C/E)
A signal port for the gate-drive logic
This will make the power stage topology much easier to understand and debug.
One of the biggest advantages of SPICE support in PLECS is the ability to switch between a pure PLECS simulation and a SPICE simulation if the model is structured appropriately.
If you look at the SPICE demo models included with PLECS, you’ll notice that many devices have two implementations:
A native PLECS component
A SPICE-based component
The intended workflow is typically:
Use the native PLECS components for the majority of development.
Verify the control strategy.
Validate system behavior.
Iterate quickly using fast simulation times.
Once the system is functioning correctly, switch to the SPICE implementation to investigate device-level effects such as:
Vds overshoot
Gate resistor tuning
Switching transients
Device stress
In my opinion, this workflow allows you to take full advantage of PLECS without sacrificing SPICE-level fidelity where it is actually needed.
Another strategy I highly recommend when working with SPICE models is to validate each component in isolation before integrating it into a larger system.
For example, I would follow a progression similar to this:
Validate the MOSFET model
Connect it across a DC source and resistor (e.g., 800 V and 1 Ω).
Drive it using a pulse generator.
Verify the expected switching behavior and current levels.
Validate the IGBT model
Repeat the same process.
Validate the MOSFET + IGBT combination
Since your goal is to operate them in parallel with slight timing differences, verify that arrangement independently first.
Validate a single inverter leg
Confirm correct switching behavior.
Validate the inverter leg with an inductive load
For example, a synchronous buck converter configuration.
Validate a full three-phase inverter
Use a simple RL load.
Operate open-loop.
Confirm expected phase voltages and currents.
Only after all of these steps are working would I move on to closed-loop machine control with SPICE models. This approach gives you the highest probability of success when developing complex SPICE-based simulations.
As for the current model, I believe there are several issues:
The controller does not appear to be stable.
The IGBT branch appears to be conducting approximately 25 kA regardless of gate-drive status.
I believe the antiparallel diode is connected incorrectly, effectively creating a permanent short-circuit path across the DC bus.
A SPICE ground reference appears to be missing.
SPICE simulations require a well-defined 0 V reference node. Currently, the IGBT component seems to be providing this reference indirectly, but neither the MOSFET nor the DC source appears to have a clear connection to the SPICE ground node.
My suspicion is that the solver is finding a high-impedance path back to the reference node, which is allowing the simulation to converge, but this is likely not the intended circuit configuration.