InstaSPIN Motor Control on TIVA processors

Sean,
No, the InstaSPIN-FOC and -MOTION solutions are only available on Piccolo devices.

A few years ago there was a Tiva kit for the DRV8312 that showed use of sensorless (SMO) FOC but that isn't supported by anyone either. Your best luck may be looking at the Hercules ARM Cortex-R4F devices and their motor kits...at least as a starting point.

If you aren't experienced in sensorless motor control be warned, it is very challenging to bring a robust solution to market.

Thanks, CHris. I will look at the hercules. That is a Cortex M4 , too, is it?

Is the Sliding Mode Observer available in the InstaSPIN FOC or InstaSPIN MOTION libraries ... or in the DIgital Motor Control Library? I would like to try using SMO vs FAST.

The problem I am trying to solve here is to find a TI processor with a small foot print and many pins (i.e. BGA) where I can bootstrap the motor control project by using the InstaSPIN libraries

the 28069M (at least the control card version) is pulling ~900mW at 90MHz and the chip does not have much more I/O after I run to motor drive ICs, like TI DRV8301 or Microchip MCP8026.

here's the SW for that Tiva/Stellaris kit, still available online
www.ti.com/.../SW-DK-LM4F-DRV8312;tisearch=Search-EN-Everything

No, we do not include the SMO/eSMO in MotorWare, it is only in controlSUITE (and for the Tiva kit).

There is no technical reason to use the SMO if you have FAST unless you are worried about not having access to the source code (which is valid for some applications).

the Hercules is R4F
here is an example kit
www.ti.com/.../drv8301-rm48-kit

no SMO, but encoder based FOC is included as well as InstaSPIN-BLDC (library based)

Thanks, Chris. I will look at the Hercules devices. That is a ARM Cortex M4 , too, is it?

Is the Sliding Mode Observer available in the InstaSPIN FOC or InstaSPIN MOTION libraries ... or in the DIgital Motor Control Library? I would like to try using SMO vs FAST.

The problem I am trying to solve here is to find a TI processor with a small foot print and many pins (i.e. BGA), where I can bootstrap the motor control project by using the InstaSPIN libraries

The 28069M (at least the control card version) is pulling ~900mW at 90MHz and the chip does not have much more I/O after I run to motor drive ICs, like TI DRV8301 or Microchip MCP8026.

Chris,

When you say the TIVA+DRV8312+SMO/FOC from the past is no longer a supported kit, do you mean there is no documentation, code, or libraries ... or just no support? The TM4C123 has the foot print, pin count and power level I want. It has 2x4 ePWM generators. It just doesn't have InstaSPIN.

The design I am working on has a sInusoidal FOC drive through redundant external motor driver ICs for a PMSM. The TMS320F28069M will do it with InstaSPIN and two external driver ICs (TI DRV8301 or Microchip MCP8026). We want the FETs external, so the BEMF signal can be accessed off the shunt resistors. But, the 69M pulls too much power, it's too big and flat QFP, and it does not have enough I/O left after using 6 ePWM channels. I have not fiddled with using FPU, CLA, or changed the clock speed (90MHz), to try and save power.

The motor is sensorless, 2 pole pair, low inductance (<70uH), ~3A maximum current, and 8-18kRPM. I need a sensorless drive. We want sinisoidal vs. trapazoidal and sppeed controlled. I am curious if using InstaSPIN will require a sort of auto-calibration phase (and perhaps continuous monitoring) for each individual motor or if a general set of motor parameters will work for all motors built.

Ideally, I would try a motor drive control design like this ... TM4C123 + 2xMCP8026 + SMO/FOC

I have already written an MCP8026 driver and linked it in with InstaSPIN to run on essentially a 2xMCP8026-69M-KIT board we made, modeled after the DRV8301-69M-KIT. It receives the same 69M-ISO control card. I feel comfortable with builds using InstaSPIN modules and modifiying underlying drivers, and the hardwarte abstraction layer. I need a driver library for the TIVA to build a HAL module, then port InstaSPIN and get access to a SMO module (there is no FAST on TIVA). The Sliding Mode Observer is the thing. Is there source or access to a SMO module in a DMC Library? SMO should be a target independent module, I would think.

Please advise.

SKB

"When you say the TIVA+DRV8312+SMO/FOC from the past is no longer a supported kit"

The kit is not available for purchase any longer. I gave you a link for the SW download. No one from TI will offer any sort of support if you have questions, etc. You would be all on your own.

