Profiling with EVLGANSPIN2-3PH

[BlachaL]

I purchased the EVLGANSPIN2-3PH evaluation module. I added a definition for this module in the MCSDK. I connected a BLDC motor from a well-known drill operating at a nominal voltage of 230VAC to it. I measured the resistance and inductance of the windings, as well as the number of poles. The code was generated in MCSDK v. 6.4.2 in FOC mode with the profiling option – it can only be generated in STO-PLL mode, so the HALL sensors are not used. The PWM frequency is 10 kHz, and the overcurrent control option is enabled.
I started all tests at 70 VDC with a limit of 800 mA.
After starting the profiler, the motor hums quietly for a moment, and profiling freezes at about 30%. I can't get the profiler to work properly.
I started the MotorPilot, and the motor only squealed. Current consumption is about 250 mA.

Redesigning the project to STO-Cordic mode allowed the motor to start in MotorPilot. It starts slowly but smoothly and gains speed. The current draw also increases until it reaches the power supply's current limit. I increased this limit to 3A and started the motor. The current increased until it reached the limit, after which a crash occurred and two of the three GANSPIN612 chips were damaged.
I intend to repair the module and continue developing the project.
Please advise me on how to run the Profiler program and how to prevent further damage.

 

[GMA]

Hello ​@BlachaL,

Refer to the Known problems chapter of the Motor Profiler application note in the user manual, available from Workbench tool > About > Documentations > Documentation.

Set the MC Profiler maximum current parameter to a value lower than the maximum current of the motor or board.
Limit the current in the DC supply.

[BlachaL]

I doubt this is the overcurrent problem, as the power supply current limit was set to 800 mA during profiling. The motor only hums, buzzes, or stays silent to the point of timeout. He didn't rotate. There were no signs of overcurrent during profiling. Current sensing options were set to default settings for this evalboard.

The overcurrent occurred when I tried to recompile the project as STO-Cordic and run it in speed mode in MotorPilot. In fact, the start and acceleration were very smooth – until the overcurrent occurred.

 

[Jason Miller234]

It sounds like a configuration or current-feedback issue rather than the profiler itself. verify the motor parameters, current sensing, and phase wiring before testing again. Also, use an oscilloscope to check phase currents during startup to avoid damaging more GaN devices.

[BlachaL]

I replaced all the GANSPIN612 ICs with brand new GANSPIN611 ICs (the stronger ones). I started a new project in MCSDK and generated code for the profiler. The profiler started with some issues – it ran at low voltage and/or low current – ​​due to detected overcurrent signals.

Profiling was completed at 70 V/3 A and 320 V/0.5 A. With these parameters, the motor started running. Now the problems occur when the motor is running at full speed and I start applying torque. The BREAK signal from the GANSPIN's FLT output appears again. If I set the RPM to a low value, I can load the motor even to a stop without any overload indication. Increasing the PWM frequency from 10 kHz to 20 kHz helped a bit. The motor needs to operate throughout the entire RPM and load range, so I replaced the 33 mOhm sensing resistors with 20 mOhms – this also improved a bit, but didn't completely solve the problem. The oscilloscope shows no current spikes that could trigger the overcurrent protection – the current through the measuring resistors does not exceed 3A.

I'm wondering what to do next.

[GMA]

Hello ​@BlachaL,

The FLT/BREAK signal is triggered not only by overcurrent detection. Refer to the GANSPIN612 datasheet.

[BlachaL]

Thanks for reply.

I am aware of this. FLT can be triggered by overcurrent, overheating or VCC undervoltage. The thermal camera shows over 50 Celsius degrees across the three shunt resistors and on inrush NTC thermistor. That’s it. GANSPIN’s thermal condition looks fine. I didn’t check VCC stability because there are dedicated Viper06 module on this evalboard. This should be sufficent under all condition, but i'll check it today  on oscilloscope for peace of mind.