TMS320F28069M: Motor speed runaway with Instaspin

Is sensored based instaSPIN-motion? Or sensorless? Any current waveform for showing the issue you mentioned? What do you mean speed runaway?

Hi Yanming,

I contacted with the customer requesting some graphics and as soon as I receive them I'll share. When I say speed runaway I mean overspeed condition, when motor spins at its maximum speed (may not be the proper word after all).

I'll contact soon.

In the following picture you can see in the left that the reference speed of the vehicle is 0 but the real speed of the vehicle increases to its maximum value. In the right side of the picture you can see the normal behavior, with a vehicle reference 0 value and a vehicle real 0 value. To clarify, motor A and B are opposites, that is why always have same modulus but different sign.

Here is another picture with a non-zero reference value, and as you can see, the real and reference speed values are always the same, and the motor A and B always opposites.

I hope these graphics are clear enough to understand the problem. If there is anything else I can do, let me know.

EDIT: It is sensor based Instaspin MOTION.

It's better to have the current waveform captured by an oscilloscope.

1. Enable Rs recalculation and set the right USER_MOTOR_RES_EST_CURRENT value to ensure both the encoder and the motor are aligned on a zero degree electrical angle.

2. Make sure that motor parameters and ADC offset are correct.

3. Set the right acceleration. Don't use a high acceleration during start run the motor.

Hi Yanming,

Sorry for the delay, but customer is busy so they won't be able to send us images by the moment. Anyway, I take some pics of the current waveform in our installations. Here they are:

So as you can see after Rs recalculation, in this case the motor spins to the correct speed reference. However, we found that the RampUp time and ResEst current are not appliying correctly. These are the values we used in the pictures above:

• USER_EST_FREQ_Hz = 15000
• IndEstCurrent = 30
• RampUpWaitTime = 2 * USER_EST_FREQ_Hz
• FineWaitTime = 5 * USER_EST_FREQ_Hz

We have seen that changing FineWaitTime works correctly, but changing RampUpWaitTime has no effect. Changing IndEstCurrent has some effects on the maximum current value, but doesn't match with the assigned value.

We are 100% sure that the problem occur during the encoder alingment process, but we don't see anything wrong. May you provide us some guidance on how to face this problem? 

EDIT

We got some pics with the problem. All the variables have the same value excepting FineWaitTime, which has the original value (we have checked that this has no effect on system operation). 

As you can see, as soon as the Rs recalculation ends the motor spins at its maximum speed until we take some action. Hope this help.

BTW, can we somehow check if the alignment process is correctly done? We think that could be very useful to solve this problem.

As mentioned above, please try the following steps.

1. Enable Rs recalculation and set the right USER_MOTOR_RES_EST_CURRENT value to ensure both the encoder and the motor are aligned on a zero degree electrical angle.

2. Make sure that motor parameters and ADC offset are correct.

3. Set the right acceleration. Don't use a high acceleration during start run the motor.

I don't know what do you mean. As you can see, Rs recalculation is enabled and the parameters you mention are the correct ones according to the TI documentation and labs.

I can't provide pics with final configuration because the problem happens very occasionaly in customer installations, but we have not been able to replicate it in our installations.

Again, we think that parameters and software implementation is fine, but the problem may probably be in the zero alignment. We came to this conclusion after experimentation and everything point to it.

Our priority at this moment is to check somehow if the alignment is correctly done, is there any way? Any advise?

And why the Rs recalculation times (specifically RampUp time) are not applying correctly?

You can try run the motor without load first to see if there is the same issue. And to check if the issue is only appeared at running the motor with heavy load. If yes, that means the rotor is not aligned to the zero position for encoder offset calibration.

You should set an enough FineWaitTime for implementing the Rs recalculation to make sure that the rotor is forced to zero position.

Thanks for your reply Yanming. Unfortunately, the load can't be detached from the motor as they both are integrated. Here in our installations we can experiment without load, but we have not been able to replicate the problem with the same config they are using. 

With respect to Fine time, at this moment we have set 1.25 seconds. We can increment this value (as well as customer can) but we prefer not to increment this value too much. Would, for example, a 3 seconds fine time be enough? Should it be greater?

EDIT

We are trying to verify the correct alignment of the motor. At this moment we are injecting current through the U phase, and the next step is to inject current though the V phase to check the encoder counts. In this way, we can ensure that the motor is correctly aligned if the number of counts is the correct one. How can we change the phase at which the current is injected?

Using a light load could be ok for checking if the rotor is forced to zero position.

The default time is 7 seconds for fine time, 2 seconds for coarse time. You might try to set the fine time to 5s.

It's better to inject a positive current to d-axis, and force the rotor angle to zero for alignment.

Apparently we solve the problem doing 2 alignments in a row. This way, by the moment at least, we are able to confirm that the encoder counts are the correct ones comparing the results of the 2 alignments. Also increased the fine time, at this moment to 3s, we will be experimenting a few days with this value, algo with the 5s you proposed, and then I will update information about the problem, ie if it has been corrected in all situations, if there is any configuration better than another etc.

Regards

Hi Yanming,

I have 3 questions related to the Rs recalculation process. I'm attaching a current waveform obtained with the current test parameters.

1. Why Rs RampUp time is still not in concordance with the value we set in user.c? Other times are applying correctly.
2. Have you some idea why this spike occurs? It happens often, sometimes it is almost unnoticeable, but generally is as huge as this pic shows.
3. The current level on the second Rs recalculation is extremely small compared to the first one (USER_MOTOR_RES_EST_CURRENT is set to 10A, so first recal is applying more than assigned, and the second less than assigned).

Regards

Asier Lamariano said:

Why Rs RampUp time is still not in concordance with the value we set in user.c? Other times are applying correctly.

It also depends on the current ramp rate, you might ignore this, and just make sure that the fine time is correct that is import to force the rotor to the zero position.

Asier Lamariano said:

Have you some idea why this spike occurs? It happens often, sometimes it is almost unnoticeable, but generally is as huge as this pic shows.

It seems like the reference torque current is too large. You might reset or configure the integral variable of both speed and current PI to a appropriate value.

Asier Lamariano said:

The current level on the second Rs recalculation is extremely small compared to the first one (USER_MOTOR_RES_EST_CURRENT is set to 10A, so first recal is applying more than assigned, and the second less than assigned).

Phase 2 and 3 are not for Rs recalculation. Do you enable force angle?