". I am curious if using InstaSPIN will require a sort of auto-calibration phase (and perhaps continuous monitoring) for each individual motor or if a general set of motor parameters will work for all motors built."

you do not need to ID each motor if they are the "same" motor with only normal manufacturing variance. You should of course do an RsRecal somewhat regularly or use the RsOnline (though your high speed application really doesn't require tracking of Rs)

"Is there source or access to a SMO module in a DMC Library? SMO should be a target independent module, I would think."

there is source for SMO and eSMO in controlSUITE. There should also be source for SMO in the Tiva download I posted.

SMO should actually work ok for your application in general. You aren't trying to run extremely slow and your top frequency is 600 Hz.  good luck!

TIVA doesn't have FAST. If I am to do Sensorless FOC Motor Control on a Tiva is why I thought I would I need an SMO module.

correct.
see the software download I linked. it should be included if I remember the kit contents correctly.

Okay, so I've looked at the eSMO/SMO documentation in controlSuite. I am assuming it is possible to drop this in to get the rotor angle Theta vs. the FAST angle estimator solution in my current drv8301-69M-kit experimental code. Is there anything else from FAST that is being used in say, proj5b.c?

I wouldn't recommend trying to drop SMO into the MotorWare / InstaSPIN-FOC control system, I would use an SMO project from controlSUITE or the Tiva example if using Tiva MCU.

The ROM library includes more than just the FAST observer, it controls most of the state machine for motor ID as well as the start--up options (recalibration, offsets, forceangle). I do not think it would be so straight forward to replace just the estimator with SMO.

Chris,

am using the DRV8301-69M-KIT with InstaSPIN to implement an FOC drive control. I do want to replace using FAST for obtaining the rotor angle with SMO

Below here is the prototype for a function to set up parameters that are used during motor operation in funtion SMO_POS_run() to compute Theta (the rotor angle)

//! \brief Sets up the SMO_POS module
//! \param[in] smo_posHandle The smo_pos handle
//! \param[in] Rs Stator resistance (ohm)
//! \param[in] Ls Stator inductance (H)
//! \param[in] Vb Base phase voltage (volt)
//! \param[in] Ib Base phase current (amp)
//! \param[in] period Sampling period in sec
void SMO_POS_setup(SMO_POS_Handle smo_posHandle, const float32_t Rs, const float32_t Ls,const float32_t Vb, const float32_t Ib, const float32_t period );

Where do I get the "Base Phase Voltage" and "Base phase current" values?

SKB

Chris,

I understand that FAST does much more than return a rotor angle estimate when the motor is running. I would like to run SMO in parallel with the FAST observer until I see them both delivering a similar Theta and just to see how SMO performs. After that, I will consider what it takes to implement sinusoidal FOC without having FAST on chip.

SKB

no one has done that before. It should be doable, you have all the inputs needed for the SMO. Your bigger challenge will probably be just in mixing the two types of software together.

Base Phase Voltage / Base Phase Current are found in the -Settings.h file in the controLSUITE format.
HVPM_Enhanced_Sensorless-Settings.h

this is discussed in the documentation for these projects.

Okay, my existing system on the DRV8301-69M-KIT board seems closest to DRV830x-HC-C2-KIT_v105 project

From "C:\ti\controlSUITE\development_kits\DRV830x-HC-C2-KIT_v105\PM_Sensorless\PM_Sensorless-Settings.h" ...

// Define the base quantites
#define BASE_VOLTAGE 38.29 // Base peak phase voltage (volt), maximum measurable DC Bus(66.32V)/sqrt(3)

//options for BASE_CURRENT based on DRV830x current-sense amplifier gain setting
//NOTE: DRV8302 can only be set to gain of 10 or 40
//#define DRV_GAIN 10
//#define DRV_GAIN 20
#define DRV_GAIN 40
//#define DRV_GAIN 80

#if DRV_GAIN == 10
#define BASE_CURRENT 82.5 // Base peak phase current (amp) , maximum measurable peak current (with DRV830x gain set to 10)
#elif DRV_GAIN == 20
#define BASE_CURRENT 41.25 // Base peak phase current (amp) , maximum measurable peak current (with DRV830x gain set to 20)
#elif DRV_GAIN == 40
#define BASE_CURRENT 20.625 // Base peak phase current (amp) , maximum measurable peak current (with DRV830x gain set to 40)
#elif DRV_GAIN == 80
#define BASE_CURRENT 10.3125 // Base peak phase current (amp) , maximum measurable peak current (with DRV830x gain set to 80)

So, the numbers I will use for Vb and Ib will be as follows(I am using gain 40V/V) ...

#define BASE_VOLTAGE 38.29 // Base peak phase voltage (volt), maximum measurable DC Bus(66.32V)/sqrt(3)
#define BASE_CURRENT 20.625 // Base peak phase current (amp) , maximum measurable peak current (with DRV830x gain set to 40)

These will be used to set up Fsmopos and Gsmopos parameters in and SMOPOS structure, before it is used with calls to SMO_MACRO
I am using the IQ version of smopos.h from "C:\ti\controlSUITE\libs\app_libs\motor_control\math_blocks\v4.3\smopos.h"

The computation of these values is done as per the

//! \brief Setup the SMO_POS module
//! \param[in] SMO_POS_Handle The SMO_POS handle
inline void SMO_POS_calc_params(SMO_POS_Handle smo_posHandle)
{
SMO_POS_Obj *smo_pos = (SMO_POS_Obj *)smo_posHandle;

smo_pos->Fsmopos = expf((-smo_pos->Rs/smo_pos->Ls)*(smo_pos->Ts));
smo_pos->Gsmopos = (smo_pos->Vb/smo_pos->Ib)*(1.0f/smo_pos->Rs)*(1.0f-smo_pos->Fsmopos);
} // end of SMO_POS_calc_params() function

from "C:\ti\motorware\motorware_1_01_00_14\sw\modules\smopos\src\float32\smopos.h"

We will see how this goes. AM I headed in the right direction here, do you think, Chris?

SKB

sure.
as I stated, pulling the SMO into MotorWare/InstaSPIN-FOC structure is where you will have challenges.
I agree it's a good idea to see if you can run the SMO as-is with your own motor...

good luck

I read through and understood all of the documentation on SMO that I could find in the controlSuite and Motorware source files and documents.
I took working proj5b code that uses the FAST observer to compute Theta. I set up all of the Fsmopos, Gsmopos, Kslide, and Kslf values in an SMO block with a SMO_CALC_PARAMS macro invoked in proj5b.c::main(), just after where the voltage and current offset are set. Then, SMO_MACRO is invoked from within the inline ctrl.h::CTRL_runOnlineUser() to generate gSmoPos.Theta, which should be equivalent to
'angle_pu' coming from the FAST observer (EST_getAngle_pu).

But, there is a function I am yet missing, the "flux angle correction". The correction has to be there for the delay caused by the the low pass filter used on the estimated back EMF value (Kslf = 2*pi*f0) in e(s) = e(s) + Kslf(z(s) - e(s)

Where can I get the "flux angle correction" code? The value of Kslf is set to 0.1 = 2*pi*f0, which is the time constant of that filter, right?
So, is the correction to Theta to added the filter delay @ the w(omega) frequency to the rotor angle estimate coming from the SMO.

Hmm, how does that delay vary with motor speed?

#define SMO_MACRO(v) \
\
/* Sliding mode current observer */ \
(v).EstIalpha = _IQmpy((v).Fsmopos,(v).EstIalpha) + _IQmpy((v).Gsmopos,((v).Valpha-(v).Ealpha-(v).Zalpha)); \
(v).EstIbeta = _IQmpy((v).Fsmopos,(v).EstIbeta) + _IQmpy((v).Gsmopos,((v).Vbeta -(v).Ebeta -(v).Zbeta )); \
\
/* Current errors */ \
(v).IalphaError = (v).EstIalpha - (v).Ialpha; \
(v).IbetaError = (v).EstIbeta - (v).Ibeta; \
\
/* Sliding control calculator */ \
/* v.Zalpha=v.IalphaError*v.Kslide/v.E0) where E0=0.5 here*/ \
(v).Zalpha = _IQmpy(_IQsat((v).IalphaError,(v).E0,-(v).E0),_IQmpy2((v).Kslide)); \
(v).Zbeta = _IQmpy(_IQsat((v).IbetaError ,(v).E0,-(v).E0),_IQmpy2((v).Kslide)); \
\
/* Sliding control filter -> back EMF calculator */ \
(v).Ealpha = (v).Ealpha + _IQmpy((v).Kslf,((v).Zalpha-(v).Ealpha)); \
(v).Ebeta = (v).Ebeta + _IQmpy((v).Kslf,((v).Zbeta -(v).Ebeta)); \
\
/* Rotor angle calculator -> Theta = atan(-Ealpha,Ebeta) */ \
(v).Theta = _IQatan2PU(-(v).Ealpha,(v).Ebeta);


/*
Extended version of sliding control calculator

if (_IQabs((v).IalphaError) < E0)
(v).Zalpha = _IQmpy((v).Kslide,_IQdiv((v).IalphaError,E0));
else if ((v).IalphaError >= E0)
(v).Zalpha = (v).Kslide;
else if ((v).IalphaError <= -E0)
(v).Zalpha = -(v).Kslide;

if (_IQabs((v).IbetaError) < E0)
(v).Zbeta = _IQmpy((v).Kslide,_IQdiv((v).IbetaError,E0));
else if ((v).IbetaError >= E0)
(v).Zbeta = (v).Kslide;
else if ((v).IbetaError <= -E0)
(v).Zbeta = -(v).Kslide;
*/


#define SMO_CALC_PARAMS(v, Rs, Ls, Ts, Vb, Ib) \
\
(v).Fsmopos = _IQexp(_IQmpy(_IQdiv(-(Rs), (Ls)), (Ts))); \
(v).Gsmopos = _IQmpy(_IQmpy(_IQdiv((Vb), (Ib)), _IQdiv(_IQ(1.0f), Rs)),(_IQ(1.0f) - (v).Fsmopos));

/*
smo_pos->Fsmopos = expf((-smo_pos->Rs/smo_pos->Ls)*(smo_pos->Ts));
smo_pos->Gsmopos = (smo_pos->Vb/smo_pos->Ib)*(1.0f/smo_pos->Rs)*(1.0f-smo_pos->Fsmopos);
*/

The flux angle correction is part of the esmo library. Details of that is tied to a licensing agreement.

rgds,

ramesh

the eSMO is only provided as a .lib
you may want to look at using the completely visible source of SMO

Yes, this is in the Stellaris kit

C:\StellarisWare\AppNotes\sw01294\motorware_1_00_01_00\sw\modules\smopos\src\float32\smopos.c/.h

C:\StellarisWare\AppNotes\sw01294\motorware_1_00_01_00\sw\solutions\foc_smo\boards\drv8312kit_revD\stellaris\lm4f211\src\drv.c/.h

C:\StellarisWare\AppNotes\sw01294\motorware_1_00_01_00\sw\solutions\foc_smo\boards\drv8312kit_revD\stellaris\lm4f211\projects\ccs5\project01\main.c

etc.

There is no use of a "flux angle correction" function applied to the SMO rotor angle estimate. At least I do not see it.

from main.c::void ADCS0IntHandler(void) ...

IPARK_run(gDRVObj.iParkHandle, &gDRVObj.parkInVec, &gDRVObj.pOutVec);
gDRVObj.iParkAlpha = gDRVObj.pOutVec.value[0];
gDRVObj.iParkBeta = gDRVObj.pOutVec.value[1];

// ------------------------------------------------------------------------------
// Connect inputs of the VOLT_CALC module and call the phase voltage macro
// ------------------------------------------------------------------------------
gDRVObj.DcBusV.dcBusV = gDRVObj.ulADC0Value[3] * 0.000244140625;
gDRVObj.pInVec.value[0] = gDRVObj.pOutSVGen.value[0];
gDRVObj.pInVec.value[1] = gDRVObj.pOutSVGen.value[1];
gDRVObj.pInVec.value[2] = gDRVObj.pOutSVGen.value[2];
VOLT_CALC_run(gDRVObj.voltCalcHandle, &gDRVObj.DcBusV, &gDRVObj.pInVec, &gDRVObj.pOutVec);

// ------------------------------------------------------------------------------
// Connect inputs of the SMO_POS module and call the sliding-mode observer macro
// ------------------------------------------------------------------------------
gDRVObj.iInVec.value[0] = gDRVObj.clarkeAlpha;
gDRVObj.iInVec.value[1] = gDRVObj.clarkeBeta;
gDRVObj.vInVec.value[0] = gDRVObj.pOutVec.value[0];
gDRVObj.vInVec.value[1] = gDRVObj.pOutVec.value[1];
SMO_POS_run(gDRVObj.smoPosHandle, &gDRVObj.vInVec, &gDRVObj.iInVec, &gDRVObj.smoPosOut);

// ------------------------------------------------------------------------------
// Connect inputs of the SPEED_EST module and call the estimated speed macro
// ------------------------------------------------------------------------------
SPEED_FR_run(gDRVObj.speedFrHandle, gDRVObj.smoPosOut.ElecTheta, &(gDRVObj.speedOut));

// Switch Modes if we have achieved the speed requested in RampGen Commutation
if((gDRVObj.lsw == 1) && (gDRVObj.speedRef >= 0.2))
{
if((gDRVObj.rmpCntlHandle->setpointValue + 0.01) >= 0.2)
{
if(gDRVObj.transFlag == 0)
{
gDRVObj.beginCount = gDRVObj.isrTicker;
gDRVObj.transFlag = 1;
}
else if(gDRVObj.beginCount + 10000 <= gDRVObj.isrTicker)
{
gDRVObj.lsw = 2;
gDRVObj.transFlag = 0;
}
}
}

if((gDRVObj.lsw == 1) && (gDRVObj.speedRef <= -0.2))
{
if((gDRVObj.rmpCntlHandle->setpointValue - 0.01) <= -0.2)
{
if(gDRVObj.transFlag == 0)
{
gDRVObj.beginCount = gDRVObj.isrTicker;
gDRVObj.transFlag = 1;
}
else if(gDRVObj.beginCount + 10000 <= gDRVObj.isrTicker)
{
gDRVObj.lsw = 2;
gDRVObj.transFlag = 0;
}
}
}

// ------------------------------------------------------------------------------
// Connect inputs of the SVGEN_DQ module and call the space-vector gen. macro
// ------------------------------------------------------------------------------
gDRVObj.pVref.value[0] = gDRVObj.iParkAlpha;
gDRVObj.pVref.value[1] = gDRVObj.iParkBeta;
SVGEN_run(gDRVObj.svGenHandle, &gDRVObj.pVref, &gDRVObj.pOutSVGen);

// ------------------------------------------------------------------------------
// Connect inputs of the PWM_DRV module and call the PWM signal generation macro
// ------------------------------------------------------------------------------
gDRVObj.mFuncV1 = (int16_t)(gDRVObj.pOutSVGen.value[0] * 32768);
gDRVObj.mFuncV2 = (int16_t)(gDRVObj.pOutSVGen.value[1] * 32768);
gDRVObj.mFuncV3 = (int16_t)(gDRVObj.pOutSVGen.value[2] * 32768);
Generate_Outputs((DRV_Handle)&gDRVObj);

// GUI Update
if(gDRVObj.speedOut >= gDRVObj.graphData->trigValue)
{
gDRVObj.graphData->trigValue = 0;
}

Graph_Data_Update(gDRVObj.graphData);

}//end if(RunMotor)

ROM_ADCIntClear(ADC0_BASE, 0);

}// end of ADCS0IntHandler()

