MCAT:unable to measure motor parameters

cancel
Showing results for 
Search instead for 
Did you mean: 

MCAT:unable to measure motor parameters

1,151 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport
case:00162660

Problem:
We are trying to run a 1.2 kW 24 V BLCD motor with Freemaster and MCAT with sensorless FOC, but we are unable to measure the motor parameters. We keep getting "Wrong characteristic data" fault.

Background:
Our HW is based on NXP TWR58F220 CPU board and TWRMCLV3PH motor control board. The largest difference are bigger FET's on the power stage to allow motor currents of up to 100 A. Of course the phase current measurements have been scaled accordingly. We are using KV56 CPU, which is basically the same CPU as the KV58. The FET driver is MC33937, which it the same as in the development kit. The FETs are Infineon IPB020N08N5ATMA1.

We have been able to run the BLDC motor that comes with the TWRMCLV3PH (Linix 45ZWN24-40, 24 V, 40 W) with our own HW. We have also been able to tune and run a 180 W BLCD motor, but we can't tune or run the 1.2 kW BLDC.

Power stage characterization:
We've made the power stage calibration for our own HW with the 40 W Linix motor. It seems that it is not possible to the calibration with the 180 W motor, because it has much lower phase stator resistance than what the MCAT allows to use. Minimum allowed Rs for MCAT is 0.3 Ohm, but the 180 W motor has Rs of 0.084 Ohm according to the motor's datasheet.

After the calibration with the 40 W motor, we are able to run the motor measurement for the 180 W motor, and for example the Rs value is measured to be 0.07 Ohm, which seems to be close to the motor's specification. The measurement is done with "Is DC" set to 1.2 A and "Is AC" set to 0.6 A.
After the measurement, we are able run the motor.

If we try the same setup with the 1.2 kW motor, we get "Wrong characteristic data" fault. Manufacturer does not specify the Rs value for the 1.2 kW motor, but obviously it is much smaller than with the 180 W motor.

Questions:
1. Are we doing the power stage characterization correctly when using small motor instead of a larger one? Why does MCAT limit the Calib Rs value to minimum of 0.3 Ohm?

2. Why can't MCAT measure parameters for the large BLDC? Could it be caused by the very small Rs, that MCAT has trouble to measure? We have tried different Is current values without success.

We are not very familiar with these kinds of motors, so we are a bit lost with the big amount of parameters. We are happy to provide additional information if needed.
0 Kudos
14 Replies

454 Views
pavelsustek
NXP Employee
NXP Employee

Hello,

 

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:

  • Required voltage applied to the motor during measurement is very low
  • Error voltage picked from the characteristic is also low but a bit higher than the required voltage
  • The two voltages are subtracted Ureq – Uerror resulting in very low but negative Uphase voltage that is divided by Iphase. Rs is then negative which generates an error.

 

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.

 

OR

 

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.

Regards,

Pavel

0 Kudos

454 Views
ristomustonen
Contributor II

Hello,

 

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?

Regards,

Risto

0 Kudos

454 Views
pavelsustek
NXP Employee
NXP Employee

Hello Risto,

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.

Regards,

Pavel

0 Kudos

454 Views
ristomustonen
Contributor II

Hello,

 

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?

Best Regards,

Risto

0 Kudos

454 Views
pavelsustek
NXP Employee
NXP Employee

Hello Risto,

  • number of pole pairs = 4 ok
  • one-phase stator resistance - Rphase-to-phase / 2. Some manufacturers might specify directly Rphase in datasheet
  • inductance Ld & Lq - might be simplified to Ld=Lq for initial tuning. 
  • back EMF constant (Ke) - should be available in datasheet. You can use Kt and recalculate to rough Ke
  • rotor inertia (J) - it's required for speed PI controller constant calculation. But tuning of PI controller might be done manually reflecting required dynamic response of system
  • BEMF voltage threshold for blocked motor (E block) - yes, Nmax to rad/sec and then Emax = Ke * Nmax
  • Align voltage & Align duration - needs to be set manually according to drive inertia (motor + load). The bigger inertia, the higher Valign and longer Talign. Generally, after alignment, the rotor has be set properly to starting position without oscillations

If you want to use BLDC trapezoidal control instead, refer please to www.nxp.com/motorcontrol_bldc.

Regards,

Pavel

0 Kudos

454 Views
ristomustonen
Contributor II

Hello Pavel,

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?

BR,

Risto

0 Kudos

454 Views
pavelsustek
NXP Employee
NXP Employee

Hello Risto,

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.

BR,

Pavel  

0 Kudos

454 Views
ristomustonen
Contributor II

Hi Pavel,

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?

BR,

Risto

0 Kudos

454 Views
pavelsustek
NXP Employee
NXP Employee

Hi Risto,

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:

g_sM1Drive.sFocPMSM.sIqPiParams.bLimFlag 

g_sM1Drive.sFocPMSM.sIdPiParams.bLimFlag

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.

Regards,

Pavel

0 Kudos

454 Views
ristomustonen
Contributor II

Hi Pavel,

 

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?

BR,

Risto

0 Kudos

454 Views
pavelsustek
NXP Employee
NXP Employee

Hi Risto,

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.

Regards,

Pavel

0 Kudos

454 Views
ristomustonen
Contributor II

Hi, Pavel.

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.

BR,

Risto

0 Kudos

454 Views
pavelsustek
NXP Employee
NXP Employee

Hi Risto,

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.

Regards,

Pavel

0 Kudos

454 Views
ristomustonen
Contributor II

Hello Pavel,

Thanks for the answers. We'll keep on trying to figure out the suitable parameters.

BR,

Risto

0 Kudos