Flux Automatic Parameter Measurement

[derekcook]

Hello, 

I have 2 projects, one sensored and one sensorless. I am using the same hardware and motor for both of these. In the sensorless project, I can use the default 14.99% for the flux motor parameter identification, and the rotation is very smooth. This is not the case for the sensored project. In this project, once I start the motor identification at 14.99%, I get an overspeed fault because the motor takes off very fast. Not at all like the sensorless project. 

In the sensored project it works just fine if I put the calculations for resistance, inductance and flux from the motor datasheet in. I can run position control and speed control just fine, and have been for around a month now. I am unsure why the automatic parameter flux measurement does not work? The inertia measurement works fine, and it will work if I set the parameter for flux identification to less than 5%, but it still does not spin smoothly, it makes a couple of quick jolts, and I do not trust this measurement. 

Have you seen this before, or know what would cause this?

[linestream-adam]

derekcook wrote:

In the sensored project it works just fine if I put the calculations for resistance, inductance and flux from the motor datasheet in. I can run position control and speed control just fine, and have been for around a month now. I am unsure why the automatic parameter flux measurement does not work? The inertia measurement works fine, and it will work if I set the parameter for flux identification to less than 5%, but it still does not spin smoothly, it makes a couple of quick jolts, and I do not trust this measurement. 

Is your motor bare shaft when you are performing the motor parameter identification with the sensored project? As part of this identification the speed loop is utilized to spin the motor at the goal speed. And the speed loop is tuned to be not very stiff. I've seen issues when the motor is not bare shaft during this process. 

Also when performing the flux identification using sensored control, the encoder must be aligned. Since you made changes to support the resolver, there could be something unexpected going on with this process.

derekcook wrote:

The measurement should be 0.895 Wb per my datasheet, but the calculation the KMS autotuning is giving me is 0.170 Wb. 

What settings should I be looking at that may cause an incorrect flux calculation or a flux test to give me an overspeed fault?

Flux units can be very tricky things. Can you post your datasheet? I can probably help with confirming the units. Of the three motor parameters, flux is the least important. It is used to help with a correction factor for the estimator and to determine if the motor is spinning. It isn't directly leveraged for control purposes.

derekcook wrote:

When I put in the flux number from the datasheet in the sensorless project, 0.895 Wb I get a motor startup failure, whereas when I use the calculated number from the GUI 0.170 Wb, the motor runs fine. Is something different with the flux calculations between the sensored and sensorless project?

This isn't surprising given the difference between the datasheet flux and the identified flux. The startup algorithm uses the measured flux compared against the rated flux in order to determine if the motor is spinning. If the measured flux isn't at least 50% of the rated flux, it determines that the motor isn't spinning and will throw a startup fault. In the sensored project, this fault isn't part of the startup process as you don't need a startup with the sensored project. 

[derekcook]

Hey Adam, 

Thanks for the reply. My motor is bareshaft during the motor parameter identification. If the USER_ALIGN state is entered, all that will happen is the next state will get set to USER_IDLE. Actually,  User encoderAligned variable is initialized and reset to true in my project, so the USER_ALIGN state should never be entered? All of the DC Injection in USER_ALIGN has been removed. I could try restoring this while doing parameter measurement - currently it is commented out. 

Thanks for the description of how the flux is used in the startup block and why I am getting the startup failure with the datasheet number. That makes since. 

The datasheet is posted below - A flux is not given in Webers, but we were able to use the V / 1000RPM to calculate 0.895 Webers. 

