InstaSpin Motion with custom hardware stability problems

Jeff,

The issue with the torque value being wrong is due to a software bug introduced in the MOTION projects in MotorWare 12.  This bug only impacts the display of the torque value and does not impact the control.  

I think the issue you are having with Lab 12 is related to the alignment between the motor and encoder.  When you run lab 05b, what did the motor spin anti-clockwise (when seen from the shaft end)?  If not, you should switch two of the motor phase lines.

Next time you start Lab 12 follow this procedure:

1. Set gMotorVars.Flag_enableSys to 1, but do NOT set gMotorVars.Flag_Run_Identify to 1.  This will let us check the operation of the encoder.  
2. Add "st_obj.vel.conv.Pos_erev" & "st_obj.vel.conv.Pos_mrev" into the watch window.  These are both Q24 variables.
3. Manually rotate the motor anti-clockwise.  You should see the values in Pos_erev & Pos_mrev increase.  If these values decrease than you need to switch the A & B signals of your encoder.
4. When you have manually rotated the motor one rotation, the value in Pos_mrev should be equal to 1.0.  If it is not approximately 1.0, than you need to double check the value you put into USER_MOTOR_ENCODER_LINES.

The shaft end meaning the end you attach the load to?

I currently have.

When running 5b the motor runs clockwise when looking at the load end. The Pos-erev and Pos_mrev also increase to 1 when moved one revolution clockwise.

Does the direction still need to be reversed? I don't understand can you explain why?

Jeff,

If both the motor phase and encoder agree than we shouldn't need to reverse anything.  It is easier for us to specify in our procedure one direction that everything should align to.  So when I recommend to people that they go through that procedure I will specify a direction.

Your motor has 2 pole pairs, correct?  How many lines are on your encoder?  

I saw your changes for the FOC user.h file.  Can you attach the user.h file for motion?

Thanks that's what I thought about the direction.

Attached user.h from motion.4744.user.h

This will only effect sensorless FAST usage, but I don't think your parameters are correct. Your Rs / Ls is too small, it should be larger than your max speed even if that's just 50 or 60 Hz. 

It's also unusual that your Rr is the same as Rs. Usually Rr is lower. Did you ID these values?

Jeff,

The user.h file looks fine (aside from what Chris mentioned).  The Rs & Ls values are also important for the sensored labs when using induction motors.

To do sensored induction motor control we need to estimate the amount of slip in the motor.  Slip refers to the difference between the operating speed and the synchronous speed of the motor.  This is accomplished by SpinTAC Position Converter.  For lab 12 the Slip Compensation is setup in spintac_velocity.h (Line 258).

STPOSCONV_setupSlipCompensator(obj->posConvHandle, ST_SAMPLE_TIME, USER_IQ_FULL_SCALE_FREQ_Hz, USER_MOTOR_Rr, USER_MOTOR_Ls_d);

This component needs to know the motor Rs & Ls in order to get a good estimation of the motor slip.  The reason it will occasionally work is that at no load the slip is very small.  So it might be close enough to keep the motor spinning sometimes, but will break down at other times.  

I think making sure the motor parameters are right will resolve this issue.

The values I'm getting for RS and LS are pretty consistent and are being measured by the hardware itself. Can you define the difference that effects this measurement when the motor is wired for either Delta or Wye. We are trying to determine this with the motor manufacturer.

Delta and Wye don't matter to the algorithm.

If you can get nameplate data I recommend doing some of the calculations yourself to see if there is a gross error in the motor ID

http://e2e.ti.com/support/microcontrollers/c2000/f/902/p/318299/1107286.aspx#1107286

If so, you should walk through SPRUHJ1 section on identification and view your current waveforms to make sure stability is met, full flux is met, etc. during ID portion.

One note here regarding Rr.

Rr being inaccurate won't effect field orientation / torque, it will just effect the speed estimation accuracy.

It is your Ls and flux value that will effect field orientation / torque production and must be reviewed. Your Ls value should be smaller than you are identifying to give higher current and higher Rs / Ls.

The strange part is I can make lab5b turn the motor fine with some small tweaking to the pid controllers for speed. It turns the proper direction and the reported speed looks reasonably close with the Rs and Ls values I reported.

With Lab12 the motor is now always turning backwards while running away much faster than 100 rpm which is commanded. I have verified that the encoder is aligned as recommended above.

When started at 100 rpm the motor moves back and forth maybe 1/8 turn then runs away the wrong direction.

Other Ideas?

Jeff,

I really think that we are having issues related to the motor parameters.  When you run with Lab 05b are you able to produce the expected amount of torque if you load down the motor?

In lab 12 for induction machines we rely on the motor parameters in order to adjust the electrical angle of the machine to account for the motor slip.  If these motor parameters are wrong, we can't account for the slip and won't be able to produce torque or will produce torque in the wrong direction.

Hi Adam,Chris,

Here are some Later Measurements for Rs Ls which came from a locked rotor test. These measurements seem better. But now I'm waiting for a replacement IGBT because I lost one to high voltage.

#elif (USER_MOTOR == Marathon_ATC)

#define USER_MOTOR_TYPE MOTOR_Type_Induction)

#define USER_MOTOR_NUM_POLE_PAIRS (2)

#define USER_MOTOR_Rr (0.0212)

#define USER_MOTOR_Rs (0.0431)

#define USER_MOTOR_Ls_d (0.00023147

#define USER_MOTOR_Ls_q (0.00023147)

#define USER_MOTOR_RATED_FLUX (0.8165*460.0/60.0)

#define USER_MOTOR_MAGNETIZING_CURRENT (42.61)

#define USER_MOTOR_RES_EST_CURRENT (10.0)

#define USER_MOTOR_IND_EST_CURRENT (NULL)

#define USER_MOTOR_MAX_CURRENT (60.0)

#define USER_MOTOR_FLUX_EST_FREQ_Hz (5.0)

#define USER_MOTOR_ENCODER_LINES (512.0)

#define USER_MOTOR_MAX_SPEED_KRPM (1.725)

#define USER_SYSTEM_INERTIA (0.75)

#define USER_SYSTEM_FRICTION (0.75)

That looks much better. Proper R/L and Rr less than Rs.

Ok we have made definite progress. The motor is now much better controlled. We have some initial jerking when first starting up and I don't think the initial angle calibration is working. During RS calibration I assume that I should see the rotor move to align with electrical zero? This is a standard 4 Pole ACIM, how much movement would be normal during this procedure? I am applying 30 amps but that doesn't seem like its enough for zero angle? The motor is rated for 68 amps full run torque.

Jeff,

For ACIM we don't need to do an alignment step between the motor and the encoder.  Since we control the magnetic field in the rotor, we can choose that the initial position is zero.  After the initial jerking, is the motor able to control well?  Have you tried setting "gMotorVars.Flag_enableRsRecalc" to 0?

Ok Thanks that makes sense. Yes after initial start the motor seems to be well controlled and is producing expected torque. We are still using RsRecalc do you think that would effect the initial start? We have not done any high speed testing (been limited to 200-400 RPM)yet due to the possibility of high bus voltage blowing the Igbt's.

Jeff,

If you are using a lot of current in order to do the RsRecalc this could have an impact on the initial conditions of the slip calculation.  Typically you only need to use ~10% of the motor max current in order to do the resistance recalibration.