Startup and Generator-mode with Asynchronous Induction Motors

Maik Locksiepen said:

I have used the InstaspinFOC lab3b as a starting point for my project.

I would recommend choosing a different lab that has more functionality. Some things you need to decide:

• Do you want to use the forward control system from the library / ROM to save space in your user code? If so, you should start with 2a, 2c (if you need the special low inductance / low flux motor ID), or 2d (FPU). 
• If you aren't going to use the control from ROM, I would choose a lab that best matches your system functionality.
  • 5a: torque control only, access to update current control gains
  • 5b: adds simple speed loop, access to update speed control gains
  • These three build off of 5b, but add these components only (i.e. 10 doesn't include functionaliy of 7 or 9, but you can create a mixed project that does everything)
    • 7: RsOnline (important if you have low speed, high load applciations)
    • 9: Field Weakening
    • 10: Modulation over the defautl sinewave 1.0 (needed to reach higher speeds w/o field weakening)
• Please note that MW _12 introduced some SW functions for proper motor ID of induction motors.  These are ONLY in proj_lab2x, so if you want to ID induction motors in your product you should make sure this logic & function get included in your project.

Maik Locksiepen said:

1. Smooth motor start up:

I recommend using an RsRecalc at first start-up.
1. it's good to get a new Rs at first start-up
2. Doing an RsRecalc will align the D axis to allow a smoother start-up

Maik Locksiepen said:

So what I think I need here, is a way to set the ctrl into a passive state, in which it will measure and observe, but will not become active and try to force a speed/torque/position.

You can do this by disabling the PWM output. You can even keep the EST running which will allow you to more easily catch the rotor on next start-up if the rotor is already moving. Search the forum for "flying start"

Maik Locksiepen said:

Do you have any ideas what could be done in this situation?

I would try the RsRecald or Id injection first.  You should also command the motor speed/torque before releasing the brake

Maik Locksiepen said:

3. Generator mode

As you stated, this is speed loop tuning.  It may be challenging to solve with just a PI controller.  This is an application where I have seen the SpinTAC controller from our InstaSPIN-MOTION provide better capability. It really helps to know the intertia of the system and have a controller that better rejects disturbance.

Hello and thank you for the quick reply,

As you suggested I have made the switch to lab5b as the base for my project. Adjusting the piGains in this lab for up and down direction respectively seems to solve the speed-oscillation problem for most of our motors and weight distributions.

Labs 7,9,10:

I would like to look into the further labs based on 5b that you mentioned ( I am interested in the field weakening lab9 in particular) but there is no documentation on those labs in motorware (motorware/docs/labs). Only a short headline and summary for each one is included in the instaspin_labs.pdf. Are there any alternative sources for documentation on these labs?

PWM inversion:

On a different hardware that is currently being developed, I will need to control a driver module with inverted pwm inputs. This means I will need to invert the pwm output signals in motorware.
Is there a central point somewhere in hal for example, where I can do this? I am worried about some hidden dependencies in libraries.

Maik,

Maik Locksiepen said:

As you suggested I have made the switch to lab5b as the base for my project. Adjusting the piGains in this lab for up and down direction respectively seems to solve the speed-oscillation problem for most of our motors and weight distributions.

Excellent!

Maik Locksiepen said:

Labs 7,9,10

In latest MotorWare _12 (which you need to use) the instaspin_labs.pdf has an updated write-up for Lab 7.

Lab 9 and 10 needs to be documented in the next release....I've been pushing to get this complete.  They are quite straightforward.  The proj_lab##.c are correct, as are the .js files so they have the new variables you will need.

In lab 9 you have two options

1. enable auto field weakening gMotorVars.Flag_enableFieldWeakening
   1. have a gMotorVars.SpeedRef_krpm greater than you can reach w/o FW
   2. IdRef will be decreased up to user.h safety setting: USER_MAX_NEGATIVE_ID_REF_CURRENT_A
      1. you can decrease this limit to fit your motor
   3. Watch your speed PI controller, it likely will need to have Kp lowered (InstaSPIN-MOTION SpinTAC controller is very helpful for this topic)
2. manual field weakening

1. have a gMotorVars.SpeedRef_krpm greater than you can reach w/o FW
2. manually decrease gMotorVars.IdRef_A up to user.h safety limit of: USER_MAX_NEGATIVE_ID_REF_CURRENT_A
3. Watch your speed PI controller, it likely will need to have Kp lowered (InstaSPIN-MOTION SpinTAC controller is very helpful for this topic)

 In both cases, be very careful with weakening the field. There is NOT a limit built-in to check the actual current of the motor, and if you go over rated current for an extended time you WILL demagnetize your motor. I have done it myself with the small Anaheim/Telco motor!!

gMotorVars.Is_A = sqrt (Iq^2 + Id^2) and needs to stay < your maximum continuous current

lab 10

In lab 10 we show you how to go beyond the sinewave modulation that we define as a value of 1.0.  Anything above 1.0 moves the modulation into space vector and then eventually to full modulation (trapezoidal) with a value of 1.333

This setting can be updated with:

gMotorVars.OverModulation

When we are using modulations of <=1.0 the low side shunt on-time windows are typically always large enough to get valid current measurements on our U and V phases.  As you increase beyond 1.0 this is not the case and you need to start looking at all three U, V, W and choosing to ignore one or two and estimate the overall current.

svgencurrent.MinWidth  allows you to set the minimum sampling window of the low side shunt that you consider valid.  If the window for that current sampling event of that phase is lower, the value will be ignored.

svgencurrent.IgnoreShunt = tells you which of the 3 currents are being ignored

gMotorVars.Vs is a per unit representation of the voltage you are applying. So if your Modulation is at 1.0 and you are commanding full torque or speed, gMotorVars.Vs = 1.0

As you increase modulation, and have increased torque or speed commands, gMotorVars.Vs will increase up to gMotorVars.OverModulation

Maik Locksiepen said:

PWM inversion:

On a different hardware that is currently being developed, I will need to control a driver module with inverted pwm inputs. This means I will need to invert the pwm output signals in motorware.
Is there a central point somewhere in hal for example, where I can do this? I am worried about some hidden dependencies in libraries.

HAL_setupPwms

is how the Pwms are configured

Spending some time understanding hal.c and hal.c is worthwhile.  It's the GLUE that connects a solution project with a specific device / pin-out and inverter.  And it is where much of your customization will occur for your product.

I have done some testing with the field weakening feature (both automatic and manual), but the results were not what I was hoping for.

My motor does 1365rpm at its nominal frequency of 50Hz.
With no load (other than the gear) I can run this motor at around 3000rpm without any problems. My desired target speed under load would be around 2700rpm.

Now, as soon as I apply some load, the maximum speed goes down. This is expected of course, but what I do not understand here is, what the limiting factor is?

I have tried raising USER_MOTOR_MAX_CURRENT from 10.0 A to 18.0 A. This does not have any impact on the maximum speed. Is and Iq show a maximum of about 9.0 A at motor startup, then stay around 6.0 A during motor movement. Even though I raise the max current limit, no additional current is drawn.

Bus voltage stays stable at around 300V.

As my target frequency is above the nominal motor frequency, I was hoping that field weakening would solve this.
But if anything, this seems to even worsen it. After setting a IdRef_A of up to (-1.7), the EST measured speed still stalls at the same point under load. But on the other hand this increases the motor slip, so the effective speed measured by an external sensor is even lower.
Raising the IdRef_A any further will cause the motor to lose any power and the weight will drop down instead of being lifted (which I assume is the demagnitization you have warned about). So within the viable range of this setting, it does not seem to help.

My hardware would be able to provide much more power to the motor. It is specced for 35A continuous current, 90A peak. But there seems to be a limiting factor somewhere, which prevents this.

As the maximum speed is highly dependant on the load, I guess it may be torque related. Torque spikes to around 80.0 on motor startup (during force angle mode) then stays at around 50.0 during the rest of the motor movement, while speed stalls. More torque would be needed to reach the higher speed, so I was looking for some limitation on this value, but could not find any.

I am including my user.h.

7840.user.h

Maik Locksiepen said:

Now, as soon as I apply some load, the maximum speed goes down. This is expected of course, but what I do not understand here is, what the limiting factor is?

The limiting factor is your Torque production.  In field weakening for an induction motor you are reducing the magnetic field of the rotor, hence it is capable of producing less torque.  This is physics.

The best way to test the limits of field weakening for an induction motor is just to enable PowerWarp (there is a flag). When it is enabled the FAST Estimator will automatically adjust the Id magnetizing current to the minimum level to meet the the torque command.  Now, how it reacts to changing loads may not be as dynamic as you would like if you want to do your own field weakening, but it will show you the phsyical limits of speed/torque and where your Id needs to be to meet those speed/torque goals.

Maik Locksiepen said:

After setting a IdRef_A of up to (-1.7),

Stop there.  You can't set the IdRef to a negative number for an induction motor.  You have to INDUCE the magnetic field by injecting +IdRef.  This is the magnetizing current you identify to produce rated torque at rated speed.

To increase the torque production, you can increase IdRef from this value.

To decrease torque (and weaken the field), you can decreasee IdRef from this value (and PowerWarp will show you the bare minimum you can reduce to for a given load) but you can't go to 0 or below.  At that point you don't have an electric motor as you have no magnetic rotor!

Flux of 3.76 V/Hz, with a voltage of 618V you will saturate at 164 Hz = 4930 RPM