TMS320F280041C: Sensorless PMSM not reaching speed with Instaspin-FOC and FAST

Are you using the TI EVM kit or your own board? Did you try to run the lab05 to identify the motor parameters and use the identified parameters for running the lan07?

Thanks for your reply.

Yes, we've run the motor ID code and used those parameters and we are using our own board. Upon further testing we see that is07 does seem to perform an alignment at initialization to a known zero rotor position we've marked. Besides not being able to reach speed, we've noticed that at low speeds the motor oscillates in speed and doesn't quite settle. We think both cases indicate that the angle output of the FAST algorithm is not correct. Could it be that at higher speeds, the angle phase "slips" and needs to be corrected by adding some phase table vs speed? Or are some of the parameters fed into the FAST not correct? In the past, with other algorithms, we've determined that the motor inductance value has a big effect on the estimated angle.

Force angle (open loop control) is used for the startup and low speed, so there could be a little bit of oscillating during startup at the first rotation., especially the motor with a heavy load.

Did you use lab03 and lab04 to verify the current and voltage sensing since you are working on your own board? And could you please post some current waveforms to show the issue that could help us to understand your questions? If possible, do you have a chance to run the motor with TI EVM kits and see what happens?

You don't need to add any angle compensation according to the speed, the FAST estimator has had this function already. You just need to make sure that the hardware board is good enough for motor drive and set the correct parameters in user.h based on the hardware and motor.

We have used an EVM kit but on a different motor. Below is graph of Id_ref ( Idq_ref_A.value[0] ), and estimated angle. This is a PM motor, so seems strange that Id_ref isn't zero, but a -6A - +4A sine.  As far as I know, it's not running Rs online recalibration or field weakening.

In the graph, the motor is commanded to increase speed from 75 Hz to 200 Hz, then it stalls close to 200 Hz. Max motor speed is 370 Hz.

Do you mean the motor speed is electrical frequency set by the variable " motorVars.speedRef_Hz"?

Can you check the "userParams.maxVsMag_V" and "motorVars.Vs_V" in the expression watch window? To see if the value of both variables is very close.  If yes, please increase the dc bus voltage of the inverter to see what happens.

Hi. Yes the electrical frequency in Hz. It's an 8 pole motor, 2900 RPM - so Max speed around 390 Hz. Using lab07 motor starts up about half the time, when it does, current at 75 Hz is about 2 A. When increasing speed to 200 Hz, current increases to 20A until there is a motor sudden stall. We are applying 48V and it's a 48V motor so it should achieve velocity higher than 200 Hz. When we use lab04 and Iq = 18A the motor spins no problem past 300 Hz. This is probably because we are applying a large current.

For the speed closed loop lab07, is there an initial rotor alignment built in? We think the big increase in current at higher speeds is due to the estimated angle misalignment getting worse at higher speeds.

Did you try to identify and run the motor using the TI EVM kit, and have a comparison with the test result on your own board?

And did you have any waveforms of the motor phase current captured by the oscilloscope with a current probe?

We haven't tried the motor ID using a TI EVM kit, just our custom board. Could this potentially change some motor parameters? Is the correct sequence to perform the motor ID on a TI EVM kit and then copy the parameters to the user.h file when using a custom board?

Below are startup currents for the 3 phases running  lab07 with forced angle enabled, run 3 different times as we only have one current probe. From this we can see that there is no initial rotor lock or alignment, and when we try to enable it as described in an earlier post, the motor buzzes and current just oscillates, increasing in magnitude until it trips. Is there another way to implement a rotor alignment without using the offline Rs Recalibration enable or is there something in the lab07 code that doesn't allow this method of rotor alignment?

Below are CC graphs of the FAST estimated angle and the 3 current phases taken with the motor spinning at 75 Hz (about 560 RPM) running lab07. When the speed is increased to 200 Hz (1500 RPM), the currents increase 10x and the motor stalls.

The latest user.h file attached0841.user.h

Do you have any chance to identify and run the motor on the TI EVM kit? It seems like current waveforms are not good. Can you run the motor at a low speed and capture the waveforms as above?

InstaSPIN-FOC doesn't use the rotor lock and initial position detect for a startup, just use the force angle.

We will set up the motor with our EVM kit and let you know results.  We understand there is no initial position detect, but are surprised to learn that there is no rotor lock for sensorless applications. In the InstaSPIN-FOC User's Guide SPRUHJ1H in Chapter 14 they mention ways of managing full load at startup, and the technique described is to do a rotor alignment (we used to call it rotor lock, but same thing) at startup by applying a DC current. Following this technique has not worked for us using different lock currents and delays. Is there an error in the manual? With InstaSPIN-FOC there is no different way of starting up a motor under full load?

As mentioned previously, using the Rs recalibration to force the motor to an initial position hasn't worked using the function in the InstaSPIN user guide. The current rises exponentially. We have applied a DC current on the q-axis for 3 seconds while setting the rotor to zero angle as you described, but we don't seem to see the q axis current command change to the DC value commanded for the time commanded. Could you provide the function that we could  use to implement this?

Set a torque current value to Idq_offset_A.value[1] directly.