Bandwidth limitations

mojo,

we do not have a speciific limitation.  we have run with the standard InstaSPIN-FOC control system over 1.5KHz with 15 KHz FAST estimation.  To do this you may have to change the speed filter in user.h

Once you get over these speeds you will start to see the effect of sample to output delay, meaning that your output stimulus is based on a sample 15 KHz back in time, and the rotor has moved significantly enough that your output is not exactly where you would want it to be with the new location.  it is rather simple to add software angle compensation for this effect.  we have done so and have tested motors up to 2.5 KHz performing flawlessly.  this angle compensation will be added into MotorWare in one of the next releases. The software is all functioning we just have to add the documentation around it, which tends to take the most time. 

We have an update planned shortly here for June. I think angle compensation will end up in the next one near end of July.

Hi Chris,

thanks for the quick reply..

If I understand correctly the 15kHz you're talking about is the sampling rate (synchronized to PWM probably ?). If that's true, I could actually raise the PWM frequency, let's say to 50kHz and so on... if I use a motor of 3-4 kHz ?

Is that the limitation you're talking about ? there's no limitation for the estimator by itself (like a digital filter, which has a bandwidth...) ?

thanks

The 15 Khz is the execuation rate of the controller. In this case it's talking about the FAST estimator as well as the current controller.  It's the rate at which you are creating an estiamated angle and applying the correction to the system vs. how much the rotor is actually moving in that time.

There is also a software filter inside of FAST for the speed estimation

//! \brief Defines the software pole location for the speed control filter, rad/s
#define USER_SPEED_POLE_rps           (100.0) // 100.0 Default, do not change

We made this accessible but I don't believe it will need to be changed...but I'm not writing the documentation so be sure to check that once the angle compensation example is publishe.

ok, so to summarize this - I could basically run also at 100kHz (assuming the processor can handle the calculations, inverter etc.), and by that raise the bandwidth of the estimator with respect to 15kHz. is that correct ?

I didn't read yet how the estimator works but I assume that at some point it's calculating the mathematical model (in one way or another) of the motor, so high rate is preferable... ?

thanks again for your great support

The control system (Transformations --> FAST --> Current --> Transforms) typically needs to be run at 10 KHz, and as you get into higher dynamics / higher speed you need to increase this to 15 KHz. There may be some benefit in very high speeds to get up to 20 KHz.

The PWM rate will depend on the inverter and current that is drawn (increasing PWM to reduce curent ripple).

Yes, FAST is model based.

ok, thanks

Sorry for all the questions, but I didn't get yet my kit... so I'm curious in the meantime...

I would assume that the current loop frequency and PWM will be the same, as ADC samples are synched to the PWM ?

hope to get my kit soon :)

thanks

to give you a bit more clarity, the general rule we would state is that

FAST should be executed ~7-10x as often as the maximum speed.

So for a 700 Hz motor, FAST should be run at least 5-7-KHz rate.

For a 2 KHz  motor, FAST should be run at least 14-20 KHz rate.

And in these higher speeds you will still need to do some additional angle compensation to address the sample/output delay.

ok, this is what I thought.

thanks

the clocks are in a tree, with easy decimation. This is also covered in the UG

ti.com/lit/spruhj1

PWM rate, can set the ADC SOC every 1st, 2nd, 3rd event (this is being added as a new "TICK" in the next MotorWare release)

The ADC done is the main clock into the control system.

You can then decimate this clock that feeds the current controller, FAST, speed controller, and trajectory controller.