LAUNCHXL-F28027: Motorwar lab code gets into "limbo" stage

Thansk!

Yes, but...

the system does not recover from this state ever. 

It is not acceptable to prevent this situation by tuning the parameters, suppose some one just give the motor a sudden 'push' by hand and the system enters this state.

At the very least I need to be able to detect this state in software and then do full reset but I would like to know what it is that actually 'bugles' in this situation.

wbr Kusti

The better way is to tune the controllers if you make sure that the motor parameters have been identified correctly by using lab02b/c and the hardware board worked well. And please check if the adding load is over the rated output power of the motor and the running speed is greater than the rated speed of the motor. Please post some testing waveforms and user.h to help us your questions if possible.

Sorry I missed you reply. 

This phenomenon happens at rather low speeds, and it happens every time I decelerate the speed too fast. 

Going down in speed 

.MaxAccel_krpmps = _IQ(3.0)

is the max I can do without this mode kicking in, accelerating no problem, I'm using

gMotorVars.MaxAccel_krpmps = _IQ(36.0);

Here is the user.h parameters

#define USER_MOTOR_TYPE                 MOTOR_Type_Pm

#define USER_MOTOR_NUM_POLE_PAIRS       (4)

#define USER_MOTOR_Rr                   (NULL)

#define USER_MOTOR_Rs                   (0.171)

#define USER_MOTOR_Ls_d                 (0.0000934)

#define USER_MOTOR_Ls_q                 (0.0000934)

#define USER_MOTOR_RATED_FLUX           (0.0132)

#define USER_MOTOR_MAGNETIZING_CURRENT  (NULL)

#define USER_MOTOR_RES_EST_CURRENT      (1.0)

#define USER_MOTOR_IND_EST_CURRENT      (-1.0)

#define USER_MOTOR_MAX_CURRENT          (10.0)

#define USER_MOTOR_FLUX_EST_FREQ_Hz     (20.0)

#define USER_MOTOR_FREQ_LOW             (10.0)          // Hz - suggested to set to 10% of rated motor frequency

#define USER_MOTOR_FREQ_HIGH            (100.0)         // Hz - suggested to set to 100% of rated motor frequency

#define USER_MOTOR_FREQ_MAX             (120.0)         // Hz - suggested to set to 120% of rated motor frequency

#define USER_MOTOR_VOLT_MIN             (3.0)           // Volt - suggested to set to 15% of rated motor voltage

#define USER_MOTOR_VOLT_MAX             (18.0)          // Volt - suggested to set to 100% of rated motor voltage

I will try to attach a video or sound so you can hear the problem.

My main concern is that I do not know what the problem is.

Is this hardware, for example when the motor spools down and generates voltage, is that causing the issue. Then we will need to add some hardware to handle that energy.

Or is this some sort of windup problem in sw, so far I've not seen any of the PIs behaving strangely.

What I observe in this mode is that the speed feedback seems to make sense and the speed PI tracks at the low rpm but in this mode I can only get to about 25% speed ref after which the speed feedback nor the actual motor no longer tracks the ref and the PI output shoots to max.

wbr Kusti

Here is a short movie where I first adjust the motor speed slowly and then at around 25 sec mark I suddenly command the speed down to about 1krmp and the system goes into limbo and starts whining. The system still accepts input and complies but only upto about 1/4th of the range it should.

Hi,

thanks for the answer, but I don't think that is the problem nor the solution.

We added circuitry that absorbs the generated energy when we decelerating i.e. basically an over voltage clamp to power supply and the problem went away. 

So that is the solution as we are going to need that anyway because of the need for fast deceleration.

Nothing to do with  tuning the parameters.

However the question remains what is this 'limbo' stage from which the system does not recover except by re-booting?

I doubt this is software because everything seems to keep working and everything I see with the debugger looks normal.

wbr Kusti

Sorry, we can't open the Yes, the motor will be working as a generator and boost the dc-bus if the deceleration is too high and the inertia of the motor is large. What do you mean 'limbo' stage? Do you have any detailed description of it? Could you please monitor the dc-bus voltage, and capture some current and waveforms that should help us to understand the problem? And please check if the MCU is halted without any output due to the power supply.

Hi thanks for the answer. Pitty you can't open the .mov file, it is standard file from iPhone. 

Anyways, as I explained above, the problems starts when the motor functions as generator and if we do not have over voltage protection on the supply line we get the limbo condition. 

In the limbo, the switching noise from the motor has some extra audible components very different from normal op and the motorware software only complies to speed ref commands upto about 1/4 of the normal range., 

As we will have the overvoltage protection in the final product this should no be an issued but would still like to understand what happens in this situation. Can the MU be partially reset so that some initialisation of the PMW or ADC or something is wrong or something...

You might try different acceleration for startup and running, use a lower acceleration for a startup, and then set the required acceleration for the running after the speed of the motor up to a setting value.

And you should use different control gains of the speed and current regulators (PI/PID) for low and high speed, and acceleration.

Set the minimum output of the speed (PI) regulator to "0" if you just need a unidirectional rotation.

No, the ADC and PWM shouldn't go into the wrong state. The current/voltage sensing will be not good enough for control if the noise on the board is too high, that will cause the motor loss control.

Do you have a chance to check the feedback current and voltage, and make sure that the power supplies of the MCU and inverter are clear under this testing state?

Hi,

thanks for the answer and continuous support.

However we seem to go round in circles. The video I posted if you had been able to watch it would have shown the problem.

This is not a matter of tuning or anything like that. It cannot be and it must no be that if the controller is badly tuned then the system never recovers from this. I mean never, if I stop the motor and start over the system is still not working properly as I try to explain. If it was a tuning problem surely stopping the motor and starting again should make it work again as it does/did before the limbo condition hit. I'm convinced this is hardware issue and I guess that only hardware can solve this, ie we need to strictly limit the PSU voltage when the motor is generating energy.

My whole point in this thread has been to try to understand what happens and it looks like know one can answer that. I accept that and we will just avoid this condition.

wbr Kusti