Data Sheet  Drivetrain
Typ: 7606408-4000
Rating:
Stall Torque	[Nm]	58
Current at Stall Torque	[A]	41.5
Ambient Temperature	[℃]	50
Enclosure		IP 65
Insulation Class		155° (F)
Nominal Rating:
Rated Power	[kW]	8.3
Rated Torque	[Nm]	52.5
Rated Current	[A]	37.5
Rated Speed	[rpm]	1500
Rated Frequency	[Hz]	100.0
Voltage Constant (at Tamb.)	[V/1000rpm]	91.6
Winding Resistance(ph.-ph., 20°C)	[ohm]	0.111
Winding Inductance	[mH]	1.62
Number of Poles	[p]	8
Max.Values:
Max.Torque	[Nm]	260
Max. Current	[A]	166
Max. Speed	[rpm]	1800
Measurement System:
Encoder		Resolver
Sensor		KTY84
Brake:
Holding Torque	[Nm]	100
Rated Voltage	[V DC]	24
Rated Current	[A]	2.7
Brake Release Time t11	[ms]	180
Brake Engagement Time t2	[ms]	35

[linestream-adam]

Provided that your motor and encoder are aligned somehow, the USER_ALIGN state isn't important.  Are you still resetting the ENC module in DRV_updateAtFastTick when DRV_isDCInjectionEnabled returns true? If so that could be causing some weird behavior since the encoder alignment has been removed. Something to look at.

When I calculate the flux I get: 0.219 Wb

91.6 V/1krpm * (60s/m) * (1k/1000) * (rev/2pi rad) * (1/4pp)

Which is pretty close to the KMS estimated value.

[derekcook]

Hey Adam, 

Why did you divide by 4? Because there are 4 pole pairs?

[linestream-adam]

Yes, flux should be based on electrical revolutions, not mechanical. So you need to do the mechanical to electrical conversion.

[derekcook]

Hey Adam, 

I've tried the flux parameter measurement with and without the Encoder Reset Present  in DRV_updateAtFastTick when DRV_isDCInjectionEnabled returns true. I've also combined the encoder reset with a resolver reset in which I set the resolver output angle to 0, similar to QEI, and the keep track of the offset that results during the process since the resolver returns an absolute position. Still the flux parameter measure just spins until an overspeed is reached. 

I've also tried just removing every in DRV_updateAtFastTick when DRV_isDCInjectionEnabled returns true and the same overspeed event occured. I've also tried removing everything but setting tempAngle to 0 and still the same event occurred. 

I plan on just using the datasheet parameters, but it would be nice to figure out what's going on here. 

This is currently what I have occurring when DCInjectionEnabled returns true: 

if(DRV_isDCInjectionEnabled(&user))
{
tempAngle = 0;

resolver.output.rotorAngle = 0;
Resolver_Reset(&resolver);

ENC_reset(&enc);
}

Resolver_Reset() actually does not contain any code. I just had it there in case I wanted to add code to it. 

Thanks, 

Derek

[linestream-adam]

In the sensored control modes, the flux is only used for the synchronization fault and the torque estimate. It doesn't impact the control of the motor.

If this fault and the torque estimate aren't helpful in your application feel free to remove it and you won't need the value at all (you can disable rotation during the parameter estimation process to avoid it in the future).

When the flux id is performed on sensored system, it relies on all of the underlying control loops being functional. So the speed (or position) loop must be functional. My best guess is that the DC injection angle manipulation (or control loop resetting) is causing issues when it goes to spin in the flux identification.

[derekcook]

Thank you Adam, for now I am planning on removing it, but I will circle around and look back at the DC Injection later. 

Thanks for the help!

[derekcook]

Sorry, 

Don't mean to keep replying to my own question, but just adding another datapoint I got while testing that I thought may help.

When I put in the flux number from the datasheet in the sensorless project, 0.895 Wb I get a motor startup failure, whereas when I use the calculated number from the GUI 0.170 Wb, the motor runs fine. Is something different with the flux calculations between the sensored and sensorless project?

[derekcook]

To add to this my flux measurement for the sensorless project is off. The measurement should be 0.895 Wb per my datasheet, but the calculation the KMS autotuning is giving me is 0.170 Wb. 

What settings should I be looking at that may cause an incorrect flux calculation or a flux test to give me an overspeed fault?