To be honest, I am a bit surprised that the measurement worked with a motor that has Rs = 0.084 Ohm. Primarily it was designed for industrial motors that has typical Rs > 1 Ohm, operate at higher voltages and lower currents. What happens during the Rs measurement and “Wrong characteristic data” is probably:
You can try to do the characterization for larger range (I calib) and then measure at higher I DC. However, keep in mind that during the characterization there is I calib applied to the motor for several seconds and the motor winding must withstand that.
Measure the parameters manually with RLC meter or some other method. You can refer to AN4680 for manual parameter measurement.
Both your questions can be answered that the Identification is not designed for such low Rs motors.
Thanks for the clarification. The situation is what we suspected. Would it be possible to develop MCAT further to support these kinds of motors as well?
About the manual method:
In the automated motor tuning procedure MCAT measures the motor values, and uses them to calculate all necessary parameters, and generates a header file. There are quite many different (floating point) parameters, and it is not easy to understand how they are produced.
If we can obtain the motor parameters manually, what would be the procedure to get the motor running? Where should we put the values in order to get a correct header file?
Can we use MCAT to calculate all parameters and to generate the header file, or should that also be done manually?
as far as I know auto team is working to improve MCAT identification routines for automotive motors with very low resistance. However, I'm not informed about the status and progress on this.
You can put manually measured motor parameters to MCAT parameter TAB and then click Save button. MCAT calculates required constant and parameters as it's done for automatic identification, where those params are copied to particular Parameters TAB field.
Correct values are finally generated in header file.
"Can we use MCAT to calculate all parameters and to generate the header file, or should that also be done manually"
Yes, you can. MCAT can work even offline without target connection but then output app config file is stored next to FreeMASTER .pmp project.
We're unable to make motor measurements manually, because we don't have all the required equipment. However, we got an extensive motor specification from the manufacturer, so we should be able to derive all necessary values there. However some of the values need a bit interpreting.
- number of pole pairs
The motor specification states that the number of poles is 8, so number of pole pairs should be 4?
- one-phase stator resistance (Rs)
There is a specified value for Terminal Resistance, which should be the resistance value measured between two phases. In this case the one-phase stator resistance would be half of the specified resistance value. However, the specification also has value for starting current.
By calculating resistance from the starting current and supply voltage, we get a value, that is double the specified Terminal Resistance. That would indicate that the Terminal Resistance is actually one-phase stator resistance. We need to check this from the manufacturer.
- d-axis inductance (Ld)
There is a specified value for Terminal Inductance, but we are not sure whether the terminal inductance is value for a single stator or combined value of two stators in series, or perhaps the total inductance for serial-parallel connection of the stator winding (as shown in AN4680). We need to check this from the manufacturer as well.
- q-axis inductance (Lq)
This should be possible to derive from terminal inductance similarly to Ld
- back EMF constant (Ke)
We have value for motor constant as N*cm/A. We've understood that with a BLDC motor Ke is equal to the motor constant value when units are converted to N*m/A, correct?
- rotor inertia (J)
The motor specification gives inertia as g*cm^2, but that can be easily converted to kg*m^2
- BEMF voltage threshold for blocked motor (E block)
AN5237 says this is typically 0.1*Emax and Emax = Ke*Nmax. Should Nmax be converted to rad/sec, before multiplying with Ke, so that the units will match?
- Align voltage & Align duration
Where can we get these values?
We are also considering of abandoning the FOC algorithm and using trapezoidal control instead, which should make the motor control a bit more straightforward. Do you have good software samples for sensorless or sensored trapezoidal control available?
If you want to use BLDC trapezoidal control instead, refer please to www.nxp.com/motorcontrol_bldc.
We just got an information from our motor manufacturer that the motor is in delta configuration. Does the MCAT FOC algorithm or sensorless trapezoidal control work with that kind of motor?
We have managed to drive the motor with current FOC, but we have difficulties to get it started at every time. Other control schemes seems (speedFOC, voltageFOC etc.) to not work at all.
We downloaded the demo application MCRSP_BLDC_V1.3.0 and tried to run it with following setup: TWR-KV58F-220M, TWR-MC-LV3PH and LINIX-45ZWN24-40. Jumper configuration has been checked to match the instructions. Motor tries to start then goes to freewheeling and stops periodically. Should the trapezoidal control work with this setup?
Both FOC and trapezoidal algorithms work with both delta or star motor connection. For FOC the transformation from 3-phase system to 2-phase rotational coordination eliminates different motor phase connection. Control loops are then calculated using direct values (d/q) as for DC motor.
If you are able to run the motor in current FOC, the speed FOC is just about speed PIC controller tuning.
Set speed ramp increment to lower values (up to 500rpm/sec), set integral component to value close to zero and try tune proportional gain.
The startup might require also some extended tuning while start-up current and merging speed are tuned.
I've tested MCRSP_BLDC_V1.3.0 for TWR-KV58F board. the application works correctly with default LINIX motor, but you need be sure both boards (TWR-KV58 and TWR-MC-LV3PH) have correct jumper setting.
Thanks for your answer.
We have managed to get 1.2 kW motor running at Current and Speed FOC algorithms by adjusting the appconfig.h parameters.
- align voltage and duration must be very small (0.1V, 0.01 sec)
- speed controller PI parameters must be adjusted properly
- open loop start-up parameters must be fixed also
There is still one thing we are wondering. We are trying to run our motor (pp=4) close to 4000 rpm. We adjusted the N max and N nom parameters near 4500 rpm and tried to run our motor about 4200 rpm. The fastest rate we can get is 3700 rpm. Do you have any tips what we should try to make motor run faster?
it nice to read you've been able to run the motor.
To not be able to run the motor faster might be caused by current controller saturation. In other words you don't have enough voltage available to run the motor faster and output voltage waveforms are limited.
You can try to increase "Output limit" variable in MCAT Current Loop tab from default 90% to max 95%.
It could help.
As other step you can check saturation flag of current PI controllers:
If you are on limit with voltage, to achieve the required speed 4200rpm there would have to be implemented Field weakening algorithm. This enable to increase speed over "nominal" motor speed while motor torque is decreased.
Such algorithm is available, but has not been implemented in MCRSP_PMSM_V1.2 yet.
Thanks for the tips. We managed to get the motor to run at the required speed. However, there is still something wrong with the driving.
We are getting random over-current faults from the gate driver while we drive the motor. The motor has only a gearbox as a load, nothing else. The DC-drive current is just a few amps. The over-current threshold is set quite
high: about 90 A. We haven't been able to determine what causes these errors. Another symptom is, that sometimes during normal drive with low load, one of the MOSFETs may suddenly break. It has usually been a low side FET but there have also been failed high side FETs as well. There are no visible marks on the MOSFET, but measurement shows short circuit between gate, source and drain.
Any ideas what could cause the breaking? We were suspecting a spike on the gate voltage, but scoping showed that the control voltage was clean. We are using a battery to power the electronics, so there is plenty of current available. We do have a fuse, but it is too slow to stop fast transients.
Otherwise the motor runs smoothly and with constant speed. Startup is sometimes a bit hesitant during open-loop drive period.
Another thing we'd like to verify is the motor Rs parameter. The high power motor has a very low Rs value. It occurred to us, that even though we are using thick cabling, the series resistance from the cables is little bit higher than the winding resistance. Should this be taken into account with the motor parameter calculations?
random over-current faults might be caused by spikes on Fault input signal. The eFlexPWM peripheral has input filter for fault signal however filtered signal is used only for fault interrupt invoking. Raw Fault signal connected to the PWM turn-off PWM signals always the fault level is detected. See AN4795 for more details. I would recommend to increase input RC filter on fault signal.
Regarding FETs it seems to be HW issue. Do you use a FET predriver module? One should not allow to generate spikes on gate voltages. It's quite difficult to analyze from my desk.
Cabling resistance should be taken into account when its value is significant comparing to motor Rs. In your case I would use the sum of motor Rs and cable resistance.
Thank's for your answer.
We are using NXP MC33937 as a pre-driver, and over-current monitoring is made with its internal opamp and comparator. The circuit is based on the design from TWR-MC-LV3PH. We can send you the hw design files for reviewing if you like, but not through this forum.
We tried to recalculate motor parameters with the cable resistance included. Unfortunately the result was another dead MOSFET. This leads us to believe, that there is something wrong with the current motor parameters, and that may cause the hw failures. Perhaps we should resort to sensored trapezoid control instead of “shooting in the dark”. We understand how trapezoidal control works, but do you know if there is any reference project close to our HW and maybe also with IAR build environment? Any example would reduce the time to implement the algorithm in our software.
The MC33937 is quite powerful pre-driver with lots of diagnostic. You can read status register on application background to check whether some fault are not caused. It could help to analyze the root cause of FET damaging.
Do you have correctly set PWM deadtime to be sure that FET are properly switched off before other is switch on.
There're not many possibilities how to damage FET when pre-driver is used. One should avoid hazard states using internal protection.
I would expect either issue with correct deadtime or MC33937 setting or some HW board issue.
For the trapezoidal control you can try to use BLDC package.