Am I missing "flux angle correction" in this implementation of FOC_SMO? Is it at the tail end of the float SMOPOS?
I considered a macroized version of the float SMOPOS here compared the InstaSPIN SMO_MACRO and I see no difference
_IQsat() I think implements the bang-bang control, z(n) = Kslide * sign(EstI(s) - I(s)), correctly, as in the comment below it's use

I have compared the angle_pu comining from FAST with gSmoPos.Theta generated by the SMO_MACRO. There is not a stable difference in the _IQ values.

I do not see a code difference between what I have in that SMO_MACRO from InstaSpin and the code in the float SMOPOS code used on the Stellaris project.in terms of what value it generates, given the same Kslide and Kslf values. However the Kslide and Kslf values used are different.

I tried Kslide = 0.15 and Kslf = 0.1

The stellaris project seems to have used ...

SMO_POS_init(gDRVObj.smoPosHandle, sizeof(gSmoPosObj), 0.79, 0.0012, 38.29, 8.6, gDRVObj.t);
gSmoPosObj.Kslide = 0.225f;
gSmoPosObj.Kslf = 0.525f;


I can try those Kslide and Kslf values. But is there no more? How is the delay in the Theta estimate caused the Kslf low pass filter corrected for?

This is on another subject, but I noted something, I think, and wanted to ask about this. The value
Fsmopos = exp((R/L)*T), and from tuning the torque loop from InstaSPIN proj4b.c, IseriesPU = ((R/L)*T).

What does it mean, then, that Fsmopos = exp(IseriesPU)?


Regards,
SKB

Are the values for Kslide or Kslf used in the SMO_MACRO "per unitized values" and/or are they related to the PWM frequency? What specifies f0 in Kslf = 2*pi*f0 ?

Okay. I have a macro-ized version (_IQmathLib, too) of SMOPOS running right next to the FAST observer in proj5b.c code on the DRV8301_69M_KIT. The out put of SMOPOS "lags" behind the FAST observer. I need to understand how w* (omega), the speed reference, and maybe Kslide or Kslf for this SMOPOS (rotor position observer) can be "corrected".

Please advise.