InstaSPIN Projects and Labs User’s Guide
InstaSPIN Projects and Labs User’s Guide
Product Overview
Both InstaSPIN-FOC and InstaSPIN-MOTION are sensorless or sensored FOC solutions that identify,
tune and control your motor in minutes. Both solutions feature:
The FAST unified software observer, which exploits the similarities between all motors that use
magnetic flux for energy transduction. The FAST estimator measures rotor flux (magnitude and
angle) in a sensorless FOC system.
Automatic torque (current) loop tuning with option for user adjustments
Automatic or manual field weakening and field boosting
Bus voltage compensation
Additional information about the features and functionality of InstaSPIN-FOC and InstaSPIN-MOTION can
be found in the Technical Reference Manuals and User’s Guide.
1
Lab Projects Overview
The example projects (labs) described in this section are intended for you to not only experiment with
InstaSPIN but to also use as reference for your design. These projects will help you develop a successful
product. InstaSPIN-FOC and InstaSPIN-MOTION motor control solutions, as well as the lab projects, are
delivered within MotorWare. For a latest complete listing of the API functions, MotorWare’s Software
Coding Standards, and Architecture, run MotorWare.exe from the latest version install.
Ex: C:\ti\motorware\motorware_1_01_00_13\MotorWare.exe
In the lab projects, you will learn how to modify user.h, the file that stores all of the user parameters.
Some of these parameters can be manipulated through the GUI or CCS during run-time, but the
parameters must be updated in user.h to be saved permanently in your project.
The following table summarizes all the projects available, and also what projects apply to which boards
and target device.
drv8301kit
drv8312kit boost
hvkit
2
MOTION Lab06d Design your own SpinTAC Velocity Plan
FOC Lab07 Rs Online
FOC Lab07a Lab07 with fpu32
FOC Lab09 Field Weakening
FOC Lab09a Lab09 with fpu32
FOC Lab10a Overmodulation
MOTION Lab10b Overmodulation with MOTION
FOC Lab10c Lab10a with fpu32
MOTION Lab12a Sensored Inertia ID
MOTION Lab12b SpinTAC Sensored Speed Control
MOTION Lab13a Tuning SpinTAC Position Control
MOTION Lab13b Position Transitions with SpinTAC Move
MOTION Lab13c Motion Sequence Position Example
MOTION Lab13d Motion Sequence Example – Vending Machine
MOTION Lab13e Smooth Velocity Transitions in Position Control
3
Version: 1.0.11
Revision History:
1.0.11 June 19, 2014 Modified current controller gains calculation for lab 5a
1.0.8 November 07, 2013 Added note for CCS to NOT copy project into workspace
(page 11)
4
and Flash. Switch between build configurations if a Flash
project is required.
1.0.5 February 26, 2013 First released in the Appendix of the InstaSPIN-FOC User’s
Guide.
Labs Supported:
Contents
Product Overview ................................................................................................................... 1
Lab Projects Overview ............................................................................................................ 2
Lab Descriptions ..................................................................................................................... 7
Lab 1 - CPU and Inverter Setup .............................................................................................. 13
Lab 2a - Using InstaSPIN for the First Time out of ROM ......................................................... 25
Lab 2b – Using InstaSPIN out of User RAM and/or FLASH ...................................................... 39
Lab 2c – Using InstaSPIN to Identify Low Inductance PMSM .................................................. 47
Lab 2d – Using InstaSPIN out of User Memory, with fpu32 .................................................... 51
Lab 3a – Using your own motor parameters .......................................................................... 52
Lab 3b – Using your own Board Parameters: Current and Voltage Offsets (user.h) ............... 59
5
Lab 3c – Using your own Board Parameters: Current and Voltage Offsets, with fpu32 .......... 66
Lab 4 – Current Loop Control (Create a Torque Controller) .................................................... 67
Lab 4a – Current Loop Control (Create a Torque Controller), with fpu32 ............................... 73
Lab 5a – Tuning the FAST Current Loop ................................................................................. 74
Lab 5b – Tuning the FAST Speed Loop ................................................................................... 86
Lab 5c - InstaSPIN-MOTION Inertia Identification ................................................................ 111
Lab 5d - InstaSPIN-MOTION Speed Controller ..................................................................... 122
Lab 5e - Tuning the InstaSPIN-MOTION Speed Controller .................................................... 127
Lab 5f - Comparing Speed Controllers ................................................................................. 133
Lab 5g – Adjusting the InstaSPIN-FOC Speed PI Controller, with fpu32 ................................ 139
Lab 6a - Smooth system movement with SpinTAC Move ..................................................... 140
Lab 6b - Motion Sequence Example .................................................................................... 148
Lab 6c - Motion Sequence Real World Example: Washing Machine ..................................... 156
Lab 6d - Designing your own Motion Sequence ................................................................... 164
Lab 7 – Using Rs Online Recalibration ................................................................................. 172
Lab 7a – Using Rs Online Recalibration, with fpu32 ............................................................. 177
Lab 9 – An Example in Automatic Field Weakening ............................................................. 178
Lab 9a – An Example in Automatic Field Weakening, with fpu32 ......................................... 179
Lab 10a – An Example in Space Vector Over-Modulation .................................................... 180
Lab 10b – An Example in Space Vector Over-Modulation using InstaSPIN-MOTION............. 181
Lab 10c – An Example in Space Vector Over-Modulation, with fpu32 .................................. 182
Lab 12a – Sensored Inertia Identification ............................................................................ 183
Lab 12b - Using InstaSPIN-MOTION with Sensored Systems ................................................ 192
Lab 13a - Tuning the InstaSPIN-MOTION Position Controller ............................................... 197
Lab 13b - Smooth Position Transitions with SpinTAC™ Move .............................................. 206
Lab 13c - Motion Sequence Position Example ..................................................................... 215
Lab 13e - Smooth Velocity Transitions in Position Control ................................................... 232
6
Lab Descriptions
Lab 1 – CPU and Inverter Setup
This application note covers how to use the HAL object to setup the 2806xF/M, 2805xF/M or
2802xF and inverter hardware. MotorWare API function calls will be used to simplify the
microprocessor setup.
InstaSPIN implements a FAST enabled self-sensored field oriented variable speed controller. The
ROM library contains the FAST angle observer plus all code needed to implement the FOC
controller. For this lab we start by using the full ROM based code to create a FOC motor control.
InstaSPIN does not have to be executed completely out of ROM. Actually, most of the InstaSPIN
code is provided as open source. The only closed source code is the FAST angle observer. This
lab will show how to run the sensorless field oriented controller as open source in user RAM. The
only function calls to ROM will be to update and to pull information from the FAST observer.
This particular lab provides an example to identify difficult PMSM motors, especially the low
inductance PMSM motors.
This lab is the same as lab 2b, but with fpu32 enabled. This lab only applies to 2806xF device
variants.
By default, InstaSPIN starts by identifying the motor that is attached to the inverter. When
identifying the motor, the parameters Rs, Ls, and air gap flux are estimated. This lab will take the
motor parameter estimates from the previous lab and place them into the file user.h. User.h is
used to hold scaling factors, motor parameters, and inverter parameters for customizing InstaSPIN
to any motor control system.
Lab 3b – Using your own Board Parameters: Current and Voltage Offsets (user.h)
Skipping auto-calibration and using your own current and voltage offsets continues to reduce the
start-up time. If the board offsets are known, then auto-calibration at start-up is not needed. Also
introduced is the option to bypass the Rs Fine Re-estimation.
Lab 3c – Using your own Board Parameters: Current and Voltage Offsets, with fpu32
This lab is the same as lab 3b, but with fpu32 enabled. This lab only applies to 2806xF device
variants.
The speed loop is disabled and a reference is sent directly to the Iq current controller. Bypassing
the speed loop and directly controlling Iq current makes the FOC control torque.
7
Lab 4a – Current Loop Control (Create a Torque Controller), with fpu32
This lab is the same as lab 4, but with fpu32 enabled. This lab only applies to 2806xF device
variants.
For the current loop PIs, InstaSPIN calculates starting Kp and Ki gains for both Id and Iq. During
start-up, InstaSPIN identifies the time constant of the motor to determine the Ki and Kp.
Sometimes the Id and Iq Kp and Ki gains need to be manually adjusted for an optimal setting.
This lab will keep the torque controller from Lab 4 and will show how to manually adjust the current
PI controller.
InstaSPIN-FOC provides a standard PI speed controller. The InstaSPIN library will give a “rule of
thumb” estimation of Kp and Ki for the speed controller based on the maximum current setting in
user.h. The estimated PI controller gains are a good starting point but to obtain better dynamic
performance the Kp and Ki terms need be tuned based on the whole mechanical system that the
motor is running. This lab will show how to adjust the Kp and Ki terms in the PI speed controller.
Inertia identification is the first step in enabling the InstaSPIN-MOTION speed controller. The
inertia value is automatically identified by the controller, and is used to determine how strongly to
respond to disturbances in the system. In this lab, you will learn how to run the inertia
identification process from within your MotorWare project.
The InstaSPIN-MOTION speed controller features Active Disturbance Rejection Control (ADRC),
which actively estimates and compensates for system disturbances in real time. The InstaSPIN-
MOTION speed controller also features a single parameter, bandwidth, which determines the
stiffness of the system and dictates how aggressively the system will respond to disturbances.
Once tuned, the controller the typically works over a wide range of speeds and loads.
In this lab, you will learn how to replace the InstaSPIN-FOC PI controller with the InstaSPIN-
MOTION speed controller in your MotorWare project.
With single coefficient tuning, InstaSPIN-MOTION allows you to quickly test and tune your velocity
control from soft to stiff response. The single gain (bandwidth) typically works across the entire
variable speed and load range, reducing complexity and system tuning. In this lab, you will tune
the InstaSPIN-MOTION speed controller to obtain the best possible system performance.
8
Lab 5f – Comparing Speed Controllers
The InstaSPIN-MOTION speed controller shows remarkable performance when compared against
a traditional PI controller. This lab will lead you through a comparison of these two controllers.
This lab is the same as lab 5b, but with fpu32 enabled. This lab only applies to 2806xF device
variants.
InstaSPIN-MOTION includes SpinTAC Move, a motion profile generator that generates constraint-
based, time-optimal motion trajectory curves. It removes the need for lookup tables, and runs in
real time to generate the desired motion profile. This lab will demonstrate the different
configurations and their impact on the final speed change of the motor.
InstaSPIN-MOTION includes SpinTAC Velocity Plan, a motion sequence planner that allows you
to easily build complex motion sequences. You can use this functionality to quickly build your
application’s motion sequence and speed up development time. This lab provides a very simple
example of a motion sequence.
This lab builds off Lab 6b and provides a very complex example of a motion sequence.
Now that SpinTAC Velocity Plan has been introduced, this lab lets you create your own motion
sequence. It is a chance to be creative and utilize the topics and skills that were learned in
previous labs.
With the motor under heavy load, Rs Online Recalibration is required to maintain performance of
FAST. This lab will explore using this feature.
This lab is the same as lab 7, but with fpu32 enabled. This lab only applies to 2806xF device
variants.
A simple procedure in automatic field-weakening is explored. The current voltage space vector is
always compared to the maximum space vector. A voltage “head room” is maintained by
controlling the negative Id current of the FOC controller.
This lab is the same as lab 9, but with fpu32 enabled. This lab only applies to 2806xF device
variants.
9
Lab 10a – An Example in Space Vector Over-Modulation
The SVM that is used by InstaSPIN is capable of saturating to a pre-specified duty cycle. When
using a duty cycle greater than 86.6%, the SVM is considered to be in the over-modulation region.
When in the over-modulation region, current shunt measurement windows become small or even
disappear. This lab will show how to re-create the currents that cannot be measured due to high
duty cycles during SVM over-modulation.
The SVM that is used by InstaSPIN is capable of saturating to a pre-specified duty cycle. When
using a duty cycle greater than 86.6%, the SVM is considered to be in the over-modulation region.
When in the over-modulation region, current shunt measurement windows become small or even
disappear. This lab will show how to re-create the currents that cannot be measured due to high
duty cycles during SVM over-modulation. This example adds the InstaSPIN-MOTION speed
controller and profile generator.
This lab is the same as lab 10a, but with fpu32 enabled. This lab only applies to 2806xF device
variants.
This lab demonstrates how to replace the FAST estimator with a quadrature encoder. It will
demonstrate identifying the system inertia using a quadrature encoder. This lab also discusses
how to identify the system inertia in less than one revolution.
For applications where a sensor is required, InstaSPIN-MOTION can provide the same
advantages that it provides for sensorless applications. Currently, InstaSPIN-MOTION supports a
quadrature encoder. Hall Effect sensors are not supported at this time. This lab demonstrates
how to replace the FAST estimator with a quadrature encoder.
Tuning position control applications can be very difficult and time consuming. InstaSPIN-MOTION
provides a position-velocity controller that can be tuned using a single coefficient. This single gain
(bandwidth) typically works across the entire range of loads and transitions in applications,
reducing their complexity. This lab demonstrates how to connect the InstaSPIN-MOTION position
controller and tune it for your application.
InstaSPIN-MOTION includes SpinTAC Move, a motion profile generator that generates constraint-
based, time-optimal position trajectory curves. It removes the need for lookup tables, and runs in
real time to generate the desired motion profile. This lab will demonstrate the different
configurations and their impact on the final position transition of the motor.
10
InstaSPIN-MOTION includes SpinTAC Velocity Plan, a motion sequence planner that allows you
to easily build complex motion sequences. You can use this functionality to quickly build your
application’s motion sequence and speed up development time. This lab provides a very simple
example of a motion sequence.
This lab builds off Lab 13c and provides a very complex example of a motion sequence.
11
Lab 13e – Smooth Velocity Transitions in Position Control
In addition to providing smooth position transitions, SpinTAC Move can also provide smooth speed
transitions while still operating in a position control system. This lab demonstrates how to
configure SpinTAC Move to generate speed transitions in position mode.
12
Lab 1 - CPU and Inverter Setup
This application note covers how to use the HAL object to setup the 2802xF, 2805xF, 2805xM, 2806xF,
2806xM and inverter hardware. MotorWare API function calls will be used to simplify the microprocessor
setup.
The first lab is an introduction in using the MotorWare software. The 2802xF, 2805xF, 2805xM, 2806xF
and 2806xM processor Clock, GPIOs, Watchdog, and other Peripherals are setup using the HAL object
and APIs. The HAL or “Hardware Abstraction Layer” object is the MotorWare interface to controlling
micro-controller peripherals and inverter setup. All labs in the InstaSPIN series of motor labs build upon
this lab, so it is recommended to perform this lab first before moving on.
Use the HAL object to setup the 2802xF, 2805xF, 2805xM, 2806xF or 2806xM processor.
13
mainISR()
mainISR() --
main()
main() -- main.c
main.c
main.c
main.c
initialize
initialize the
the driver
driver Toggle
Toggle the
the LED
LED
disable
disable the
the watchdog
watchdog Acknowledge
Acknowledge the
the ADC
ADC interrupt
interrupt
setup
setup the
the driver
driver
Read
Read ADC
ADC signals
signals
Write
Write to
to the
the PWMs
PWMs
call
call HVProtection
HVProtection function
function
initiaze
initiaze the
the INT
INT vector
vector table
table
enable
enable the
the ADC
ADC interrupts
interrupts
enable
enable debug
debug interrupts
interrupts return
return
disable
disable the
the PWM
PWM
Enable
Enable global
global INTs
INTs
forever
forever
loop
loop
The MotorWare package is used for this lab. The setup of peripherals and even the inverter will be taken
care of by MotorWare APIs, specifically the HAL object and APIs. Important commands to initialize the
drive are listed in the flowchart of Figure 1. The files and project are located in the MotorWare directory as
shown in Figure 2 depending on which processor the user is working with, below.
For lab 1 and all InstaSPIN-FOC lab projects, the MotorWare path refers to a 2802xF, 2805xF or 2806xF
device series. All TMS320F2802xF, TMS320F2805xF and TMS320F2806xF devices include the
appropriate ROM capability to run these projects. All of the projects are based on an inverter board
(DRV8312, DRV8301, HVMTR, etc.) paired with the TMDSCNCD28027F, TMDSCNCD28054MISO or
TMDSCNCD28069MISO controlCARD. The TMDSCNCD28069MISO controlCARD uses the
TMS320F28069M device. The TMDSCNCD28054MISO controlCARD uses the TMS320F28054M
device. The “M” devices are identical to “F” devices but include additional ROM capability for InstaSPIN-
MOTION. “M” and “F” devices are identical in the software and behavior for all InstaSPIN-FOC projects.
To open lab 1 use the following menu selection: Project -> Import Existing CCS/CCE Project ->
Select the “ccs5” folder at the appropriate MotorWare revision, board and MCU target combination to
import all projects for these labs.: Ex:
c:\ti\motorware\MotorWare_1_01_00_13\sw\solutions\instaspin_foc\boards\drv8312kit_revD\f28x\f2806xF
\projects\ccs5
14
Do NOT select Copy the projects into the workspace
work out of the parent ti\motorware\motorware_#_##_##_## directory
A description of the included files for Lab 1 is shown in the below tables. Note that main.h is common
across all labs so there will be more includes than are needed for this lab.
15
Table 1: Important header files needed for the setup.
main.h Header file containing all included files used in main.c
modules
math.h Common math conversions, defines, and shifts
est.h Function definitions for the FAST ROM library
platforms
hal.h Device setup and peripheral drivers. Contains the HAL object.
user.h User file for configuration of the motor, drive, and system parameters
16
4. main.h is now open for review
Global objects and declarations that are listed in the table below are only the objects that are absolutely
needed for the drive setup. Other object and variable declarations are used for display or information for
the purpose of this lab.
Table 2: Global object and variable declarations important for the setup
globals
CTRL
The handle to the hardware abstraction layer object (HAL). The driver object
HAL_Handle contains handles to all microprocessor peripherals and is used when setting up
and controlling the peripherals.
Holds the scale factor information that is in user.h. Allows for scale factor
USER_Params
updates in real-time.
To view the details of the objects HAL_Handle and USER_Params follow these steps:
1. In the file “proj_lab01.c” right-mouse click on HAL_Handle and select “Open Declaration”
17
2. With the file “hal_obj.h” now open, right- mouse click on HAL_Handle and select “Show In
Outline”
3. With the Outline View open, expand “_HAL_Obj_” to see each member of the HAL object
18
4. In the file “proj_lab01.c” right-mouse click on USER_Params and select “Open Declaration”
5. From the Outline view, expand _User_Params_ to display each member of the object
This section covers functions needed to setup the microcontroller and the FOC software. Only the
functions that are mandatory will be listed in the table below. Functions that are not listed in Table 3:
Important setup functions needed for the motor control are in the project for enhanced capability of the
19
laboratory and not fundamentally needed to setup the drive. For a more in depth explanation for
definitions of the parameters and return values go to the MotorWare section of this document (InstaSPIN-
FOC and InstaSPIN-MOTION User’s Guide, SPRUHJ1).
Enables the ADC interrupt in the PIE, and CPU. Enables the interrupt to be sent
HAL_enableAdcInts
from the ADC peripheral.
HAL_enableGlobalInts Enables the global interrupt.
HAL_disablePwm Set the inverter power switches to high impedance.
The methods used inside of the mainISR() are time critical and are used run-time. When integrating this
ISR into your code, it is important to verify that this ISR runs in real-time.
The code in this lab will blink an LED and read ADC values which will eventually be three motor currents,
three motor voltages, and one DC bus value. PWM values are also written to the inverter with
HAL_writePwmData() resulting in a 50% duty cycle since the gPwmData{} values are initialized to zero
when defined. Table 13 explains the functions used in the mainISR.
20
Table 4: The mainISR API functions that are used for Lab 1.
mainISR
HAL_toggleLed Toggles the LED on the motor inverter.
HAL_acqAdcInt Acknowledges the ADC interrupt so that another ADC interrupt can happen again.
Reads in the Adc result registers, adjusts for offsets, and scales the values
HAL_readAdcData according to the settings in user.h. The structure gAdcData holds three phase
voltages, three line currents, and one DC bus voltage.
Converts the Q pwm values in gPwmData to Q0 and writes these values to the
HAL_writePwmData
EPWM compare registers.
21
Lab1 is a quick lab similar to “Hello World” type of programs. The corresponding embedded programming
code is to blink a LED #2 on the ControlCARD. The goal is to review the MCU and inverter setup
functions, specifically the HAL object and make sure the LED blinks.
1. Insert the MCU control card, connect the USB cable to the control card, and finally apply
power to the kit.
2. Click proj_lab01 at the top of the Project Explorer tab (near the top left of your screen).
4. Click the green bug that symbolizes “Debug”. This button should automatically change the
CCS perspective to “CCS Debug” as well as load the .out file to the target.
5. Click Real-Time Silicon Mode which looks like a clock and press “Yes” if a small window pops
up.
22
6. Click Resume which looks like a yellow vertical line with a green triangle besides it.
7. One of the LED labeled “LD2” on the inverter board will blink.
8. If LED labeled “LD2” doesn’t blink, there might be a user configuration error. In order to see if
this is the case, take a look at the following variable in the watch window:
If this variable is different than “USER_ErrorCode_NoError”, edit user.h file to address the
error shown by variable gMotorVars.UserErrorCode.
9. Lab 1 is complete.
23
The HAL object was created to ease the setup of the MCU and inverter. Lab 1 taught us how to use the
HAL object to setup and initialize the MCU and inverter. We will build on this functionality to see how to
enable InstaSPIN.
24
Lab 2a - Using InstaSPIN for the First Time out of ROM
InstaSPIN-FOC and InstaSPIN-MOTION are FAST enabled self-sensored field oriented controllers.
InstaSPIN-FOC offers cascaded speed control, while the InstaSPIN-MOTION speed controller features
Active Disturbance Rejection Control (ADRC), which estimates and compensates for system disturbances
in real time.
The ROM library contains the FAST observer plus all code needed to implement the FOC controller and
speed loop. For this lab we start by using the full ROM based code to create an FOC motor control.
Labs have been developed to cover the various uses of the on-chip motor control ROM. The library is
very robust and can be customized to many different applications. The library can perform all of the
sensorless estimation and the full cascaded FOC and speed control loop with very minimal external
software or it can just provide the rotor flux angle estimation with the InstaSPIN-MOTION advanced
speed controller. This lab implements the full InstaSPIN-FOC solution from ROM with the fewest number
of library function calls. We will learn what enables the motor parameter identification and then how to
start the motor.
Lab 2a adds the critical function calls for identifying and running a motor. The block diagram of Figure 3
shows the default closed loop functionality of the ROM library. This lab will create a full sensorless FOC
drive with a minimum number of InstaSPIN function calls.
25
CTRL_setMaxAccel_pu CTRL_run
wref CTRL_setup
Traj
User_SpdRef Spdout Iq_ref
Ramp Speed
CTRL_setSpd_ref_krpm Iq
PI HAL_writePwmData
~
w
Iq PI
Vq Vα_out Ta
INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id
Iq PARK
~ HAL_acqAdcInt
~ EST_run q
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle
~
w ~ FAST™ Estimator
EST_getSpeed_krpm w Vα_in Va ADC
Speed Flux, Angle, Speed, Torque
Vb Driver
~t EST_getTorque_lbin ~
t Motor Parameters ID Vβ_in CLARKE
Vc
Torque
Vbus
~ EST_getRs_Ohm
Rs
user.h CTRL_setFlag_enableCtrl
Motor Type
~ EST_getLs_d_H Enable Motor Identification
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
Figure 3: Block diagram for Lab 2a showing what blocks will be used to run an FOC, speed controlled,
PMSM, motor. API functions that are in red are functions that were used in previous labs.
A description of the new included files critical for InstaSPIN setup is shown in the figure below. Note that
main.h is common across all labs so there will be more includes in main.h than are needed for this lab.
26
Global object and declarations that are listed in the table below are only the objects that are absolutely
needed for the motor controller. Other object and variable declarations are used for display or information
for the purpose of this lab.
Table 6: Global object and variable declarations important for the motor control
globals
CTRL
The handle to a controller object (CTRL). The controller object implements all of
CTRL_Handle
the FOC algorithms and calls the FAST observer functions.
OTHER
Not needed for the implementation of InstaSPIN but in the project this structure
MOTOR_Vars_t contains all of the flags and variables to turn on and adjust InstaSPIN. The
structure defined by this declaration will be put into the CCS watch window.
This section covers functions needed to setup the microcontroller and the FOC software. Only the
functions that are mandatory will be listed in the table below. Functions that are not listed in Table 7 are
in the project for enhanced capability of the laboratory and not fundamentally needed to setup the motor
control. For a more in depth explanation for definitions of the parameters and return values go to the
document MotorWare section of this document (InstaSPIN-FOC and InstaSPIN-MOTION User’s Guide,
SPRUHJ1).
27
Table 7: Important setup functions needed for the motor control.
setup
CTRL
Initializes all handles required for field oriented control and FAST observer
CTRL_initCtrl
interface. Returns a handle to the CTRL object.
Copies all scale factors that are defined in the file user.h and used by CTRL into
CTRL_setParams
the CTRL object.
The background loop makes use of functions that allow user interaction with the FAST observer and FOC
software. Table 8 lists the important functions used. The flowchart of Figure 4 shows the logic of the
forever loop. The block called “Update Global Variables” is used to update variables such as speed,
Stator Resistance, Inductance, etc.
Table 8: Functions used in the forever loop that check for errors and setup the InstaSPIN controller and
FAST observer in real-time.
forever
loop
CTRL
Check for errors throughout the state machine of the InstaSPIN controller and
CTRL_isError
FAST observer.
Enables/Disables the sensorless controller. The first time this function is called
and the function CTRL_setFlag_enableUserMotorParams() is not set TRUE, motor
CTRL_setFlag_enableCtrl
commissioning is performed. Then subsequent times it is called the motor will
start to run.
CTRL_updateState Returns "true" if the controller's state machine has changed.
CTRL_getState Returns the state of the controller.
CTRL_setMaxAccel_pu Sets the maximum acceleration rate of the speed reference.
CTRL_setSpd_ref_krpm Sets the output speed reference value in the controller.
HAL
HAL_updateAdcBias It sets the voltage and current measurement offsets, before the motor is started.
Turns on the outputs of the EPWM peripherals which will allow the power
HAL_enablePwm
switches to be controlled.
Turns off the outputs of the EPWM peripherals which will put the power switches
HAL_disablePwm
into a high impedance state.
EST
Sets the maximum current slope for the Iq and Id reference change. If current
EST_setMaxCurrentSlope_pu
isn't ramping as fast as needed, increase the value with this function call.
28
Begin
Begin forever
forever loop
loop
TRUE CTRL
CTRL
error?
error? C
Disable
Disable control
control FALSE
Disable
Disable Power
Power Switches
Switches Enable/Disable
Enable/Disable Control
Control
depending
depending on
on Motor
Motor Parameters
Parameters TRUE
Flag_Run_Identify
Flag_Run_Identify Identified?
Identified?
B
Set
Set Max
Max Speed
Speed ref.
ref. Acceleration
Acceleration
FALSE Set
Set Max
Max current
current ref.
ref. slope
slope
CTRL
CTRL state
state TRUE
Flag_MotorIdentified
Flag_MotorIdentified == TT
changed?
changed?
FALSE CTRL
CTRL state
state TRUE Get
Get Max
Max current
current ref.
ref. slope
slope
OffLine?
OffLine?
Enable
Enable Power
Power Switches
Switches
FALSE
Update
Update Global
Global Variables
Variables
CTRL TRUE
CTRL state
state EST
EST state
state locked
locked
OnLine?
OnLine? rotor?
rotor? TRUE
FALSE
FALSE
CTRL
CTRL state
state System
System Flag
Flag TRUE
TRUE
Idle?
Idle? Update
Update Offsets
Offsets Enabled?
Enabled?
Disable
Disable Power
Power Switches
Switches Enable
Enable Power
Power Switches
Switches
Flag_Run_Identify
Flag_Run_Identify == FF FALSE
FALSE
User
User Motor
Motor TRUE
Parameters
Parameters End
End forever
forever loop
loop
Used?
Used?
FALSE Correct
Correct for
for v1.6
v1.6 bug
bug
The main ISR calls very critical, time dependent functions that run the FOC and FAST observer. The new
functions that are required for this lab are listed in the Table below.
29
The code for Lab 2a is setup according to the flowchart shown in Figure 4: Forever loop flowchart. The
HAL calls from Lab 1 will be used as a starting point and are shown in red. Extra function calls are added
into the code to interface with the FAST library and are shown in green. The first step when running a
motor with InstaSPIN is to fill the library with nameplate data from the motor. The first topic that needs to
be covered before running any motor with InstaSPIN is the file “user.h”.
In proj_lab02a, open user.h from the directory in MotorWare shown the figure above.
30
Figure 5: Directory to the file user.h for PMSM (left) and ACIM Motors (right).
Halfway through the user.h file, there is a definition of motor parameters. The section of the code starts
with the name “USER MOTOR & ID SETTINGS”. To customize this file a new motor definition must be
created, for now call it “My_Motor”.
Comment out // the line that defines the current motor, which will look like the following:
For the actual motor parameters copy and paste an empty set of motor parameter definitions (see
“undefined_PM_placeholder”) and convert them as below if it is a PMSM, IPM or BLDC motor:
31
#elif (USER_MOTOR == MY_MOTOR)
#define USER_MOTOR_TYPE MOTOR_Type_Pm
#define USER_MOTOR_NUM_POLE_PAIRS (4)
#define USER_MOTOR_Rr (NULL)
#define USER_MOTOR_Rs (NULL)
#define USER_MOTOR_Ls_d (NULL)
#define USER_MOTOR_Ls_q (NULL)
#define USER_MOTOR_RATED_FLUX (NULL)
#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 (3.0)
#define USER_MOTOR_IDENT_FREQUENCY_Hz (20.0)
A few values can already be put into the user.h motor parameters.
32
USER_MOTOR_IDENT_FREQUENCY_Hz A starting point for this frequency if the motor is a
PMSM motor is 20.0 Hz, and if it is an ACIM motor, a good starting point is 5.0 Hz.
A spreadsheet was created to help setup user.h parameters based on motor parameters, control
frequencies, filter poles, etc. The spreadsheet can be found in this folder:
C:\ti\motorware\motorware_1_01_00_13\docs\labs\motorware_selecting_user_variables.xlsx
Later in the lab after the motor parameters are identified, the appropriate NULL values will be updated
with the identified values. One thing to note is that this motor is defined to be a permanent magnet motor.
The terms “Magnetizing Current” and “Rr” are not needed for a PM motor model and therefore will always
be left NULL. Also note that the inverter has already been defined. In the top half of the user.h file, there
are definitions for currents and voltages, clocks and timers, and poles. These definitions are used to
setup current, voltage scaling and filter parameters for the library.
Now, connect the motor that will be run with InstaSPIN to the kit. Insert the MCU control card. Connect
the USB cable to the control card. Finally apply power to the kit. In Code Composer, build proj_lab02a.
Start a Debug session and download the proj_lab02a.out file to the MCU.
A structure containing the variables to run this lab from the Code Composer Real-Time Watch Window
has been created by the name of “gMotorVars” and is defined in main.h. A script has been written to
easily add these variables to the watch window.
Select the scripting tool, from the debugger menu “View->Scripting Console”.
The scripting console window will appear somewhere in the debugger.
Open the script by clicking the icon that is in the upper right corner of the scripting tool.
Select the file “sw\solutions\instaspin_foc\src\proj_lab02a.js”.
The appropriate motor variables are now automatically populated into the watch window.
The variables should look like below
o Note the number format.
o For example, if “gMotorVars.Flag_enableSys” is displayed as a character, right-mouse
click on it and select “Number Format -> Decimal”
o For the “Q-Value(24)” format, after right-mouse clicking on the value select “Q-Values-
>Q-Value(24)” from the pop-up menu
33
Enable the real-time debugger. .
o A dialog box will appear, select “Yes”.
click the run button .
enable continuous refresh on the watch window. .
The controller will now start identifying the motor. Be sure not to try to stop the shaft of the motor while
identification is running or else there will be inaccurate identification results. Once the
“gMotorVars.Flag_Run_Identify” is equal to 0, and we are identifying a PMSM motor, then the motor
parameters have been identified. If we are identifying an ACIM motor, the controller and estimator states
will show the following states:
If this is the case, then lock the rotor, and enable the controller again by setting
“gMotorVars.Flag_Run_Identify” to 1. Once the “gMotorVars.Flag_Run_Identify” is equal to 0, then the
ACIM is done identifying.
34
Record the watch window values with the newly defined motor parameters in user.h as follows:
o USER_MOTOR_Rr = gMotorVars.Rr_Ohm’s value (ACIM motors only)
o USER_MOTOR_Rs = gMotorVars.Rs_Ohm’s value
o USER_MOTOR_Ls_d = gMotorVars.Lsd_H’s value
o USER_MOTOR_Ls_q = gMotorVars.Lsq_H’s value
o USER_MOTOR_RATED_FLUX = gMotorVars.Flux_VpHz’s value
o USER_MOTOR_MAGNETIZING_CURRENT = gMotorVars.MagnCurr_A’s value (ACIM
motors only)
The motor is not energized anymore. If an ACIM was identified, remove whatever instrument was used to
lock the rotor at this time. To run the motor,
The control will re-calibrate the feedback offsets and then re-measure Rs_Ohm. After the measurements
are done, the motor shaft will accelerate to the default target speed. The speed feedback is shown (in
kilo-rpm) by the variable “gMotorVars.Speed_krpm”. The target speed reference is (in kilo-rpm) set by the
variable “gMotorVars.SpeedRef_krpm”.
Set the variable “gMotorVars.SpeedRef_krpm” to a different value and watch how the motor shaft
speed will follow.
If this is an ACIM motor, you might want to experiment with PowerWarp. Once the motor is running in
closed loop, enable power Warp by setting “gMotorVars.Flag_enablePowerWarp” flag to 1. The following
oscilloscope plot shows how the current consumed by the motor goes from rated magnetizing current to a
minimum calculated by the PowerWarp algorithm.
35
36
Notice that when changing between speeds, the motor shaft speed does not change instantaneously. An
acceleration trajectory is setup between the input speed reference and the actual speed reference
commanding the input of the speed PI controller.
To change the acceleration,
Set the variable “gMotorVars.Flag_Run_Identify” to 0 to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
API functions used in the watch window during this lab are shown in the table below.
Table 10: Functions used to interface with the watch window during this lab.
updateGlobalVariables
CTRL
CTRL_setSpd_ref_krpm Sets the output speed reference value in the controller in kilo-rpm.
CTRL_setMaxAccel_pu Sets the maximum acceleration rate of the speed reference.
CTRL_getState Gets the controller state.
EST
EST_getSpeed_krpm Gets the speed value in kilo-rpm.
EST_getTorque_lbin Gets the torque value in lb-in.
EST_getRs_Ohm Gets the stator resistance value in Ohms.
EST_getLs_d_H Gets the direct stator inductance value in Henries (H)
Gets the stator inductance value in the quadrature coordinate direction in
EST_getLs_q_H
Henries (H).
The estimator continuously calculates the flux linkage between the rotor and
stator, which is the portion of the flux that produces torque. This function returns
EST_getFlux_VpHz
the flux linkage, ignoring the number of turns, between the rotor and stator coils,
in Volts per Hertz, or V/Hz.
EST_getState Gets the state of the estimator.
37
Lab 2a has demonstrated the basics of using the InstaSPIN library and running it out of ROM. A new
motor has been identified and the values were entered into the file user.h. The recorded motor
parameters will be used in the following labs to bypass motor commissioning and speed up the initial
startup of the motor.
38
Lab 2b – Using InstaSPIN out of User RAM and/or FLASH
InstaSPIN does not have to be executed completely out of ROM. Actually, most of the InstaSPIN source
code is provided. The only source code that remains in ROM is the FAST observer. This lab will show
how to run the sensorless field oriented controller in user RAM with TI provided source code. The only
function calls to ROM will be to update and to pull information from the FAST observer.
In the previous lab (lab 2a) the full InstaSPIN-FOC motor control software was executed out of ROM.
This lab will also implement the InstaSPIN motor control software but it will be done with open source
code that is executed out of user RAM. The only code that has to remain closed is the FAST observer.
A block diagram is shown below of the minimal ROM implementation of InstaSPIN-FOC. InstaSPIN-
MOTION can use the same implementation. All of the same functions that were used in lab 2a are also
used in this lab. If any functions are re-used from a previous lab, they will be highlighted in red. The new
file that is included in lab 2b’s project is “ctrl.c”. The ctrl.c file contains the same control code that is in the
ROM of the 2802xF, 2805xF/M and 2806xF/M.
39
ctrl.c
CTRL_setMaxAccel_pu CTRL_run
wref CTRL_setup
Traj
User_SpdRef Spdout Iq_ref
Ramp Speed
CTRL_setSpd_ref_krpm
PI Iq HAL_writePwmData
~
w
Iq PI
Vq Vα_out Ta
INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id
Iq PARK
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle
~
w ~ FAST™ Estimator
EST_getSpeed_krpm w Vα_in Va ADC
Speed Flux, Angle, Speed, Torque
Vb Driver
~t EST_getTorque_lbin ~t Motor Parameters ID Vβ_in CLARKE
Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
Figure 6: Block diagram of only FAST in ROM with the rest of InstaSPIN-FOC in user memory
Because most of the InstaSPIN-FOC code has moved from ROM to user memory, more files must be
added to the project as compared to lab 2a. Table 11 lists the new files in the project. Note that many of
the functions are located in the header file associated with the C-file, such as: clark.h, ipark.h, park.h,
svgen.h and traj.h.
40
Table 11: New files that must be included in the project for user's RAM.
proj_lab02b
filter_fo.c Contains code for a first order filter used for offset calibration.
offset.c Contains the offset code used to find voltage and current feedback offsets.
Y User Motor Y
Is Controller Configure Motor’s
Start Idle Parameters from Set Motor Identified
Enabled? Parameters
user.h?
N N
N Y N N
Is Motor Perform Locked
Is Estimator Idle?
Identified? Rotor Test?
Y Y
N Y
Is Controller Is Controller Locked Rotor or
Enabled? Enabled? Estimator Idle?
Y N Y
Offsets
Estimation
Complete? N
Figure 7: State diagram showing the three states, Idle, Offline, and Online, for CTRL_run.
41
Now is a good time to talk about the CTRL_run state machine shown in the figure above. There are three
states in CTRL_run: Idle, Offline, and Online. The Idle state normally happens when the controller is
shutdown. CTRL is in the Offline state during offset calibration and motor parameter identification. The
Online state happens when the control and motor are running and all identification has finished.
The most important part of the code happens during the Online state, where the function CTRL_run is
called from the mainISR(). As seen below, the CTRL and HAL handles, and the ADC and PWM data are
passed to the CTRL_run() function.
The code lines below are part of CTRL_run, all of the code for CTRL_run can be found in the file ctrl.c.
The if-then statements below show that when the motor is being identified CTRL_runOnLine is executed
from ROM. After the motor is identified, CTRL_runOnLine_User is run from user RAM.
CTRL_runOnLine_User is an inlined function that is located in ctrl.h. It contains the entire FOC
implementation with calls to the FAST observer for rotor flux angle values.
42
Executes from
user memory
Executes from
ROM memory
during Motor ID
With the file ctrl.h open and selecting Outline View within CCS (View->Outline), you can select
CTRL_runOnLine_User from the Outline window to review the code in the source window.
43
There are no new includes after lab 2a.
There are no new global object and variable declarations after lab 2a.
Nothing has changed between lab 2a and this lab for initialization and setup.
Nothing has changed from lab 2a, only now the code is run out of RAM.
44
The code for Lab 2b is setup according to the diagram as shown in the figure below. Notice that all of the
function calls are shown in red. As the code appears from main.c, there is no difference between running
the code from ROM (lab 2a) or RAM (lab 2b).
For this lab procedure, it will be good to look through the map file and see what functions are still in ROM
and the others that are run from RAM. First we must generate the MAP file by building the code.
Looking at the proj_lab02b.map file section “GLOBAL SYMBOLS: SORTED BY Symbol Address”, there
are many CTRL functions that are located in the .text section of RAM or between addresses 0x08000 –
0x010000. If the map listing file for proj_lab02a is opened, there are no CTRL symbols located in user
memory and hence are all called out of ROM. However, the map file for proj_lab02b shows the CTRL
function calls being loaded and executed in user’s memory as shown below:
To run this lab, follow the same exact procedure from lab 2a.
45
Most of the InstaSPIN code is open source. Lab 2b has demonstrated how to run FOC out of user RAM
with minimal function calls into ROM. The only part of InstaSPIN that remains in ROM is the FAST
observer and functions used during motor commissioning (identification).
InstaSPIN-MOTION provides several components in ROM, including inertia identification, the speed
controller, and the motion profile generator. These components will be covered in the upcoming labs.
46
Lab 2c – Using InstaSPIN to Identify Low Inductance PMSM
This lab implements a few additional functions compared to previous lab 2b, so that PMSM motors with
low inductance can be identified.
When identifying low inductance PMSM motors, special considerations need to be taken. These
considerations are related to how the control loops are setup, so that even with low inductance, the
control loops are stable. This lab implements and utilizes new functions to allow identification of low
inductance PMSM motors.
47
ctrl.c
CTRL_setMaxAccel_pu CTRL_run
wref CTRL_setup
Traj
User_SpdRef Spdout Iq_ref
Ramp Speed
CTRL_setSpd_ref_krpm
PI Iq HAL_writePwmData
~
w
Iq PI
Vq Vα_out Ta
INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id
Iq PARK
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle
~
w ~ FAST™ Estimator
EST_getSpeed_krpm w Vα_in Va ADC
Speed Flux, Angle, Speed, Torque
Vb Driver
~t EST_getTorque_lbin ~t Motor Parameters ID Vβ_in CLARKE
Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
Figure 8: Block diagram of only FAST in ROM with the rest of InstaSPIN-FOC in user memory
Nothing has changed in initialization and setup from the previous lab.
48
Table 12: New API function calls.
forever
loop
proj_lab2c.c
This function recalculates gains of the current control loops as well as the speed
CTRL_recalcKpKi control loop during motor identification to allow low inductance motors to
identify and run
This function calculates the correct Q format of the inductance to be identified.
CTRL_calcMax_Ls_qFmt
This is required for low inductance PMSM motors
main ISR
proj_lab2c.c
This function uses the Q format calculated in function CTRL_calcMax_Ls_qFmt
CTRL_resetLs_qFmt
when inductance identification begins
49
To build, load and run the code, follow this procedure:
After setting these two flags, the motor will start identifying, and motor parameters will be displayed in the
watch window.
When identifying low inductance motors, it is possible that the PWM frequency needs to be increased to
allow a better current control by minimizing current ripple. In general, 45 kHz should be high enough to
identify any inductance:
If the current ripple is still too high, which can be checked with a current probe and an oscilloscope,
consider increasing this frequency up to 60 kHz in 5 kHz increments.
Also, if the motor has too much cogging torque at low speeds, which is common in high speed motors,
consider increasing the frequency at which the flux and inductance is identified. This frequency is set to
20 Hz by default, but can be increased.
If the motor is not running smoothly while identifying the motor, or if the inductance coming back from the
identification process varies too much from run to run, increase this frequency in increments of 20, up to
100 Hz or so if needed.
Lastly, low inductance motors usually have low flux values also. Make sure that the full scale voltage is
set to a value that allows the flux to be identified. Consider this formula when selecting full scale voltage:
50
Lab 2d – Using InstaSPIN out of User Memory, with fpu32
This lab runs Lab 2b with floating point unit enabled. This lab only applies to 6x devices, as it has a
floating point unit.
We conclude that the libraries in ROM also work when fpu32 is enabled in 6x devices.
51
Lab 3a – Using your own motor parameters
By default, when InstaSPIN starts it first identifies the motor attached to the inverter if that motor has not
been previously identified. When identifying the motor, the parameters Rs, Ls, and air gap flux are
estimated. This lab will take the motor parameter estimates from the previous lab and place them into the
file user.h. User.h is used to hold scaling factors, motor parameters, and inverter parameters for
customizing InstaSPIN to any motor control system. The software will be modified to indicate that the
motor has been previously identified such that the identification step can be skipped.
The motor commissioning stage is very useful, but does take a long time to perform. Motor Parameters
only have to be measured once. This lab shows how to use the motor parameters previously identified in
lab 2 and then how to save those motor parameters in the file user.h.
Lab 3a adds the function call for setting the required flag to bypass motor identification. This lab also has
function calls for saving the current and voltage offsets to the user gMotorVars structure, viewable from
the Watch Window. Figure 9 shows the block diagram for running FAST with an external FOC with a
listing of the new API functions used in this lab.
52
ctrl.c
CTRL_setMaxAccel_pu CTRL_run
wref CTRL_setup
Traj
User_SpdRef Spdout Iq_ref
Ramp Speed
CTRL_setSpd_ref_krpm
PI Iq HAL_writePwmData
~
w
Iq PI
Vq Vα_out Ta
INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id
Iq PARK
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle FAST™ Estimator
~
w ~
EST_getSpeed_krpm w Flux, Angle, Speed, Torque Vα_in Va ADC
Speed
Motor Parameters ID Vb Driver
~t EST_getTorque_lbin ~t Vβ_in CLARKE
Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
Forever Loop
CTRL_setFlag_enableUserMotorParams
HAL_getBias
Figure 9: Block diagram of only FAST in ROM with the rest of InstaSPIN-FOC in user memory
Nothing has changed in initialization and setup from the previous lab.
53
Table 13: New API function calls.
forever
loop
CTRL
Sending a true in this function's parameters will cause the controller to read
CTRL_setFlag_enableUserMotorParams
motor parameters from user.h and not perform the motor commissioning.
HAL
Returns the current and voltage offsets that are inherent in the current and
HAL_getBias
voltage feedback circuits of the inverter.
Nothing has changed in this section of the code from the previous lab.
54
After verifying that user.h has been properly updated with your identified motor parameters, build lab3a,
connect to the target and load the .out file.
Add the appropriate watch window variables by calling the script “proj_lab03a.js”.
Enable the real-time debugger.
Click the run button.
Enable continuous refresh on the watch window.
The watch window should look like the figure belowMake sure that number formats are correct. For
example, the gMotorVars.I_bias array values are in Q24 format.
Before starting let’s cover what will occur in this lab and the variables to watch. After
“Flag_enableSys” and “Flag_Run_Identify” are set true, the following motor events will happen:
o Voltage and current offsets (bias) are measured
o Rs value of the motor is re-estimated
In the next procedure, once “Flag_Run_Identify” is set true, watch how the bias values are updated
and then immediately afterwards the Rs_Ohm value is re-estimated.
55
Procedure:
Make sure gMotorVars.Flag_enableUserParams is set to 1, which should be the default value for
this lab
In the Watch Window set “Flag_enableSys” to true (value of 1), and then set “Flag_Run_Identify”
to true. Note the bias values are updated and then Rs_Ohm is re-estimated. The Watch Window
will look something like the figure below.
Figure 11: The Watch Window after bias calculation and Rs re-calibration.
Next copy and paste the I_bias and V_bias values from the Watch Window into the
corresponding #define statements in the file user.h, as shown below.
56
//! \brief ADC current offsets for A, B, and C phases
Verify that the drive is functioning by changing the “gMotorVars.SpeedRef_krpm” value and
making sure the motor is spinning smoothly.
If this is an ACIM motor, you might want to experiment with PowerWarp. Once the motor is
running in closed loop, enable power Warp by setting “gMotorVars.Flag_enablePowerWarp” flag
to 1. The following oscilloscope plot shows how the current consumed by the motor goes from
rated magnetizing current to a minimum calculated by the PowerWarp algorithm.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
57
This lab showed how to bypass the motor identification process and load motor parameters from user.h.
The inverter current and voltage offsets were measured, read, and copied into user.h for use in the next
lab where a complete customization of the InstaSPIN software is done to work with the inverter and
completely eliminate any calibration before motor startup.
58
Lab 3b – Using your own Board Parameters: Current and
Voltage Offsets (user.h)
Skipping auto-calibration and using your own current and voltage offsets continues to reduce the start-up
time. If the board offsets are known, then auto-calibration at start-up is not needed. Also introduced is
the option to bypass the Rs Fine Re-estimation.
At the very beginning immediately after InstaSPIN is enabled, an offset calibration takes place. The
offsets for the current and voltage feedback circuits are measured and recorded. These offsets are
subtracted from the ADC measurements during motor operation. During normal operation of the motor
and drive, these offsets do not change much. In this lab, the offsets that were measured in lab 3a are
stored in the user.h file, further reducing the amount of time needed before starting the motor.
Write current and voltage offsets to the HAL object to reduce calibration time before motor
startup.
Bypass Rs fine re-estimation (also known as Rs recalibration) which also reduces calibration time
before motor startup.
Lab 3b adds function calls for using the current and voltage offsets that are recorded in the file user.h. It
is also shown how to bypass Rs re-calibration. Figure 12 shows where the new additions have been
added in the code.
During the initialization, the offset values for current and voltage from the file user.h are used to initialize
the HAL object. Then the controller is configured to bypass offset calibration. The bias values are stored
into the HAL object in the location hal.adcBias.I.value[0 – 2] and hal.adcBias.V.value[0 – 2]. Note that the
bias values are not part of ROM and are therefore inside of user memory.
59
Table 14: New API function calls during initialization.
Initialization
CTRL
Sending a false in this function's parameters will cause the controller to bypass
CTRL_setFlag_enableOffset
the offset calibration.
HAL
Manually set the current and voltage offset values that are inherent in the current
HAL_setBias
and voltage feedback circuits of the inverter.
ctrl.c
CTRL_setMaxAccel_pu EST_setFlag_enableRsRecalc CTRL_run
wref CTRL_setFlag_enableOffset CTRL_setup
Traj
User_SpdRef Spdout Iq_ref
Ramp Speed
CTRL_setSpd_ref_krpm
PI Iq HAL_writePwmData
~
w
Iq PI
Vq Vα_out Ta
INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id
Iq PARK
HAL_setBias
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle
~
w ~ FAST™ Estimator
EST_getSpeed_krpm w Vα_in Va ADC
Speed Flux, Angle, Speed, Torque
Vb Driver
~t EST_getTorque_lbin ~t Motor Parameters ID Vβ_in CLARKE
Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
EST_setFlag_enableRsRecalc HAL_setBias
CTRL_setFlag_enableOffset
Figure 12: Block diagram of only FAST in ROM with the rest of InstaSPIN-FOC in user memory
Inside of the forever loop, the Rs re-calibration is disabled. The global variable
gMotorVars.Flag_enableRsRecalc is used as a Boolean parameter into the function
EST_setFlag_enableRsRecalc(), as see in the code below. This allows the user in real time, to turn Rs
Recalc back on from the Watch Window.
60
EST_setFlag_enableRsRecalc(obj-
>estHandle,gMotorVars.Flag_enableRsRecalc);
During initialization, this flag is set to FALSE by default to with the following code:
Table 15: New API function calls during the main run-time loop.
Forever Loop
CTRL
Sending a false in this function's parameters will cause the controller to bypass
CTRL_setFlag_enableRsRecalc
the Rs calibration.
Nothing has changed in this section of the code from the previous lab.
61
After verifying that user.h has been properly updated with your inverter’s voltage and current offsets, build
lab3b, connect to the target and load the .out file.
Add the appropriate watch window variables by calling the script “proj_lab03b.js”.
Enable the real-time debugger.
Click the run button.
Enable continuous refresh on the watch window.
The bias values in the watch window should be zero before the motor is run. To see where the actual
bias values are contained in the working code, add the “hal” object to the watch window and expand as
shown in the figure below.
62
Set “Flag_enableSys” to true and then set “Flag_Run_Identify” to true. Watch how the bias
values for the HAL object are updated and should be the same as the offset values that are in
user.h, as shown below. The watch window will look something like the figure below.
The motor responds to speed reference changes the same as in previous labs
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
63
Figure 14: The watch window after bias calculation and Rs re-calibration.
64
This lab showed how to read in your own inverter’s offset values for voltage and current. Before the
motor starts spinning, offset voltage calibration and Rs recalibration take time. If these values are
previously measured, they can be stored and read into the control allowing us to bypass the time it takes
to measure these values.
65
Lab 3c – Using your own Board Parameters: Current and
Voltage Offsets, with fpu32
This lab runs Lab 3b with floating point unit enabled. This lab only applies to 6x devices, as it has a
floating point unit.
Bypassing motor identification and using motor parameters from user.h, with fpu32 enabled.
We conclude that the libraries in ROM also work when fpu32 is enabled in 6x devices.
66
Lab 4 – Current Loop Control (Create a Torque Controller)
The speed loop is disabled and a reference is sent directly to the Iq current controller.
This lab will explore using the InstaSPIN-FOC and InstaSPIN-MOTION framework purely as a torque
controller by removing the speed loop.
“User external speed control mode” disables the provided Speed controller and sets the FOC control
system to expect an Iq torque command as an input. This torque command input can be provided by the
user or can be the output from a user provided speed controller (which will be demonstrated in future
labs).
FOC at its core is a torque controller. We just often see it wrapped inside of a speed or position loop. By
adding extra control loops there is more of a chance to generate instability. So it is in Torque mode
where the FAST algorithm and its estimation and angle tracking capabilities should truly be judged. You
can have a perfect torque controller, but if your speed loop is commanding an under-damped, oscillating
torque reference signal the overall performance of the system will still be quite poor. The speed
controlled system also masks the true performance of the FAST FOC system. By adding a speed
controller, the total response of the FAST FOC system is reduced.
67
During the initialization, a function is called to disable the speed PI and the SpinTAC™ speed controller.
The figure below lists the function and its description used to disable the speed control and then allow the
Iq reference to be sent directly to the Iq PI controller.
Id
Iq PARK
HAL_setBias
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle
~
w ~ FAST™ Estimator
EST_getSpeed_krpm w Vα_in Va ADC
Speed Flux, Angle, Speed, Torque
Vb Driver
~t EST_getTorque_lbin ~t Motor Parameters ID Vβ_in CLARKE
Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
CTRL_setIq_ref_pu CTRL_setFlag_enableSpeedCtrl
Figure 15: Block diagram of only FAST in ROM with the rest of InstaSPIN-FOC in user memory
68
Inside of the forever loop, the Iq reference is converted from a user input of amps (gMotorVars.IqRef_A)
to per unit with the following code.
_iq iq_ref =
_IQmpy(gMotorVars.IqRef_A,_IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A));
To set the Iq reference in the FOC control, the function CTRL_setIq_ref_pu() passes the Iq reference to
the non-inverting input of the Iq current PI controller with the following code.
// Set the Iq reference that use to come out of the PI speed control
CTRL_setIq_ref_pu(handle, iq_ref);
One other task needs to be completed while doing torque control. When motoring, the controller needs to
know the direction that the motor will be applying torque. The function CTRL_setSpd_ref_krpm() function
is used to set whether the motor starts in the clock-wise or counter-clockwise direction. When using the
CTRL_setSpd_ref_krpm() function in torque control mode, the magnitude of the speed parameter does
not matter only the sign.
// set the speed reference so that the forced angle rotates in the correct
direction
// for startup.
if(_IQabs(gMotorVars.Speed_krpm) < _IQ(0.01))
{
if(iq_ref < 0)
CTRL_setSpd_ref_krpm(handle,_IQ(-0.01));
else if(iq_ref > 0)
CTRL_setSpd_ref_krpm(handle,_IQ(0.01));
Another point to look out for is during the zero-speed crossing. The sign for the speed reference must not
be in the incorrect direction until the actual speed is zero. To emphasize this, the flowchart in Figure 20
shows what is going on in the software. As you can see, the software sets the direction for the speed
reference when speed is reduced to under 10 RPM, using the Iqref sign to set direction.
69
Set sign direction
|speed| Yes
<
10rpm
Iqref Yes
<
0
End
Figure 16: Flowchart describing how to test for the speed direction before setting the speed sign.
The following table lists the new functions in the main loop that are needed to implement the torque
controller.
Table 17: New API function calls during the main run-time loop.
Forever Loop
CTRL
Take the Iq current reference as a parameter and set the input of the Iq PI current
CTRL_setIq_ref_pu
controller.
Nothing has changed in this section of the code from the previous lab.
70
Build lab4, connect to the target and load the .out file.
Add the appropriate watch window variables by calling the script “proj_lab04.js”.
Enable the real-time debugger.
Click the run button.
Enable continuous refresh on the watch window.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
71
Many applications will require only a torque controller. InstaSPIN can easily covert a motor controller to
either control speed or torque. In this lab the motor controller was converted into a torque controller.
With the FOC system, the Iq reference directly relates to torque.
72
Lab 4a – Current Loop Control (Create a Torque Controller),
with fpu32
This lab runs Lab 4 with floating point unit enabled. This lab only applies to 6x devices, as it has a floating
point unit.
We conclude that the libraries in ROM also work when fpu32 is enabled in 6x devices.
73
Lab 5a – Tuning the FAST Current Loop
A technique of setting the proportional gain (Kp) and integral gain (Ki) for the current controller of the FOC
system is explored in this lab. After the Kp and Ki gains are calculated, we will then learn how to program
InstaSPIN with these values.
This lab explains one theory on how to tune PI current gains when controlling an electric motor.
A popular form of the PI controller (and the one used for this analysis) is the “series” topology which is
shown below.
74
From this diagram, we can see that:
Where and are the parallel PI controller proportional and integral gains respectively. In the series
structure, sets the gain for ALL frequencies, and directly defines the inflection point (zero)
of the controller in rad/sec. It’s pretty easy to understand the effect that has on the controller’s
performance, since it is simply a gain term in the open-loop transfer function. But what is the system
significance of the zero inflection point?
It is common knowledge that the gain of the PI controller has a pronounced effect on system stability. But
it turns out that the inflection point in the graph (the “zero” frequency) also plays a significant but perhaps
more subtle role in the performance of the system. To understand this, we will need to derive the transfer
function for the PI controller, and understand how the controller’s “zero” plays a role in the overall system
response.
Using the series form of the PI controller, we can define its “s-domain” transfer function from the error
signal to the controller output as:
s
K pseries K iseries 1 series
K series
K series
Ki
PI s
Equation 1
K pseries
p i
s s
From this expression, we can clearly see the pole at s = 0, as well as the zero at s = (rad/sec). So,
why is the value of this zero so important? To answer this question, let’s drop the PI controller into the
heart of a current mode controller, which is controlling a motor, as shown below.
75
Figure 18: PI current controlled motor system including the stator.
We will use a first-order approximation of the motor winding to be a simple series circuit containing a
resistor, an inductor, and a back-EMF voltage source. Assuming that the back-EMF voltage is a constant
for now (since it usually changes slowly with respect to the current), we can define the small-signal
transfer function from motor voltage to motor current as:
I s 1
R
V s 1 RL s Equation 2
If we also assume that the bus voltage and PWM gain scaling are included in the term, we can
now define the “loop gain” as the product of the PI controller transfer function and the V-to-I transfer
function of the RL circuit :
series series s
K p K i 1 series
I s
Ki
1
Gloop ( s) PI s
R
V s s 1 L
R s
Equation 3
To find the total system response (closed-loop gain), we must use the equation below:
Gloop s
Gs (assuming the feedback term H(s) = 1)
1 Gloop s Equation 4
76
series series s
K p K i 1 series
Ki
1
R
s 1 R s
L
G s
series series Equation 5
K p K i 1 seriess
Ki
1
1
R
s 1 R s
L
s
1 series
G s Ki
Equation 6
1
series L series s 2 series R series series s 1
K K
p Ki p Ki Ki
The denominator is a second order expression in “s” which means there are two poles in the transfer
function. If we are not careful with how we select and , we can easily end up with complex
poles. Depending on how close those complex poles are to the jw axis, the motor control system could
have some really large resonant peaks. So let’s assume right away that we want to select Ka and
in such a way as to avoid complex poles. In other words, can we factor the denominator into an
expression like Equation 7.
2 1
s 1 1 Cs 1 Ds
L s R
K series K series K series K series K series Equation 7
p i p i i
where C and D are real numbers.
If we multiply out the expression on the right side of the equation, and compare the results with the left
side of the equation, we see that in order to obtain real poles, the following conditions must be satisfied:
L
CD
K series
p K iseries Equation 8
and,
R 1
series C D
K pseries K iseries Ki Equation 9
As a first attempt to solve Equation 8 and Equation 9, simply equate the terms on both sides of Equation
9. In other words,
77
R 1
C , and D
K series
p Kiseries
Kiseries Equation 10
The reasoning for these substitutions will become clear later. If we replace the denominator of Equation 6
with its factored equivalent expression as shown in Equation 7, and then make the substitutions
recommended in Equation 10, we get the following:
s
1 series
G s Ki
Equation 11
s
1 seriesR series s 1 series
K p Ki
Ki
It turns out that the “D” substitution results in a pole which cancels out the zero in the closed-loop gain
expression! By choosing C and D correctly, we not only end up with real poles, but we can create a
closed-loop system response that has only ONE real pole and NO zeros! No peaky frequency responses
or resonant conditions! Just a beautiful single-pole low-pass roll off response!
But wait…there’s more! By substituting the expressions for C and D recommended in Equation 10 back
into Equation 8, we get the following equality:
R
K iseries Equation 12
L
Recall that is the frequency at which the controller zero occurs. So in order to get the response
described in Equation 11, all we have to do is to set (the controller zero frequency) to be equal to
the pole of the plant!
So, now we know how to set . But what about ? Let’s rewrite the closed-loop system
response G(s), making all of the substitutions we have discussed up to now, and see what we get:
Gs
1
K pseries L Bandwidth
L
series
s 1 Equation 13
K p
In summary, there are some simple rules we can use to help design a PI controller for the motor’s current
loop:
sets the zero of the PI controller. When controlling a plant parameter with only one real pole in its
transfer function (e.g., the current in a motor), should be set to the value of this pole. Doing so will
result in pole/zero cancellation, and create a closed-loop response that also only has a single real pole.
In other words, very stable response with no resonant peaking.
sets the BANDWIDTH of the closed-loop system response. As seen by Equation 13, the higher
is, the higher the current loop bandwidth will be. To further extrapolate, the current controller is
best determined by the time constant of the motor system. In the lab following this one, the speed control
PI loop is analyzed. By combining the Speed and current controller design, a very stable cascaded
78
control loop can be created. Since the speed control loop hasn’t been designed yet, this lab will only take
into consideration the sampling time and see how large the can be adjusted before the bandwidth
is too high.
79
CTRL_setSpd_ref_krpm CTRL_setFlag_enableSpeedCtrl ctrl.c
CTRL_setFlag_enableRsRecalc CTRL_run
+ is positive torque CTRL_getK*
wref CTRL_setFlag_enableOffset CTRL_setup
- is negative torque CTRL_setK*
Traj
User_SpdRef Spdout Iq_ref
Ramp Speed
PI Iq HAL_writePwmData
~
w
Iq PI
CTRL_setIq_ref_pu Vq Vα_out Ta
User_IqRef INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id
Iq PARK
HAL_setBias
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle FAST™
~
w ~
EST_getSpeed_krpm w Software Encoder Vα_in Va ADC
Speed
Rotor Flux Observer Vb Driver
~t EST_getTorque_lbin ~t Vβ_in CLARKE
Motor Parameters ID Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
Forever Loop
CTRL_getKp
CTRL_getKi
CTRL_setKp
CTRL_setKi
During motor identification or even when motor parameters from user.h are used, the gain is
calculated based on the motor R/L pole. The bandwidth of the control or is set to not be too high
and cause instability in the current control loop. Immediately after motor identification has finished, the
and gains for the current controller are calculated in the function calcPIgains(). After
calcPIgains() is called, the global variables gMotorVars.Kp_Idq and gMotorVars.Ki_Idq are initialized with
the newly calculated and gains. The following figure shows the logic flowchart needed to
implement the current controller gain initialization.
80
Table 18: New API function calls during the main run-time loop.
Forever Loop
CTRL
CTRL_getKp Get the Kp gain from the CTRL object.
CTRL_getKi Get the Ki gain from the CTRL object.
CTRL_setKp Set the Kp gain in the CTRL object.
CTRL_setKi Set the Ki gain in the CTRL object.
Initialize Kp and Ki
Is Motor Yes
Identified?
Flag_Latch_Software_Update Yes
==
TRUE
Flag_Latch_Software_Update
=
FALSE
Flag_Latch_Software_Update
=
TRUE
calcPIgains()
gMotorVars.Kp_Idq = CTRL_getKp()
gMotorVars.Ki_Idq = CTRL_getKi()
End
Figure 20: Flowchart showing how the watch window and variables are initialized.
Nothing has changed in this section of the code from the previous lab.
81
Build lab5a, connect to the target and load the .out file.
Add the appropriate watch window variables by calling the script “proj_lab05a.js”.
Enable the real-time debugger.
Click the run button.
Enable continuous refresh on the watch window.
Where:
Calculate the =( ⁄ ) .
Compare values
Compare your calculated from the that is initially stored in “gMotorVars.Ki_Idq”.
The two values should be the same.
82
o Use a bandwidth that is 1/20 of the current controller frequency. Keep in mind that the
bandwidth needed to calculate the controller gains is in radians per second, and the
controller frequency is in Hz, so the following conversion is used:
o Example: ,
o ⁄
o has to be per unitized to
o ⁄
found in “user.h”
found in “user.h”
As the bandwidth gets wider, the sampling delay has more of a negative effect on the phase margin of the
controller and causes the control loop to become unstable. Figure 21 is a plot of the motor current
waveform with a stable setting. As the is increased, the phase margin of the control loop
becomes smaller. After a while the control loop is unstable and starts to oscillate as shown in Figure 22.
The current controller gain should not be set to this high of a value. When a current loop instability
occurs, lower the gain until the current waveform is like the one in the following figure.
Figure 21: setting that has been calculated at 1/20 of the bandwidth.
83
Figure 22: setting that is too high resulting in the controller becoming unstable.
It is important to notice that by default, in the ROM code, the current controller gains are set to the
following values:
Although it is consider a full bandwidth when it is equal to the same frequency of the current controller as
follows:
84
and gains of the current controller were adjusted. The gain creates a zero that
cancels the pole of the motor’s stator and can easily be calculated. The gain adjusts the
bandwidth of the current controller-motor system. When a speed controlled system is needed for a
certain damping, the gain of the current controller will relate to the time constant of the speed
controlled system and it is best to wait until more knowledge of the mechanical system is attained before
calculating the current controller’s .
85
Lab 5b – Tuning the FAST Speed Loop
InstaSPIN-FOC provides a standard PI speed controller. The InstaSPIN library will give a “rule of thumb”
estimation of Kp and Ki for the speed controller based on the maximum current setting in user.h. The
estimated PI controller gains are a good starting point but to obtain better dynamic performance the Kp
and Ki terms need be tuned based on the whole mechanical system that the motor is running. This lab
will show how to adjust the Kp and Ki terms in the PI speed controller.
The InstaSPIN-MOTION disturbance-rejecting speed controller replaces the standard PI controller. The
InstaSPIN-MOTION controller offers several ease of use and performance advantages: 1) it proactively
estimates and compensates for system errors; 2) the controller offers single-parameter tuning that
typically works over the entire operating range. If you would like to use the InstaSPIN-MOTION controller,
you may skip Lab 5b and proceed to Lab 5c.
Tuning the speed controller is much more difficult than tuning the current controller. The speed controller
resides in the mechanical domain which has much slower time constants where phase delays can be
tighter, playing more of an effect on stability of the system. The most important parameter needed for
accurately tuning a speed controlled system is inertia. That being said two different approaches for
tuning the speed loop are covered here. The first technique uses trial and error and can be used if no
parameters of the mechanical system are known. The second technique assumes that inertia and
mechanical bandwidth are already known, then it designs the current control and speed control gains.
Objectives Learned
Tune the speed controller quickly using a trial and error technique.
Tune the speed controller with the knowledge of inertia and mechanical bandwidth.
Background
Many times when trying to tune an electric motor, the inertia is not immediately available. InstaSPIN
provides the capability to use a very simple but effective technique to quickly tune the PI speed control
loop without knowledge of any mechanical parameters. For this next discussion, InstaSpin uses the
“parallel” PI controller for the speed control loop which is illustrated in the figure above.
86
Figure 23: Parallel PI control.
Assume that the stator time constant is much quicker than the mechanical system. To simplify the
analysis, the current controller is represented as a constant gain below.
Figure 24: Speed control model used to show similarity between a mass, spring, damped system.
K
1 p s
Gloop ( s ) PI s K curr Mech ( s ) K i
Ki K K
s curr s
Equation 14
K K curr K i K p
Gloop ( s ) 1 s
s2 K i
87
The gain contains the electric motor’s voltage constant and inertia. The closed loop transfer function
now becomes:
Kp
KK curr K i 1 s
K i Equation 15
Gloop ( s ) 2
s KK curr K p s KK curr K i
The free-body diagram for a mass, spring, damper system is shown in Figure 25. The transfer function
for the mechanical system is:
1
Tmech ( s ) J Equation 16
b k
s 2 s sp
J J
Comparing like terms of the denominators between Equation 15 and Equation 16 we find the following
relationships between PI gains and the mechanical system.
Kp b
Equation 17
K i k sp
88
Equation 17 states that increasing has the similar effect on the motor controlled system as increasing a
spring constant. Or in other words it stiffens the system by strengthening the spring. The dampening of
the system is controlled by the gain. For example, if the gain is set real low, will take over and
the motor control system will act like a spring. When a step load is applied to the system, it will oscillate.
Increasing the damping ( ) will reduce the oscillations.
Figure 26: Speed controller cascaded with a current controller and speed filter.
Notice that in our system, the speed feedback signal is filtered. Unless you have an analog tachometer
mounted to your motor shaft, you are probably synthesizing the speed signal by measuring other system
parameters. Even if you are using an incremental encoder on the motor shaft, you will need to synthesize
velocity by measuring position. For this reason, the speed signal often needs to be filtered before it is
usable by the control system. For our purposes, let’s just assume that we are using a single-pole low
pass filter of the form
Where is the time constant of the velocity filter low pass filter (green block from above diagram).
Gcurrent s
1
L
s 1
Equation 18
K pseries
Where is the error multiplier term in the current regulator’s PI structure.
is not visible to the outside world since it is set to cause pole/zero cancellation within the current
controller’s transfer function. To avoid confusing the coefficients of the speed controller with those of the
current controller, we will call the speed controller’s coefficients and as shown in
89
Figure 26. In the series form of the PI controller, is the error multiplier term (
), and is the integrator multiplier term ( ). The equation that was used
for the current controller can also be used to describe the speed control:
s
spdK pseries spdKiseries 1
series Equation
spdK series
spdK series
spdK
PI speed s spdK 19
p i series i
p
s s
The transfer function from motor current to motor torque will vary as a function of what type of motor is
being used. For a Permanent Magnet Synchronous Motor under Field Oriented Control, the transfer
function between q-axis current and motor torque is:
Mtr s
3P 3
r Pr Equation 20
22 4
Where:
P = the number of rotor poles
r = the rotor flux (which is also equal to the back-EMF constant (Ke) in SI units)
For an AC Induction machine, the transfer function between q-axis current and motor torque would be:
3 Lm2
Mtr s P Id Equation 21
4 Lr
Where:
P = the number of stator poles
Lm = the magnetizing inductance
Lr = the rotor inductance
Id = the component of current that is lined up with the rotor flux
For now, let’s assume we are using a Permanent Magnet Synchronous Motor.
Finally, the load transfer function from motor torque to load speed is:
Load s
11
Equation 22
Js
Where:
J = the inertia of the motor plus the load
Multiplying all these terms together results in the composite open-loop transfer function:
90
( )
( )( )( )
Equation 23
( )
( )
Let’s combine all the motor and load parameters at the end of this equation into a single constant K:
3Pr
K Equation 24
4J
Simplifying, we get:
( )
Equation 25
( )
Assuming that the zero dB frequency occurs somewhere between the zero at and the two
nonzero poles in the denominator of the expression, we should end up with a Bode plot that looks
something like this:
91
The reason the shape of this curve is so important is because the phase shift at the 0 dB frequency
determines the stability of the system. In general, in order to get a phase shift at 0 dB that leads to good
stability, the magnitude response should cross 0 dB at a rate no steeper than -20 dB per decade.
As you can see from equation 25, we must solve for three unknowns ( , , and )
which are affected by multiple system parameters. But instead of wading through pages and pages of
esoteric equations, it’s time to make another simplification. Let’s assume that there is only one pole
higher than the zero-dB frequency instead of two. This assumption could mean that you don’t have a
velocity filter in your system, OR that the velocity filter’s pole is way higher than the current controller’s
pole, OR that the current controller’s pole is way higher than the velocity filter’s pole. For most systems, it
is plausible to assume the latter scenario. So if we eliminate the effect of the current controller pole, we
can rewrite the velocity open-loop transfer function as shown below:
( )
For now, let’s assume that the delta in frequency between the pole and the zero is
fixed. In order to achieve maximum phase margin (phase shift +180), the unity gain frequency should
occur exactly half way in-between these two frequencies on a logarithmic scale. Translating from dB to a
normal gain scale, this means the following is true:
And
Solving for
92
Where δ we will define as the "damping factor." If δ is increased, it forces the zero corner frequency
( ) and the velocity filter pole ( τ) to be further apart. And the further apart they are, the phase
margin is allowed to peak to a higher value in-between these frequencies. This improves stability but
unfortunately reduces system bandwidth. If δ = 1, then the zero corner frequency and the velocity filter
pole are right on top of each other, resulting in pole/zero cancellation. In this case the system will be
unstable. Theoretically, any value of δ > 1 is stable since phase margin > 0. However, values of δ close
to 1 are usually not practical as they result in severely underdamped performance.
We will talk more about δ later, but for now, let’s turn our attention towards finding the last remaining
coefficient: . From this equation: we see that the open-
loop transfer function of the speed loop will be unity gain (0 dB) at a frequency equal to the zero inflection
point frequency multiplied by . In other words,
s
K spdK pseries spdKiseries 1
series
spdK i 1 Equation 26
s
s 2 1 2
series
spdK i s j spdKseries
i
By performing the indicated substitution for “s” in Equation 26 and solving, we obtain:
Equation 27
spdKiseries 1
spdK series
Equation 28
K t
p
K
At this point, let’s step back and try to see the forest for the trees. We have just designed a cascaded
speed controller for a motor which contains two separate PI controllers: one for the inner current loop and
one for the outer speed loop. In order to get pole/zero cancellation in the current loop, we chose
as follows:
R
K iseries Equation 29
L
93
Equation 30
Where is the bandwidth of the current controller.
Next, we select a value for the damping factor ( ) which allows us to precisely quantify the tradeoff
between velocity loop stability and bandwidth. Then it’s a simple matter to calculate and
1
spdKiseries Equation 31
2 t
spdKiseries
Equation 32
1
spdK series
K t
p
K
The benefit of this approach is that instead of trying to empirically tune four PI coefficients which have
seemingly little correlation to system performance, you just need to define two meaningful system
parameters: the bandwidth of the current controller and the damping coefficient of the speed loop. Once
these are selected, the four PI coefficients are calculated automatically.
The current controller bandwidth is certainly a meaningful system parameter, but in speed controlled
systems, it is usually the bandwidth of the speed controller that we would like to specify first, and then set
the current controller bandwidth based on that. In the next section, let’s take a closer look at the damping
factor, and we will come up with a way to set the current loop bandwidth based on the desired speed loop
bandwidth.
So far we have discussed how to distill the design of a cascaded speed controller from four PI coefficients
down to two “system” parameters. One of those parameters is simply the bandwidth of the current
controller. The other is the damping factor ( ). The damping factor represents the tradeoff between
system stability and system bandwidth in a single parameter. But how do you choose an appropriate
damping factor value for your design, and what does it mean in terms of your system’s transient
response?
To help answer these questions, let’s take a look at figure 28, which illustrates the open-loop magnitude
and phase response for a speed control system. Note that all frequencies are scaled to the value of the
velocity filter pole. Assuming that the current controller's pole is very high with respect to this pole, the
shape of the curves won’t change, regardless of the velocity pole value. In Figure 28, the damping factor
is swept from 70 to 1.5 in 8 discrete steps to show how it affects system response. A value of 1.0
corresponds to the condition where the open-loop magnitude response has unity gain at the same
frequency as the velocity filter's pole. This scenario results in the velocity filter pole exactly cancelling out
the zero which is creating all that nice phase lead we need to stabilize our system. So we see that a
value of 1.0 yields a system with zero phase margin, which of course is unstable.
94
Figure 28: Open loop gain and phase margin for various values.
One of the goals of the damping factor is to achieve maximum stability for a given bandwidth. This is
confirmed in the plots above, which show that the phase margin always peaks to its maximum value at
the unity gain frequency. As the damping factor is increased, you eventually reach a point of diminishing
returns for phase margin improvement as the signal phase shift approaches -90 degrees. However, the
gain margin continues to improve as the damping factor is increased.
Figure 29 illustrates the closed-loop magnitude response of the velocity loop with respect to the velocity
filter pole as d is swept from 70 to 1.5.
95
Figure 29: Closed loop magnitude response of the speed loop for various
From figure 29 you can see how decreasing the damping factor increases the bandwidth of the velocity
loop. In fact, decreasing the damping factor from 70 to 1.5 increases the bandwidth by almost two orders
of magnitude. But as the damping factor approaches unity, the complex poles in the velocity loop
approach the axis, resulting in pronounced peaking of the gain response. This peaking effect is
usually undesirable, as it results in excessive underdamped ringing of the step response. You can better
see this in figure 30, which shows the normalized step response of the system for various values of
damping factor. Values below 2 are usually unacceptable due to the large amount of overshoot they
produce. At the other end of the scale, values much above 35 produce extremely long rise and settling
times. Your design target window will usually be somewhere in-between these two values.
96
Figure 30: Step response of the closed loop system for various
What happens if you pick a damping factor based on a desired shape for your step response, but the
response time is too long? Well, assuming you have the design flexibility to do so, your best recourse
might be to increase the velocity filter pole. In figures 28 and 29, all frequencies are scaled to this pole
value, which means that if you change it, all other frequencies will change proportionally. So if you
double the value of the velocity filter pole in figures 28 and 29, you will half the time axis in figure 30.
But what if you don’t have this flexibility? Unfortunately, you will be forced to choose between response
time and overshoot. In other words, you can solve one problem or the other, but not both at the same
time.
So far we have discussed how to set three of the four PI coefficients in a velocity control loop. But there
is still one left… . Recall that sets the bandwidth of the current controller. In many respects,
is the hardest one to set since its effect on system performance is more subjective than the other
three.
We saw that is used for pole-zero cancellation within the current loop. and
are indexed to the velocity feedback filter’s time constant, and are calculated by first selecting a suitable
damping factor which is related to the responsiveness and damping of the system. We also saw that
sets the current controller’s bandwidth. But what should that bandwidth be?
97
It turns out that we have two competing effects vying for control of where we set . On the bottom
end of the frequency range, we have the velocity feedback filter pole with some really nice tan lines that
wants to push the current controller pole to higher frequencies so as to not interfere with our nice tuning
procedure. But we can only go so high before we start running into other problems. Let’s take a look at
both ends of the frequency spectrum in an effort to understand these issues, and hopefully gain some
insight into how to judiciously set . But first, let’s rewrite the open-loop transfer function of the
velocity loop to once again include the current controller’s transfer function:
( )
( )
Our tuning procedure assumes that the current controller’s closed-loop gain is always unity, which implies
it has infinite bandwidth. But in reality, as long as the current controller’s bandwidth is at least 10x higher
than the velocity loop unity gain frequency, our tuning procedure is still pretty good at predicting the
system response. If this condition isn’t satisfied, the current controller pole starts interfering with the
velocity loop phase margin, resulting in a more underdamped response than our tuning procedure would
otherwise indicate.
Figure 31 shows an example case to illustrate this point. The green curve represents what the tuning
procedure predicts the normalized step response should be for a system with a damping factor of
2.5. The red curve shows what happens when the current controller’s bandwidth is reduced to equal the
velocity filter’s bandwidth. The system is still stable, but the damping is much less than predicted from
our tuning procedure. At this point, we have two options…either increase the damping factor (and
consequently lower the frequency response of the velocity loop), or increase the current loop bandwidth
by increasing . The cyan curve shows the first option where we increase the damping factor just
enough to bring the overshoot down to the predicted value. Unfortunately this increases the step
response transient time as well. The yellow curve shows the latter option where we put the damping
factor back to 2.5, and increase the current controller’s pole to be 10x higher than the velocity loop unity
gain frequency. As you can see, the actual response more closely resembles the predicted value. The
higher the current controller’s bandwidth is, the closer the response will resemble the predicted response.
98
Figure 31: Step response of the closed loop system for various
So from this exercise, we might conclude that the best strategy is to set the current controller bandwidth
to be as high as possible. But is this really the best course of action? Usually high bandwidth in any
system results in unruly and obnoxious behavior, and should only be used if absolutely necessary. In this
case, high current loop bandwidth often results in undue stress on your motor, since high frequency
current transients and noise translate into high frequency torque transients and noise. This can even
manifest itself as audible noise! But there is also another limit on your current loop bandwidth: the
sampling frequency.
Take a look at Figure 32 which shows a digital Field Oriented Control (FOC) based Variable Frequency
Drive (VFD). To simplify the discussion, we will assume that the entire control loop is clocked by a
common sampling signal, although in real-world applications we often choose to sample the velocity loop
at a much lower frequency than the current loop to save processor bandwidth.
99
Figure 32: Digital FOC system for a PMSM
In an analog system, any change in the motor feedback signals immediately starts having an effect on the
output control voltages. But with the digital control system of Figure 32, the motor signals are sampled
via the ADC at the beginning of the PWM cycle, the control calculations are performed, and the resulting
control voltages are deposited into double-buffered PWM registers. These values sit unused in the PWM
registers until they are clocked to the PWM output at the start of the next PWM cycle. From a system
modeling perspective, this looks like a sample-and-hold function with a sampling frequency equal to the
PWM update rate frequency. The fixed time delay from the sample-and-hold shows up as a lagging
phase angle which gets progressively worse at higher frequencies. Figure 33 shows a normalized
frequency plot of the phase delay for a sample-and-hold function, where the sampling frequency is
assumed to be 1. As you can see, the phase delay reaches down into frequencies much lower than the
sampling frequency. For example, at one decade below the sampling frequency, the S&H is still affecting
a phase shift of -18 degrees.
100
Figure 333: Phase lag plot for a sample and hold, Fs = 1
Since the current controller processes higher bandwidth signals than the velocity loop, it is usually the
current loop that suffers most by the S&H effect of the PWM module. Since the PWM S&H is in series
with the signal path for the current loop, its magnitude and phase contributions add directly to the open-
loop response for the current controller. If we rewrite the equation for the open-loop response of the
current controller (assuming ), we end up with the following function:
( )( )
This is simply an integrator function with gain of . Unity gain will obviously occur when
. The single pole at implies that the unity gain frequency will have a 90 degree phase shift,
which also implies a 90 degree phase margin. However, for a digital control system, you must add the
phase lag shown in Figure 33. To do this, calculate for the following frequency ratio:
Then use Figure 33 to determine how much phase lag you must subtract off of your phase margin. For
example, if , then you must subtract off 18 degrees from your phase margin, leaving
you with a comfortable 72 degrees. In most designs you probably want to keep at least an order
of magnitude below the sampling frequency. So using this assumption as well as the constraints from the
101
velocity loop tuning procedure, we can now write a general “rule of thumb” expression for the range of
:
In most designs this still leaves a fairly broad range for the value of .
EXAMPLE
An Anaheim Automation 24V permanent magnet synchronous motor has the following characteristics:
Rs = 0.4 ohms
Ls = 0.65 mH
Back-EMF = 0.0054 v-sec/radians (peak voltage phase to neutral, which also equals flux in Webers in the
SI system)
Inertia = 2E-4 kg-m2
Rotor poles = 8
Speed filter pole = 100 rad/sec
Sample frequency, Fs = 10 kHz (or sampling period, Ts = 100 µs)
The desired current controller bandwidth is 20 times lower than the sampling frequency and we would like
a damping factor () of 4. Find all the current and speed PI coefficients:
SOLUTION
Since we are trying to set the current bandwidth 20 times lower than the sampling frequency, we solve
this equation:
Now, the integral gain of the current controller is using the following equation:
For the speed controller, we take into account the speed filter, and using the following equation:
102
( )
And,
( )
The simulated speed transient step response for this example is shown in the following figure where the
time axis is now scaled appropriately for this design example.
103
There are no new project files.
CTRL_setFlag_enableSpeedCtrl ctrl.c
CTRL_getK* CTRL_setFlag_enableRsRecalc CTRL_run
CTRL_setSpd_ref_krpm CTRL_getK*
wref CTRL_setK* CTRL_setFlag_enableOffset CTRL_setup
Traj CTRL_setK*
User_SpdRef
Ramp Speed Spdout Iq_ref
PI Iq HAL_writePwmData
~
w
Iq PI
CTRL_setIq_ref_pu Vq Vα_out Ta
User_IqRef INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id
Iq PARK
HAL_setBias
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle FAST™
~
w ~
EST_getSpeed_krpm w Software Encoder Vα_in Va ADC
Speed
Rotor Flux Observer Vb Driver
~t EST_getTorque_lbin ~t Vβ_in CLARKE
Motor Parameters ID Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd
~ EST_getLs_q_H
Lsq
~ user.h
yrated
~ user.h
Irated
Forever Loop
CTRL_getKp
CTRL_getKi
CTRL_setKp
CTRL_setKi
104
The get and set functions for the Kp and Ki speed controller have been added. Immediately after
identification, the speed PI gains are updated to pre-calculated versions that were used during motor
identification. After the gains are updated, they can be changed in real time by using the “gMotorVars”
structure.
Table 19: New API function calls during the main run-time loop.
Forever Loop
CTRL
CTRL_getKp Get the Kp gain from the CTRL object.
CTRL_getKi Get the Ki gain from the CTRL object.
CTRL_setKp Set the Kp gain in the CTRL object.
CTRL_setKi Set the Ki gain in the CTRL object.
Nothing has changed in this section of the code from the previous lab.
105
Build lab5b, connect to the target and load the .out file.
Add the appropriate watch window variables by calling the script “proj_lab05b.js”.
Enable the real-time debugger.
Click the run button.
Enable continuous refresh on the watch window.
First we will not worry about finding any data for the motor that is being tuned. The motor control will be
set to reference speed of 0 rpm. Then by hand, one can feel how the motor is performing.
By knowing that the Ki_spd value increases the spring constant of the system, if a speed controlled
system is unstable, reduce the Ki_spd value to stabilize the system. Knowing that the Kp_spd gain
dampens the speed controlled system can help stabilize the system by increasing Kp_spd.
106
Obtain the motor parameters
Rs – Motor resistance
Ls – Motor total inductance
P – Number of poles for the motor
Ke – Motor flux constant in V/Hz
J - Inertia of the whole mechanical system
Where:
Where:
is the tick rate between controller state machine and speed controllers,
USER_NUM_CTRL_TICKS_PER_SPEED_TICK
Calculate from the current controller bandwidth, keeping these limits in mind:
107
Calculate
Calculate
Calculate
As a reminder, the PI analysis that came up with these calculations is based on the series PI loop.
InstaSPIN uses a series PI loop for the current controllers and a parallel PI loop for the speed controller.
The speed PI gains have to be converted from the series form to the parallel form. Equation 33 shows the
conversion.
Equation 33
The calculations that have been done so far have not been converted to be used in the digital PI
regulator. All of the Ki gains precede a digital integrator. The digital integrator is multiplied by the
sampling time. To reduce the number of multiplies that are needed in the code, the sampling time must
be multiplied by the Ki gains before importing the values into the code.
Convert the integral gains to the suitable value for use in the digital PI control
The proportional gains must be per-unitized before being entered into the digital PI control
108
Enter the per-unit gain values into the appropriate gain values
gMotorVars.Kp_spd =
gMotorVars.Ki_spd =
gMotorVars.Kp_Idq =
gMotorVars.Ki_Idq =
Run the motor and load the shaft to see the performance
Compare the gain values between the trial and error and calculated tuning techniques
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
The resulting plot of this speed controller, compared to a simulation using the exact same gains looks like
this:
Now if we add a small value of viscous damping factor to the simulation, then we get a perfect match.
109
Tuning the speed controller has more unknowns than when tuning a current controller. Therefore the first
approach to tuning the speed controller, in this lab, is by using a trial and error approach. It was shown
that the parallel speed PI closed loop control correlates to a mass, spring, damper system. If more
parameters are known about the mechanical system of the motor controlled system, then the optimum
calculated approach can be used. The calculated approach will identify the gains for the speed and
current controllers based on the bandwidth and damping selected by the user.
110
Lab 5c - InstaSPIN-MOTION Inertia Identification
Both InstaSPIN-FOC and InstaSPIN-MOTION are sensorless FOC solutions that identify, tune and
control your motor in minutes. Both solutions feature:
The FAST unified software observer, which exploits the similarities between all motors that use
magnetic flux for energy transduction. The FAST estimator measures rotor flux (magnitude and
angle) in a sensorless FOC system.
Automatic torque (current) loop tuning with option for user adjustments
Inertia identification is the first step in enabling the SpinTAC™ speed controller. The inertia value is used
by the SpinTAC Velocity Control to determine how strongly to respond to the disturbances in the system.
InstaSPIN-MOTION provides a mechanism to identify the system inertia. If the inertia of your system is
known you can populate the inertia value in your project, and bypass the SpinTAC™ Inertia Identification
process (see the Bypassing Inertia Identification section of the InstaSPIN-FOC and InstaSPIN-MOTION
User Guide).
Once the inertia is identified, it can be set as the default value and does not need to be estimated again
unless there is a change in your system.
In this lab, you will learn how to run the inertia identification process from within your MotorWare project.
Additional information about Inertia Identification can be found in the InstaSPIN-FOC and InstaSPIN-
MOTION User Guide (see section Inertia Identification).
111
Inertia is a measure of the motor’s resistance to change in velocity. The greater the motor inertia, the
greater the torque needed to accelerate or decelerate the motor. The SpinTAC Velocity Control uses the
system’s inertia value to provide the most accurate control. SpinTAC™ Velocity Identify automatically
measures the system inertia by spinning the motor and measuring feedback.
In this lab, you will learn how to run SpinTAC™ Velocity Identify’s inertia identification process from within
your MotorWare project
The user motor settings from the user.h file need to be copied into the InstaSPIN-MOTION user.h file. If
you are working with the DRV8312 Rev D evaluation kit:
1. Open the user.h file that was modified as part of InstaSPIN-FOC lab 2a. It is located in
“sw\solutions\instaspin_foc\boards\drv8312_revD\f28x\f2806xF\src”
2. Locate the USER_MOTOR settings that you identified in lab 02a. It should appear similar to the
following:
5. Notice that there are now four new fields for MY_MOTOR:
o USER_MOTOR_ENCODER_LINES – This should be set to the number of pulses on your
motor’s encoder. If your motor does not have an encoder, set this to 1.0.
112
o USER_MOTOR_MAX_SPEED_KRPM – This should be set to the maximum speed that your
motor can run.
o USER_SYSTEM_INERTIA – We will determine this value as part of this lab. Please set it the
default value of 0.02.
o USER_SYSTEM_FRICTION - We will determine this value as part of this lab. Please set it the
default value of 0.01.
6. There is an additional new define for InstaSPIN-MOTION,
USER_SYSTEM_BANDWIDTH_SCALE (not included in the picture). This definition represents
the default bandwidth for the SpinTAC controller. We will determine this value in lab 05e. Please
set it to the default value of 1.0
In addition to the USER_MOTOR settings, it is important that you copy ANY field that you modified as
part of the previous labs or as part of your hardware design process into this new user.h file.
If you are using a different evaluation kit, you should replace the drv8312_revD directory with your kit’s
directory.
Inertia is the resistance of an object to rotational acceleration around an axis. This value is typically
calculated as the ratio between the torque applied to the motor and the acceleration of the mass rigidly
coupled with that motor. This test needs to be done under negligible friction and load.
There is a common misunderstanding that inertia is equivalent to load. Load usually consists of two
components, load inertia and load torque. Load inertia is the mass that will spin simultaneously with the
motor rotor, while the load torque appears as an external torque applied on the motor rotor shaft. An easy
way to differentiate the load inertia from load torque is to consider whether the load will spin together with
the rotor shaft if the rotor shaft changes spinning direction. Direct couplers and belt pulleys with the mass
rigidly mounted to the load shaft are examples of load inertia. Load inertia and motor rotor inertia
contribute to the system inertia. Examples of load torque include: gravity of a mass applied to one side of
the motor rotor shaft, distributed clothes in a washing machine drum during the spin cycle, and the fluid
viscosity of a pump. SpinTAC Velocity Identify estimates the load inertia and the friction of the system;
Eliminate or minimize the load torque before running SpinTAC Velocity Identify.
113
Simple Motion System Identifying Inertia
Load
Rotation Rotation
Motor Motor
Disconnected
Non-Rotating Non-Rotating
Mass Mass
This lab adds the critical function calls for identifying the motor inertia. The block diagram in Figure 36
shows how the SpinTAC components fit in with the rest of the InstaSPIN library.
114
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref SpinTAC™
SpinTAC™ . SpinTAC™ .
Motion wlim w ref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST™ Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC™ ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
It is important to note that only the SpinTAC Velocity Identify block is highlighted in the block diagram.
This indicates that only the SpinTAC Velocity Identify is included as part of this lab. This block accepts
the speed feedback and outputs the Iq reference that is provided to the FOC, which is placed into torque
mode. This block will generate the system inertia and friction as outputs to the user.
Prior to the Inertia Identification process, a couple of conditions need to be satisfied. These conditions
have already been satisfied in the lab code, where applicable.
The motor should not be spinning, or should be spinning very slowly.
o The estimate of the inertia could be incorrect if it begins the torque profile while the motor
is already moving.
The InstaSPIN-FOC PI speed controller needs to be disabled.
o SpinTAC Velocity Identify needs to provide the Iq reference in order to test the inertia.
This can be achieved only if the InstaSPIN-FOC PI speed controller is disabled.
A positive speed reference must be set in FAST.
o The FAST estimator needs to know the spinning direction of the motor via speed
reference in order for it to correctly estimate the speed. The value can be any positive
value for speed reference setting.
Force Angle must be enabled.
o The Force Angle provides a good start from zero speed, and produces better inertia
estimates.
Figure 37 is a flow chart that shows the steps required prior to beginning the inertia identification process.
This chart is implemented in the code of this lab.
115
Start Identify Set Speed Reference
Process to 0
Y Disable
Is Motor Speed Set Positive Speed
InstaSPIN-FOC Enable Force Angle
0? Reference
Speed Controller
N Y
Is Identify in
Exit Identify Process
Error?
A description of the new included files critical for InstaSPIN setup is shown in Table 21, below. Note that
main.h is common across all labs so there will be more includes in main.h than are needed for this lab.
Table 21: Important header files needed for the motor control.
main.h Header file containing all included files used in main.c
SpinTAC
spintac.h SpinTAC component setup and configuration.
The critical header file for the SpinTAC components is spintac_velocity.h. This header file is common
across all labs so there will be more includes in spintac_velocity.h than are needed for this lab.
116
Table 22: Important header filed needed for the SpinTAC components.
spintac.h Header file containing all SpinTAC header files used in main.c
SpinTAC
spintac_vel_id.h SpinTAC Velocity Identify structures and function declarations.
Global object and declarations that are listed in the table below are only the objects that are absolutely
needed for the motor controller. Other object and variable declarations are used for display or information
for the purpose of this lab.
Table 23: Global object and variable declarations important for the motor control
globals
SpinTAC
The object that holds all of the structure and handles required to interface to the
ST_Obj
SpinTAC components.
The new functions that are added to this lab to setup the SpinTAC components are listed in Table 24.
Table 24: Important setup functions needed for the motor control
setup
SpinTAC
ST_init Initializes all variables required for configuration of the SpinTAC (ST) object.
ST_setupVelId Sets up the SpinTAC Identify object with default values.
The main ISR calls very critical, time dependent functions that run the SpinTAC components. The new
functions that are required for this lab are listed in Table 25.
117
SpinTAC Velocity Identify is called from the ST_runVelId function. This function handles both the state
machine of SpinTAC Velocity Identify as well as calling SpinTAC Velocity Identify. These functions are
listed in Table 26.
STVELID_setVelocityPositive This function sets the goal speed (cfg.VelPos) of SpinTAC Velocity Identify
This function sets the torque ramp rate (cfg.RampTime_sec) of SpinTAC Velocity
STVELID_setTorqueRampTime_sec
Identify
STVELID_setEnable This function sets the enable (ENB) bit in SpinTAC Velocity Identify.
This function calls into the SpinTAC Inertia Identification to estimate the system
STVELID_setVelocityFeedback
inertia.
This function calls into the SpinTAC Inertia Identification to estimate the system
STVELID_run
inertia.
STVELID_getDone This function return the done (DON) bit of SpinTAC Velocity Identify
STVELID_getErrorID This function return the error (ERR_ID) of SpinTAC Velocity Identify
STVELID_getTorqueReference This function return the torque reference (Out) of SpinTAC Velocity Identify.
118
The code for this lab is setup according to the block diagram shown in Figure 36.
In Code Composer, build proj_lab05c. Start a Debug session and download the proj_lab05c.out file to
the MCU.
The InstaSPIN controller will now run the motor. In order to maintain the sensorless angle of the motor it
will spin at a slow speed. This speed the motor spins at in between inertia estimations can be modified
via the variable gMotorVars.StopSpeedRef_krpm. Prior to SpinTAC™ Velocity Identify inertia
identification the motor will decelerate to zero speed and then begin the inertia identification process.
119
Opening the Outline View will provide an outline of the user.h contents
In the section were you have defined your motor there should be two additional definitions to hold the
inertia and the friction of your system. Place the values for inertia and friction from
gMotorVars.SpinTAC.InertiaEstimate_Aperkrpm and gMotorVars.SpinTAC.FrictionEstimate_Aperkrpm as
the values for these defines.
USER_SYSTEM_INERTIA (gMotorVars.SpinTAC.InertiaEstimate_Aperkrpm)
USER_SYSTEM_FRICTION (gMotorVars.SpinTAC.FrictionEstimate_Aperkrpm)
The motor inertia is now identified. Set “gMotorVars.SpinTAC.VelIdRun” to 1 in order to run the inertia
identification process multiple times.
Set the variable “gMotorVars.Flag_Run_Identify” to 0 to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
120
This lab has demonstrated how to identify a motor’s inertia from within your MotorWare project. A
motor’s inertia has been identified and the value was entered into the user.h file. The recorded inertia
value will be used in the following labs as we begin to build our motion system.
121
Lab 5d - InstaSPIN-MOTION Speed Controller
Inertia identification is the first step in enabling the SpinTAC™ speed controller. This lab uses the motor
inertia that was identified in Lab 5c - InstaSPIN-MOTION Inertia Identification and stored in the user.h file.
The inertia value is used by the SpinTAC Velocity Control to determine how strongly to respond to the
disturbances in the system. This lab focuses on using the SpinTAC Velocity Control to spin your motor.
The motor inertia value has been identified and populated in user.h. This process should be completed
inLab 5c - InstaSPIN-MOTION Inertia Identification.
Use the SpinTAC Velocity Control to replace the InstaSPIN-FOC speed controller
This lab has new API function calls for the SpinTAC™ speed controller. Figure 38 shows the block
diagram for this project.
122
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST™ Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
The difference between the block diagram for lab 5d (Figure 38) and lab 5c (Figure 36) is that the
SpinTAC Velocity Identify component has been removed from this project. Now that the system inertia
has been identified, the SpinTAC Velocity Control component can be placed in the project. This block
accepts the user speed reference and the speed feedback and outputs the Iq reference that is provided to
the FOC, which is placed into torque mode.
The critical header file for the SpinTAC components is spintac_velocity.h. This header file is common
across all labs so there will be more includes in spintac_velocity.h than are needed for this lab.
The new functions added to the lab to configure SpinTAC components are listed in Table 28.
123
Table 28: InstaSPIN functions needed to setup the motor control
setup
SpinTAC
ST_setupVelCtl Sets up the SpinTAC Velocity Controller object with default values.
There are no changes in the main run-time forever loop for this lab.
The main ISR calls very critical, time dependent functions that run the SpinTAC components. The new
functions that are required for this lab are listed in Table 29.
The function ST_runVelId and the supporting logic have been removed from this project. This was done
because the SpinTAC Inertia Identification only needs to be done once, during development, and is not
needed in the final system. ST_runVelCtl has been added to this project and it handles calling the
SpinTAC Velocity Control. Table 30 shows the functions that are called in the ST_runVelCtl function.
CTRL
CTRL_setIq_ref_pu This function sets the Iq reference to the Iq Current Controller
124
After verifying that user.h has been properly updated with your motor’s inertia, build lab5d, connect to the
target and load the .out file.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
125
This lab showed how to replace the InstaSPIN-FOC speed controller with the SpinTAC™ speed
controller. It also demonstrated that interfacing to the SpinTAC Velocity Control is no different than
interfacing to a PI speed controller. This lab is the basis for all subsequent labs where the more
advanced features of the SpinTAC™ library will be used to tune and optimize your system.
126
Lab 5e - Tuning the InstaSPIN-MOTION Speed Controller
InstaSPIN-MOTION provides maximum control with minimal effort. InstaSPIN-MOTION features the
SpinTAC™speed controller with Active Disturbance Rejection Control (ADRC). In real-time, ADRC
estimates and compensates for system disturbance caused by:
Nonlinear friction
Changing loads
Environmental changes
The SpinTAC Velocity Control presents better disturbance rejection and trajectory tracking performance
than a PI controller, and can tolerate a wide range of inertia change. This means that SpinTAC™
improves accuracy and minimizes mechanical system duress.
With single coefficient tuning, SpinTAC™ allows you to quickly test and tune your velocity control from
soft to stiff response. This single gain (bandwidth) works across the entire variable speed and load range
of an application, reducing complexity and system tuning.
In this lab, you will tune the SpinTAC Velocity Control to obtain the best possible system performance.
Additional information about the SpinTAC Velocity Control can be found in the InstaSPIN-FOC and
InstaSPIN-MOTION User Guide (see section InstaSPIN-MOTION Controllers).
The SpinTAC Velocity Control features a single tuning parameter, bandwidth. Once the motor inertia has
been identified, you’re ready to tune the controller. This tuning process will allow you to quickly zero in on
the optimal control setting by adjusting a single variable (bandwidth).
If you have completed Lab 5b – Tuning the FAST Speed Loop, you will notice that the tuning process in
this lab for the SpinTAC Velocity Control will be much faster.
This lab assumes that the motor parameters and inertia have been identified (as part of Lab 5c -
InstaSPIN-MOTION Inertia Identification), and that you have used the SpinTAC Velocity Control to spin
your motor (Lab 5d - InstaSPIN-MOTION Speed Controller).
127
This lab has no new API function calls. Figure 39 shows the block diagram for this project.
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST™ Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
The block diagram for this lab has not been modified from lab 5d. The difference between these two labs
is that as part of this lab you will be tuning the SpinTAC Velocity Controller.
The single tuning parameter used by the SpinTAC Velocity Control is called bandwidth. Bandwidth
identifies how quickly the system will respond to changes. The bandwidth of the SpinTAC Velocity
Control is adjusted with a scalar value called BwScale. The SpinTAC Velocity Control then uses Active
Disturbance Rejection Control to automatically compensate for disturbances in your system. Figure 40
shows the controller response when a load is applied (system disturbance), and when a load is removed
(system disturbance). When load torque is applied to the system the speed will dip until the controller can
return the speed to the setpoint and when the load torque is removed from the system the speed will peak
until the controller can return the speed to the setpoint. Notice that the controller to responds more
quickly to these disturbances as the bandwidth is increased.
128
6000
SpinTAC Bandwidth Comparison
5800
5600
5400 10 rad /s
5200
5000
4800
4600
4400 20 rad /s
4200
4000 30 rad /s
Speed [RPM]
Nothing has changed in the initialization and setup from the previous lab.
129
Nothing has changed in the forever loop from the previous lab.
Nothing has changed in this section of the code from the previous lab.
Nothing has changed in this section of the code from the previous lab.
130
Build lab5e, connect to the target and load the .out file.
In order to properly hold zero speed, the ForceAngle feature needs to be turned off. Set
“gMotorVars.Flag_enableForceAngle” to 0.
Make sure the motor is at zero speed by setting “gMotorVars.SpeedRef_krpm” to 0. Once the motor is at
zero speed, manually rotate the motor shaft with your hand to feel how tightly the motor is holding zero,
this is an indication of how aggressively the motor is tuned.
This process has tuned the bandwidth scale for zero speed. It still needs to be verified at higher
operating speeds. Occasionally a bandwidth scale can work very well at zero speed but cause instability
at higher speeds.
Set the maximum motor speed as a reference in “gMotorVars.SpeedRef_krpm”
If the motor speed begins to oscillate or show other signs on instability, decrease
“gMotorVars.SpinTAC.VelCtlBwScale” until it no longer oscillates. It typically only needs to be
decreased by 10-15%
At the top of the USER MOTOR defines section in user.h there is a parameter called
USER_SYSTEM_BANDWIDTH_SCALE. Update the value for this define with the value you identified
during the tuning process.
USER_SYSTEM_BANDWIDTH_SCALE (gMotorVars.SpinTAC.VelCtlBwScale)
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
131
This lab showed how easy it is to tune the SpinTAC Velocity Control for your motor. The single
parameter tuning of the SpinTAC Velocity Control alleviates the pain of tuning PI regulators at different
speed and load configurations. The bandwidth scale value found in this lab will be used in future labs to
showcase the SpinTAC™ controller’s performance.
132
Lab 5f - Comparing Speed Controllers
The SpinTAC Velocity Control bundled with InstaSPIN-MOTION shows remarkable performance when
compared against a traditional PI controller. This lab will lead you through a comparison of these two
controllers. Additional information about the comparison of speed controllers can be found in the
InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see Optimal Performance section 13.4).
In addition to a single tuning parameter the SpinTAC Velocity Control is also a more robust controller than
a traditional PI controller. This can be observed by setting step responses into the two controllers.
This lab assumes that the SpinTAC Velocity Control has been tuned (Lab 5e - Tuning the InstaSPIN-
MOTION Speed Controller) and that the PI speed controller has been tuned (Lab 5b – Tuning the FAST
Speed Loop).
See how the SpinTAC Velocity Control provides superior speed regulation then a PI controller
This lab has no new API function calls. Figure 41 shows the block diagram for this project.
User_SpdRef
gMotorVars.SpinTAC.VelCtlEnb HAL_writePwmData
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST™ Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
133
In this lab the Traj Ramp and Speed PI blocks provided by InstaSPIN-FOC can be re-enabled. This is
done in order to compare the control performance between the SpinTAC Velocity Control and the Speed
PI. The control selection is provided by the switch gMotorVars.SpinTAC.VelCtlEnb which is discussed in
the Lab Procedure section of this document.
We will use the graphing features of Code Composer in order to visually compare the two controllers. It
will allow us to see the step response of the two speed controllers.
There are new global variables that are designed to support the graphing features of Code Composer..
Nothing has changed in the initialization and setup from the previous lab.
This version of the forever loop will allow you to switch between the SpinTAC Velocity Control and the PI
speed controller. This is controlled via the “gMotorVars.SpinTAC.VelCtlEnb” variable. When this variable
is set to 1 SpinTAC is providing the speed control, when it is set to 0 PI is providing the speed control.
This lab has been modified to store values into a buffer for graphing purposes. It will store the speed
feedback into “Graph_Data” and the Iq reference into “Graph_Data2”. This has been done so that the
actual signals for speed feedback and Iq reference can be compared visually in Code Composer.
The ST_runVelCtl function has been updated to set the integrator term in the InstaSPIN-FOC PI speed
controller. This is done in order to allow the speed controller to seamlessly switch between the SpinTAC
Velocity Control and the PI speed controller.
134
In Code Composer, build proj_lab05f. Start a Debug session and download the proj_lab05f.out file to the
MCU.
135
o In order to reset the y-axis scale on the plot please click the button with the red ‘x’
The graphs will allow you to visually see the speed response of the speed controllers and will allow you to
more easily compare the performance of the PI speed controller and the SpinTAC speed controller
To provide a fast reference to the control loops, the acceleration that the ramp generator is using needs
to be faster than the motor can accelerate. The acceleration in “gMotorVars.MaxAccel_krpmps” needs to
be set to at least 20.0.
Set a speed reference in “gMotorVars.SpeedRef_krpm” in order to get the motor spinning. Each time you
set a new speed reference it will update the graph with the controller response to the new speed
reference.
Switch between SpinTAC & PI using the variable “gMotorVars.SpinTAC.VelCtlEnb”. If this variable is set
to 1 it will use SpinTAC to control the speed. Setting this to 0 will use PI to control the speed.
Compare the response of the two speed controllers for different speed references. You will notice that
the SpinTAC controller will have less overshoot and will return to the target speed with less oscillation
than the PI controller.
136
The two controllers can also be tuned in this lab to allow for a more in-depth comparison.
To tune PI, adjust the values “gMotorVars.Kp_spd” and “gMotorVars.Ki_spd”. Note that these
parameters may need to be modified to support different speeds and loads.
To tune SpinTAC, adjust the value “gMotorVars.SpinTAC.VelCtlBwScale”. Note that this single
tuning parameter typically works across the entire operating range.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
137
This lab showed the advanced performance of the SpinTAC Velocity Control in a direct and head-to-head
comparison with a PI controller.
138
Lab 5g – Adjusting the InstaSPIN-FOC Speed PI Controller,
with fpu32
This lab runs Lab 5b with floating point unit enabled. This lab only applies to 6x devices, as it has a
floating point unit.
We conclude that the libraries in ROM also work when fpu32 is enabled in 6x devices.
139
Lab 6a - Smooth system movement with SpinTAC Move
InstaSPIN-MOTION includes SpinTAC Move, a motion profile generator that will generate constraint-
based, time-optimal motion trajectory curves. It removes the need for look-up tables and runs in real-time
to generate the desired motion profile. This lab will demonstrate the different configurations and their
impact on the final speed change of the motor. Additional information about the SpinTAC™ Move can be
found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section Trajectory Planning).
SpinTAC™ Move is a velocity profile generator that computes the time-optimal curve within the user
defined acceleration and jerk bounds. It supports basic ramp profiles as well as advanced s-curve and st-
curve (Linestream Proprietary) curves. The proprietary st-curve features a continuous jerk to provide
additional smoothing on the trajectory.
This lab assumes that the motor inertia has been identified, that you are able to control the speed of the
motor through your MotorWare project, and that the SpinTAC Velocity Control has been tuned.
This lab adds new API function calls to call SpinTAC™ Move. Figure 42 shows how SpinTAC™ Move
connects with the rest of the SpinTAC™ components.
140
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST™ Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
s-Curve
0.5 st-Curve
0
0 0.5 1 1.5 2 2.5 3
1
Acc [pu/s 2]
0.5
0
0 0.5 1 1.5 2 2.5 3
1
Jrk [pu/s3]
-1
0 0.5 1 1.5 2 2.5 3
Time [s]
141
the step in speed, the greater this tendency for the system to oscillate. Control over jerk can round the
velocity corners, reducing oscillation. As a result, acceleration can be set higher. Controlling the jerk in
your system will lead to less mechanical stress on your system components and can lead to better
reliability and less failing parts.
The critical header file for the SpinTAC components is spintac_velocity. This header file is common
across all labs so there will be more includes in spintac_velocity than are needed for this lab.
The new functions that are added to this lab to setup the SpinTAC components are listed in Table 33.
142
Nothing has changed in the forever loop from the previous lab.
The main ISR calls very critical, time dependent functions that run the SpinTAC components. The new
functions that are required for this lab are listed in Table 34.
The ST_runVelMove function has been added to the project to call the SpinTAC™ Move component and
to use it to generate references for the SpinTAC™ speed controller. The functions called in
ST_runVelMove are listed in Table 35.
The ST_runVelCtl function has been updated to use SpinTAC Velocity Move as the speed reference
instead of the ramp generator.
143
Table 36: InstaSPIN functions used in ST_runVelCtl
ST_runVelCtl
SpinTAC
This function returns the velocity reference (VelRef) from SpinTAC
STVELMOVE_getVelocityReference
Velocity Move
This function returns the acceleration reference (AccRef) from
STVELMOVE_getAccelerationReference
SpinTAC Velocity Move
144
In Code Composer, build lab6a, connect to the target and load the .out file.
SpinTAC Move will generate motion profiles every time the speed reference is updated.
The motor will accelerate up to the goal speed at the slow default acceleration. The acceleration can be
set much faster.
“gMotorVars.MaxAccel_krpmps” configures the acceleration used in the profile. Set this value to
2.0. This will cause the motor to accelerate much quicker.
Change the speed reference via “gMotorVars.SpeedRef_krpm” to -1.0 to see how changing the
acceleration limit allows the motor to change speeds much more quickly.
Set “gMotorVars.MaxAccel_krpmps” to 120.0. This is the maximum acceleration for this project.
This acceleration maximum is based on the maximum value of an IQ24 variable. This value is
set to be the maximum acceleration in SpinTAC™ Move. If a larger acceleration is configured,
this will cause SpinTAC™ Move to report an error via “gMotorVars.SpinTAC.VelMoveErrorID.”
Set “gMotorVars.SpeedRef_krpm” to 1.0 to see the very fast acceleration
SpinTAC™ Move provides a feedforward reference that is used by the SpinTAC Velocity Control to
enable very accurate profile tracking. This feedforward reference is the acceleration reference and the
rate at which it changes is the jerk. The jerk sets the rate of change of the acceleration.
To see the impact of jerk set “gMotorVars.MaxJrk_krpmps2” to 750.0. This is the maximum value
for jerk in this project. This jerk maximum is based on the maximum value of an IQ20 variable.
This value is set to be the maximum jerk in SpinTAC™ Move. If a larger jerk is configured, this
will cause SpinTAC™ Move to report an error via “gMotorVars.SpinTAC.VelMoveErrorID.”
Set “gMotorVars.SpeedRef_krpm” to -1.0 to see how adjusting the jerk allows the motor to
accelerate even faster.
SpinTAC™ Move supports three different curve types: trapezoid, s-curve, and st-curve. The curve can be
selected by changing “gMotorVars.VelMoveCurveType.” The differences between the three curves types
are discussed in detail in the InstaSPIN-MOTION User’s Guide. Note that using an extremely fast
acceleration and jerk with a trapezoid curve can cause the motor to brown-out the processor. This
145
limitation is due to the power supply on the TI evaluation board. If that happens, stop the debugger and
relaunch the lab.
SpinTAC™ Move will alert the user when it has completed a profile via the done bit. When the profile is
completed, “gMotorVars.SpinTAC.VelMoveDone” will be set to True. This could be used in a project to
alert the system when the motor reaches goal speed.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
146
This lab showed how easy it is to use SpinTAC Move to generate constraint-based, time-optimal motion
profiles. This lab also shows the different curves that can be used with SpinTAC Move. The st-curve
provides a continuous jerk profile that will enable very smooth motion for jerk sensitive applications.
147
Lab 6b - Motion Sequence Example
InstaSPIN-MOTION includes SpinTAC™ Velocity Plan, a motion sequence planner that allows you to
easily build complex motion sequences. This will allow you to quickly implement your application’s motion
sequence and speed up development time. This lab provides a very simple example of a motion
sequence. Additional information about trajectory planning, motion sequences, and SpinTAC™ Velocity
Plan can be found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section Trajectory
Planning).
SpinTAC™ Velocity Plan implements motion sequence planning. It allows for you to quickly build a
motion sequence to run your application. SpinTAC™ Velocity Plan features: conditional transitions,
variables, state timers, and actions. This lab will use a simple example to show how to quickly implement
your application’s motion sequence.
Lab 6b adds new API function calls for SpinTAC™ Velocity Plan. Figure 45 shows how SpinTAC™
Velocity Plan connects with the rest of the SpinTAC™ components.
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
148
This lab adds the SpinTAC Velocity Plan into the project. This block diagram shows how to integrate the
SpinTAC Velocity Plan with the rest of the SpinTAC components. SpinTAC Velocity Plan accepts a
motion sequence as an input and outputs the speed set point, acceleration limit, and jerk limit. These get
passed into SpinTAC Velocity Move which takes these limits and generates a profile to provide to
SpinTAC Velocity Control.
T This lab implements an example of a simple motion sequence. It includes the basic features provided
by SpinTAC Velocity Plan. Figure 46 shows the state transition map for the example motion sequence.
A B
State C
Transition
SpinTAC Velocity Plan only consumes the amount of memory that is required to configure your motion
sequence. A simple motion sequence, like the one in this lab, will consume less memory than a more
complicated motion sequence, like in the next lab. It is important that the allocated configuration array is
correctly sized for your motion sequence. This topic is further covered in the InstaSPIN-FOC and
InstaSPIN-MOTION User Guide (see section SpinTAC Plan Element Limits).
Additional details around the operation and configuration of SpinTAC™ Velocity Plan are found in the
InstaSPIN-MOTION User’s Guide.
The critical header file for the SpinTAC components is spintac_velocity. This header file is common
across all labs so there will be more includes in spintac_velocity than are needed for this lab.
149
Lab 06b adds global variables to monitor the internal states of SpinTAC™ Velocity Plan and to control
SpinTAC™ Velocity Plan. These variables provide an external interface to start, stop, and pause
SpinTAC™ Velocity Plan. These variables are also used to store the configuration of SpinTAC Velocity
Plan. This array needs to be declared in the user code so that it can be sized to fit the requirements of
the motion sequence defined by the user.
Table 38: Global object and variable declarations for SpinTAC™ Velocity Plan
globals
SpinTAC Plan
Used to handle controlling SpinTAC Plan. This defines the different
ST_PlanButton_e
states that can be set to control the operation.
The MARCO define used to establish the size of the SpinTAC Plan
ST_VELPLAN_CFG_ARRAY_DWORDS configuration array. This value is calcualted based on the number of
elements that will be used in the SpinTAC Plan configuration
stVelPlanCfgArray This array is used to store the SpinTAC Plan configuration.
During the initialization and setup, the project will call the ST_setupVelPlan function to configure and load
the motion sequence into SpinTAC™ Velocity Plan. This function is declared in the main source file for
this project. A detailed explanation of the API calls in ST_setupVelPlan can be found in the InstaSPIN-
MOTION User’s Guide.
When the motion sequence in SpinTAC Velocity Plan is configured there are many different elements that
build the motion sequence. The elements covered in this lab are States and Transitions. Each of these
elements has a different configuration function. It is important that the configuration of SpinTAC Velocity
Plan is done in this order. If the configuration is not done in this order it could cause a configuration error.
STVELPLAN_addCfgState(Velocity Plan Handle, Speed Setpoint [pu/s], Time in State [ISR ticks])
This function adds a state into the motion sequence. It is configured by setting the speed that you want
the motor to run during this state and with the minimum time it should remain in this state.
STVELPLAN_addCfgTran(Velocity Plan Handle, From State, To State, Condition Option, Condition Index
1, Condition Index 2, Acceleration Limit [pu/s^2], Jerk Limit [pu/s^3])
This function establishes the transitions between two states. The From State and To State values
describe which states this transition is valid for. The condition option specifies if a condition needs to be
evaluated prior to the transition. The condition index 1 & 2 specify which conditions should be evaluated.
If less than two conditions need to be evaluated, set the unused values to 0. Acceleration limit sets the
acceleration to use to transition between the From State speed and the To State speed. This value
cannot exceed the acceleration max that is configured for the motion sequence. The jerk limit sets the
jerk to be used in the speed transition. This value should not exceed the jerk max that is configured for
the motion sequence.
150
The functions used in ST_setupVelPlan are described in Table 40.
STVELPLAN_addCfgState This function adds a State into the SpinTAC Velocity Plan configuration
Nothing has changed in the forever loop from the previous lab.
The main ISR calls very critical, time dependent functions that run the SpinTAC components. The new
functions that are required for this lab are listed in Table 41.
The ST_runVelPlan function has been added to the project to call the SpinTAC™ Velocity Plan
component and to use it to generate motion sequences. Table 42 lists the InstaSPIN functions called in
ST_runVelPlan.
151
Table 42: InstaSPIN functions used in ST_runVelPlan
ST_runVelPlan
EST
EST_getFm_pu This function returns the speed feedback in pu from the FAST Estimator
SpinTAC
STVELPLAN_getErrorID This function returns the error (ERR_ID) in SpinTAC Velocity Plan.
STVELPLAN_setEnable This function sets the enable (ENB) bit in SpinTAC Velocity Plan.
STVELPLAN_setReset This function sets the reset (RES) bit in SpinTAC Velocity Plan.
STVELPLAN_run This function calls into SpinTAC Velocity Plan to run the motion sequence.
STVELPLAN_getStatus This function returns the status (STATUS) of SpinTAC Velocity Plan.
STVELPLAN_getCurrentState This function returns the current state (CurState) of SpinTAC Velocity Plan.
The ST_ runVelPlanTick function has been added to the project to call the time-critical components of
SpinTAC™ Velocity Plan. Table 43 lists the InstaSPIN functions called in ST_ runVelPlanTick.
152
In Code Composer, build lab6b, connect to the target and load the .out file.
To start the motion sequence, the SpinTAC™ Velocity Plan button needs to be set to start once the FAST
estimator is online.
The motor will run through a very simple motion sequence where the motor spins anti-clockwise and then
spins clockwise.
Now modify the SpinTAC™ Velocity Plan configuration to transition from State C to State B instead of
State A..
In the function ST_setupVelPlan, find the line highlighted in Figure 47. Change the value from
STATE_A to STATE_B.
Now the motor will not stop transitioning from anti-clockwise to clockwise until
“gMotorVars.SpinTAC.VelPlanRun” is set to ST_PLAN_STOP.
Continue to explore the advanced features of SpinTAC™ Velocity Plan by making additional
modifications to the motions sequence. Some examples are provided below.
153
When done experimenting with the motor:
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
154
This lab showed how easy it is to design motion sequences using SpinTAC™ Velocity Plan. This lab
configures SpinTAC™ Velocity Plan to run a simple motion sequence. This lab also showcases how
easy it is to modify the motion sequence and introduces the API calls that make up the SpinTAC™
Velocity Plan configuration.
155
Lab 6c - Motion Sequence Real World Example: Washing
Machine
SpinTAC™ Velocity Plan is a motion sequence planner. It allows you to easily build complex motion
sequences. This will allow you to quickly implement your application’s motion sequence and speed up
development time. This lab provides a very complex example of a motion sequence. Additional
information about trajectory planning, motion sequences, and SpinTAC™ Velocity Plan can be found in
the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section 14 Trajectory Planning).
SpinTAC™ Velocity Plan implements motion sequence planning. It allows for you to quickly build a
motion sequence to run your application. SpinTAC™ Velocity Plan features: conditional transitions,
variables, state timers, and actions. This lab will use the example of a washing machine to show how all
of these features can be used to implement your application’s motion sequence.
This lab adds new API function calls for SpinTAC™ Velocity Plan. Figure 48 shows how SpinTAC™
Velocity Plan connects with the rest of the SpinTAC™ components.
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
156
This lab does not contain any changes from the block diagram perspective. The primary change is using
a different motion sequence.
The washing machine example provided in this lab is an example of a complex motion sequence. It
features many interfaces to sensors and valves as well as conditional state transitions. The entire motion
sequence can be implemented in SpinTAC™ Velocity Plan. Figure 49 shows the state transition map for
the washing machine.
Start
Dry Idle Set Agitation Button
Counter pushed Fill_Valve Fill
State State Open State
Fill_Valve
Closed
Agitation
Counter
Drain_Flag == 0 decreases by 1
Drain Stage
Agitation
State State 1
Agitation
Counter > 0
A Variable
Drain_Valve Drain Drain_Valve
Transition
Closed State Open Agitation
Condition Agitation State 2
Counter <= 0
Action
Drain_Flag == 1 Wash Stage
Additional information about trajectory planning, motion sequences and SpinTAC™ Velocity Plan can be
found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section Trajectory Planning).
157
There are not new includes.
This lab adds global variables to monitor the internal states of SpinTAC™ Velocity Plan and to control
SpinTAC™ Velocity Plan. These variables provide an external interface to start, stop, and pause
SpinTAC™ Velocity Plan. These new variables are covered in
Table 44: Global object and variable declarations in SpinTAC Velocity Plan
globals
SpinTAC Plan
gVelPlanVar This array contains the states of the internal SpinTAC Plan variables.
Washer
WASHER_State_e Defines the states that make up the washing machine motion sequence.
Holds the value for the water level in the washing machine drum. 10000
gWaterLevel
represents a full water level.
There are no new function calls used to setup SpinTAC Velocity Plan. However the contents of
ST_setupVelPlan have been modified to run the example washing machine motion sequence.
When the motion sequence in SpinTAC Velocity Plan is configured there are many different elements that
build the motion sequence. These elements are States, Variables, Conditions, Transitions, and Actions.
Each of these elements has a different configuration function. It is important that the configuration of
SpinTAC Velocity Plan is done in this order. If the configuration is not done in this order it could cause a
configuration error.
STVELPLAN_addCfgState(Velocity Plan Handle, Speed Setpoint [pu/s], Time in State [ISR ticks])
This function adds a state into the motion sequence. It is configured by setting the speed that you want
the motor to run during this state and with the minimum time it should remain in this state.
158
values 1 & 2 are used to establish the bounds of the comparison. If a comparison only requires one value
it should be set in comparison value 1 and comparison value 2 should be set to 0.
STVELPLAN_addCfgTran(Velocity Plan Handle, From State, To State, Condition Option, Condition Index
1, Condition Index 2, Acceleration Limit [pu/s^2], Jerk Limit [pu/s^3])
This function establishes the transitions between two states. The From State and To State values
describe which states this transition is valid for. The condition option specifies if a condition needs to be
evaluated prior to the transition. The condition index 1 & 2 specify which conditions should be evaluated.
If no conditions or one condition needs to be evaluated, set the not used values to 0. Acceleration limit
sets the acceleration to use to transition between the From State speed and the To State speed. This
value cannot exceed the acceleration max that is configured for the motion sequence. The jerk limit sets
the jerk to be used in the speed transition. This value should not exceed the jerk max that is configured
for the motion sequence.
This function has been modified to configure SpinTAC Velocity Plan to run the motion sequence of a
washing machine. There are new function calls in order to take advantage of the advanced features of
SpinTAC Velocity Plan. The new functions are described in Table 45.
Nothing has changed in the forever loop from the previous lab.
Nothing has changed in this section of the code from the previous lab.
159
The ST_runVelPlan function has been updated to interface with the external components that make up
the sensors and valves of the simulated washing machine. Table 46 lists the functions used to interface
with external components in the ST_runVelPlan function.
160
In Code Composer, build lab6c, connect to the target and load the .out file.
To start the motion sequence, the SpinTAC™ Velocity Plan button needs to be set to start.
The motor will run through a procedure that is designed to emulate a washing machine. It will open the
WASHER_FillValve. Water will fill the drum until “gWaterLevel” reaches 1000. Once “gWaterLevel”
reaches the maximum, the WASHER_FillSensor is tripped. Then the motor will then spin clockwise and
counter-clockwise 20 times. After agitation the WASHER_DrainValve will open and “gWaterLevel” will
decrease. When “gWaterLevel” reaches 0 the water has been fully drained from the drum. It will then
begin the spin cycle. At the conclusion of the spin cycle the washer will return to the idle state ready to
begin another motion sequence.
Now modify the SpinTAC™ Velocity Plan configuration to do 30 agitations instead of 20.
In the function ST_setupVelPlan, find the line highlighted in Figure 50. Change the value from 20
to 30.
Now when the washing machine goes into agitation it should do 30 agitation cycles instead of the 20
before.
161
Continue to explore the advanced features of SpinTAC™ Velocity Plan by making additional
modifications to the motions sequence. Some examples are provided below.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
162
This lab showed how easy it is to design complex motion sequences using SpinTAC™ Velocity Plan.
This lab configures SpinTAC™ Velocity Plan to run a washing machine profile that features complex
elements. This lab also showcases how easy it is to modify the motion sequence and introduces the API
calls that make up the SpinTAC™ Velocity Plan configuration.
163
Lab 6d - Designing your own Motion Sequence
Now that SpinTAC™ Velocity Plan has been introduced, this lab lets you create your own motion
sequence. It is a chance to be creative and utilize the topics and skills that were learned in the previous
labs. Additional information about trajectory planning, motion sequences, and SpinTAC™ Velocity Plan
can be found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section 14 Trajectory
Planning).
SpinTAC™ Velocity Plan implements motion sequence planning. It allows for you to quickly build a
motion sequence to run your application. SpinTAC™ Velocity Plan features: conditional transitions,
variables, state timers, and actions. This lab will let you use these advanced features to implement your
own motion sequence.
Understand the flexibility of SpinTAC™ Velocity Plan and how it can speed up product design
Be creative
Have fun
This lab adds no new API function calls from the previous lab. Figure 51 shows the block diagram that
this project is based on.
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC + FAST Estimator HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STVELID_run ~
w
SpinTAC ADC
Velocity CTRL_run Driver
Identify CTRL_setup
ROM
164
This lab has no changes from the block diagram. The code change is in the configured motion sequence.
This lab introduces three different potential motion sequences. It features a Test Pattern, Grocery
Conveyor, and Garage Door. These motion sequences can be changed at run time with the switch
gSelectedPlan. The motion sequence can only be changed when SpinTAC Velocity Plan is in the IDLE
state.
The Test Pattern motion sequence runs a fixed speed pattern designed to exercise the controller. This
motion sequence does not contain any variables or conditional transitions. It simply runs the motor for a
fixed amount of time at each speed. Figure 52 contains the state transition map for this state machine.
Test Stage
0 4000 -4000
RPM RPM RPM
-2000 2000
RPM RPM
Transition
165
Idle Stage
State Idle
Proximity Sensor == 0
State &&
A Variable Switch == 1
Transition
Condition
Proximity Sensor == 1 Convey
|| State
Switch == 0
Convey Stage
Idle Stage
Idle Button == 1
State &&
Up Sensor == 1
Down Sensor == 1
Up Sensor = 0
Button == 1 Button = 0
Up Sensor == 1 &&
Down Sensor == 1 Down
State
State Button == 1
Down Sensor = 0
Button = 0
A Variable Down Stage
Transition Up State Button == 1
Condition
Action
Up Stage
166
Additional information about trajectory planning, motion sequences and SpinTAC™ Velocity Plan can be
found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section Trajectory Planning).
This lab also demonstrates how to setup SpinTAC Velocity Plan in order to use the minimum amount of
processor during the ISR. It splits the two function calls for SpinTAC Velocity Plan into part that runs in
the main loop of the project and part that runs in the ISR of the project.
Lab 06d adds global variables to monitor the internal states of SpinTAC™ Velocity Plan and to control
SpinTAC™ Velocity Plan. These variables are specific to the state machine that is implemented. Table
47 lists the variables that are added.
Table 47: Global object and variable declarations for SpinTAC Velocity Plan
globals
gSelectedPlan Displays the Plan that is compiled into the project.
GarageDoor
gGarageDoorDown Active if the garage door is down
gGarageDoorUp Active if the garage door is up
gGarageDoorButton Button that controls the garage door operation
GroceryConveyor
gGroceryConveyorOnOff On/Off switch for the conveyor belt
gGroceryConveyorProxSensor Proximity sensor to detect groceries at the end of the conveyor belt
During the initialization and setup, the project will call a function to generally configure SpinTAC Velocity
Plan, ST_setupVelPlan, and will call a separate function to load a motion sequence into SpinTAC Velocity
Plan. This project contains three different functions to support the different state machines in this project.
Table 48: Functions that can be used to setup different motion sequences
Setup
SpinTAC
This function calls into SpinTAC Plan to configure the motion sequence for
ST_setupVelPlan_GarageDoor
the Garage Door.
This function calls into SpinTAC Plan to configure the motion sequence for
ST_setupVelPlan_GroceryConveyor
the Grocery Conveyor.
This function calls into SpinTAC Plan to configure the motion sequence for
ST_setupVelPlan_TestPattern
the Test Pattern.
167
The main loop of the project has been modified to call SpinTAC Velocity Plan. It will call the components
of SpinTAC Velocity Plan that do not need to be updated as part of the ISR. Table 49 lists the function
that has been added into the main loop.
The main ISR of the project has been modified to call only part of SpinTAC Velocity Plan. It will only call
the components that need to be updated at the ISR frequency. Table 49 lists the function that has been
removed from the main ISR.
The ST_runVelPlan code has been modified to interface with the sensors for the three state machines in
this lab. It has also been modified to run in the Main Loop of the program. The only modification that
needs to be done is that we should only return the variables from SpinTAC Velocity Plan when the FSM is
in the STAY operation. This eliminates a race condition that exists when updating SpinTAC Velocity Plan
variables from the Watch Window.
168
In Code Composer, build lab6d, connect to the target and load the .out file.
To start the motion sequence, the SpinTAC™ Velocity Plan button needs to be set to start once the FAST
estimator is online.
The motor will now run through a test profile where it oscillates between positive and negative speeds.
Go ahead and modify the test profile to explore the capabilities of SpinTAC™ Velocity Plan.
Refer to the background section in order to see the state transition map for each of the different state
machines.
After making code modifications, the project will need to be recompiled and the .out file loaded
into the target
While making modifications to the SpinTAC™ Velocity Plan configuration, you might encounter
configuration errors. These will be indicated by the following variables:
o “gMotorVars.SpinTAC.VelPlanErrorID”
Displays the error encountered by SpinTAC™ Velocity Plan. This indicates
which function call has a configuration error.
o “gMotorVars.SpinTAC.VelPlanCfgErrorIdx”
Displays the index that caused the configuration error. This should guide you to
which instance of the function call has a configuration error.
o “gMotorVars.SpinTAC.VelPlanCfgErrorCode”
Displays specifically what the configuration error is.
Feel free to modify the code in this lab to explore the advanced capabilities provided by SpinTAC Velocity
Plan.
169
When done experimenting with the motor:
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
170
This lab showed how easy it is to design complex motion sequences using SpinTAC™ Velocity Plan.
This lab allowed you to be creative and explore on your own how SpinTAC™ Velocity Plan can enable
you to quickly design a motion sequence into your product.
171
Lab 7 – Using Rs Online Recalibration
The stator resistance of the motor’s coils, also noted as Rs, can vary drastically depending on the
operating temperature of the coils (also known as motor windings). This temperature might increase due
to several factors. The following examples list a few of those conditions where the stator coils
temperature might be affected:
As a result of the temperature increase, there is a resistance increase on the motor's windings. This
resistance to temperature relationship is well defined depending on the materials used for the windings
themselves.
In this lab, the user will exercise this feature by running a motor and enabling the Rs Online feature.
The following functions are new to this lab. These functions are all bundled in a new function called
runRsOnLine() which is called from the main forever loop. This function contains the following estimator
functions:
172
Forever Loop
EST
Gets the Estimator State to make sure the estimator is running before enabling Rs
EST_getState
Online Recalibration
Enables the Rs Online feature. After calling this function with a true as a
EST_setFlag_enableRsOnLine
parameter, a new varying Id reference will be generated to recalibrate Rs
This function sets the level of current to be generated in Id reference. The value
EST_setRsOnLineId_mag_pu needed by this function is in per unit so it needs to be scaled with
USER_IQ_FULL_SCALE_CURRENT_A
When this function is called with a true as a parameter, the internal Rs value
EST_setFlag_updateRs used by the estimator will use the Rs Online value. It is recommended to enable
this update flag only when the Rs Online value has settled.
The following block diagram shows InstaSPIN, and in red, the function call that enables Rs Online. Also,
in red, the Id reference that comes from FAST that allows Rs Online to work when it is enabled.
CTRL_setFlag_enableSpeedCtrl ctrl.c
CTRL_getK* CTRL_setFlag_enableRsRecalc CTRL_run
CTRL_setSpd_ref_krpm CTRL_getK*
wref CTRL_setK* CTRL_setFlag_enableOffset CTRL_setup
Traj CTRL_setK*
User_SpdRef
Ramp Speed Spdout Iq_ref
PI Iq HAL_writePwmData
~
w
Iq PI
CTRL_setIq_ref_pu Vq Vα_out Ta
User_IqRef INV Tb PWM
Vd Vβ_out SVM
Id_ref PARK Tc Driver
User_IdRef +
+ Id ~
Id
PI q FLASH/RAM
Id Reference
for Rs Online
Recalibration Id
Iq PARK
HAL_setBias
~ HAL_acqAdcInt
~ EST_run q FLASH/RAM
q HAL_readAdcData
~ ~ Iα Ia
y EST_getFlux_VpHz Irated Ib
Flux Iβ CLARKE
~ ~ Ic
q y
Angle FAST™
~
w ~
EST_getSpeed_krpm w Software Encoder Vα_in Va ADC
Speed
Rotor Flux Observer Vb Driver
~t EST_getTorque_lbin ~t Vβ_in CLARKE
Motor Parameters ID Vc
Torque
Vbus
ROM FLASH/RAM
~ EST_getRs_Ohm
Rs
Motor Type user.h CTRL_setFlag_enableCtrl
~ Enable Motor Identification
EST_getLs_d_H
Lsd EST_setFlag_enableRsOnLine
~ EST_getLs_q_H Enable Rs Online Recalibration
Lsq
~ user.h
Forever Loop yrated
~ user.h
Irated
EST_getState
EST_setFlag_enableRsOnLine
EST_setRsOnLineId_mag_pu
EST_setFlag_updateRs
EST_setRsOnLineId_pu
EST_setRsOnLine_pu
EST_setRsOnLine_qFmt
EST_getRs_qFmt
173
The following state machine is followed in lab 7 to allow Rs Online to work from the forever loop.
runRsOnLine
N
Is Motor
Identified?
N
Set Rs Online Is Estimator
current to 0 Online?
Y
Set Rs accumulated
Id reference to 0 Enable Rs Online
Recalibration
Disable Rs Online
Is Rs Online N
within 5% of Rs?
Disable Rs Online
updates to Rs
Y
Exit runRsOnLine
Build proj_lab07, connect to the target and load the .out file.
1. Add the appropriate watch window variables by calling the script “proj_lab07.js”.
2. Enable the real-time debugger.
3. Click the run button.
4. Enable continuous refresh on the watch window.
Once the motor starts running, the current will start looking as if there is a low frequency component to it.
This means that the Rs Online is running and Id reference is being modified by the algorithm. The
following oscilloscope plot was taken while Rs Online was running. There is a command of 0.5 A max
amplitude for Rs Online in this case:
174
5. Now change the maximum amplitude used for Rs Online by changing the following variable to
_IQ24(1.0):
175
Now notice how both Rs Online and Rs are the same and stable:
In many applications, the motor is subject to overheating conditions. This causes the stator resistance in
a motor to change. We have run the Rs Online feature of InstaSPIN, where the motor stator resistance is
updated while the motor is running, and will update resistance even if resistance goes up or down due to
temperature changes.
176
Lab 7a – Using Rs Online Recalibration, with fpu32
This lab runs Lab 7 with floating point unit enabled. This lab only applies to 6x devices, as it has a floating
point unit.
We conclude that the libraries in ROM also work when fpu32 is enabled in 6x devices.
177
Lab 9 – An Example in Automatic Field Weakening
A simple procedure in automatic field-weakening is explored. The current voltage space vector is always
compared to the maximum space vector. A voltage “head room” is maintained by controlling the
negative Id current of the FOC controller.
178
Lab 9a – An Example in Automatic Field Weakening, with
fpu32
This lab runs Lab 9 with floating point unit enabled. This lab only applies to 6x devices, as it has a floating
point unit.
We conclude that the libraries in ROM also work when fpu32 is enabled in 6x devices.
179
Lab 10a – An Example in Space Vector Over-Modulation
The SVM that is used by InstaSPIN is capable of saturating to a pre-specified duty cycle. When using a
duty cycle over 100.0%, the SVM is considered to be in the over-modulation region. When in the over-
modulation region, current shunt measurement windows become small or even disappear. This lab will
show how to re-create the currents that cannot be measured due to high duty cycles during SVM over-
modulation.
180
Lab 10b – An Example in Space Vector Over-Modulation
using InstaSPIN-MOTION
This example adds the InstaSPIN-MOTION speed controller and profile generator when doing over
modulation.
181
Lab 10c – An Example in Space Vector Over-Modulation, with
fpu32
This lab runs Lab 10a with floating point unit enabled. This lab only applies to 6x devices, as it has a
floating point unit.
We conclude that the libraries in ROM also work when fpu32 is enabled in 6x devices.
182
Lab 12a – Sensored Inertia Identification
For applications where a sensor is required InstaSPIN-MOTION can provide the same advantage it
provides to sensorless applications. InstaSPIN-MOTION currently supports quadrature encoders; Hall
effect sensors may be available in a future release. Additional information about sensored systems can
be found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section 21 Sensored Systems).
This lab discusses how to configure a quadrature encoder to provide feedback for the speed and angle
information needed by SpinTAC™ and the FOC in order to control the motor. This lab will also identify
the inertia for sensored applications.
The user motor settings have been identified and populated in the InstaSPIN-MOTION user.h file. See
the prerequisites for lab 05c for additional information
This lab has a number of new API calls. Figure 56 shows the block diagram for this project. This lab
builds from Lab 5c - InstaSPIN-MOTION Inertia Identification in order to present the simplest
implementation of the quadrature encoder.
183
User_SpdRef
Torque DRV_run
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim DRV_acqAdcInt
Plan Move Control
FOC DRV_readAdcData
FLASH/RAM ROM ROM
~
w
STPOSCONV_run STVELID_run
This lab adds the SpinTAC Position Converter into the project. This component takes the electrical angle
from the ENC module and outputs a speed feedback that is used by SpinTAC Velocity Identify. This
module will also calculate the slip required for AC Induction motors.
The additional API calls are designed to convert the raw encoder counts from the QEP driver into a
usable electrical angle via the ENC module and the electrical angle into speed feedback that can be used
in the rest of the system.
For this lab it is important to ensure that the physical connections are done correctly. If the motor or
encoder wires are connected in the wrong order, the lab will not function properly. It will result in the
motor being unable to move. For the motor it is important to ensure that the motor phases are connected
to the right phase on the controller. Phase connections for the motors that are provided with the TI Motor
Control Reference Kits are provided in Table 59.
For the encoder it is important to ensure that A is connected to A, B to B, and I to I. Often +5V dc and
ground connections are required as well. Please refer to the information for your board in order to wire
your encoder correctly.
This project will setup the calibrated angle of the encoder. This ensures that both the encoder and the
motor are aligned on a zero degree electrical angle. This step is done when the FAST™ estimator is
recalibrating the Rs value of the motor. For AC Induction motors, this calibration is not required, since the
motor will always start at a zero degree electrical angle.
It is important for the setup and configuration of the ENC module that the number of lines on the encoder
be provided. This allows the ENC module to correctly convert encoder counts into an angle. This value
is represented by USER_MOTOR_ENCODER_LINES. This value needs to be defined in user.h as part
of the user motor definitions. This value must be updated to the correct value for your encoder. If this
value is not correct the motor will spin faster or slower depending on if the value you set. It is important to
184
note that this value should be set to the number of lines on the encoder, not the resultant number of
counts after figuring the quadrature accuracy.
To include the quadrature encoder into the project, a number of platform related files need to be modified
to include the ENC module and to provide functions to access the values it produces. If you compare the
non-QEP version of these platform files with the QEP version you will see the specific differences that
have been made. Table 52 describes the files that have been modified to support the ENC module.
Table 52: New and updated files that must be included in the project
proj_lab12a
Contains code for CTRL_run and CTRL_setup, which is the code that runs the FOC.
ctrlQEP.c
This has been modified to support the ENC module.
enc.c Contains the code to configure and the ENC module.
qep.c Contains the code to configure and run the eQEP driver.
slip.c Contains the code to configure and run the SLIP module
As part of this project there is a predefined symbol that is set in order to tell the project files to use the
quadrature encoder instead of the FAST software encoder. If you right-click on proj_lab12a, and select
properties. Following window will pop-up.
185
Open Build -> C2000 Compiler -> Advanced Options, and select Predefined Symbols. The highlighted
line is the new predefined symbol that informs the project that it will use a quadrature encoder for
feedback.
A description of the newly included files for the quadrature encoder is shown in Table 53. Note that this
list only contains the files that are different from those used in the previous labs.
The critical header file for the SpinTAC components is spintac_pos_conv.h. This file contains the code
required to configure the SpinTAC Position Converter.
During the initialization and setup of the project the ENC module and the SLIP module need to be
configured. The SpinTAC Position Converter also requires some setup to function properly. This is done
by calling the function listed in Table 55. The lab is setup to configure the ENC module, SLIP Module,
and SpinTAC Position Converter correctly.
Table 55: Important setup functions needed for the motor control
main
ENC
Setups all the defualt value for the ENC module and makes it ready to produce
ENC_setup
feedback.
SLIP
Setups all the defualt value for the SLIP module and makes it ready to produce
SLIP_setup
feedback. (ACIM Only)
SpinTAC
ST_setupPosConv Setups all the default value for SpinTAC Position Converter.
186
No changes have been made in the forever loop for this lab.
The new functions that are required for this lab include functions in order to access the encoder feedback
and process that feedback to produce speed feedback that will be used by the rest of the system. The
new functions are listed in Table 56.
The new functions that are required for this lab include functions to access the electrical angle produced
by the ENC module and process that angle to produce speed feedback that will be used by the rest of the
system. The new functions are listed in Table 57.
187
Table 57: InstaSPIN functions used in ST_runPosConv
ST_runPosConv
ENC
ENC_getElecAngle This function return the electrical angle produced by the ENC module.
CTRL
CTRL_getIdq_in_addr This function returns the address of the Idq current vector. (ACIM Only)
SpinTAC
STPOSCONV_setElecAngle_erev This function set the electrical angle (Pos_erev) in SpinTAC Position Converter
This function set the Idq current vector in SpinTAC Position Converter (ACIM
STPOSCONV_setCurrentVector
Only)
This function calls into the SpinTAC Position Converter in order to produce
STPOSCONV_run
speed feedback from the electrical angle produced by the eQEP module.
This function gets the estiamted amount of slip velocity in electrical
STPOSCONV_getSlipVelocity
revolutions per second (ACIM Only)
SLIP
This function sets the slip velocity in the motor and calculates the incremental
SLIP_setSlipVelocity
slip for each iteration of the FOC. (ACIM Only)
No new API elements have been added to this lab. The one change that has been made is to the
feedback source used for SpinTAC™ Velocity Identify. Previously, SpinTAC Velocity Identify was using
the FAST estimator to provide speed feedback. This has been replaced with the speed feedback from
the SpinTAC™ Position Converter. The change is shown in Table 60.
188
After verifying that the correct encoder line count has been set as the value for
USER_MOTOR_ENCODER_LINES, use Code Composer to build lab12a. Start a Debug session and
download the proj_lab12a.out file to the MCU.
At this point the motor is using the quadrature encoder to provide the motor angle information into the
FOC. This process has removed the FAST estimator from the system.
189
2. Right-mouse click on user.h and select open, this opens the file user.c
3. Right-mouse click on the highlighted “user.h” and select “Open Declaration”, this opens user.h
Opening the Outline View will provide an outline of the user.h contents
In the section were you have defined your motor there should be two additional definitions to hold the
inertia and the friction of your system. Place the values for inertia and friction from
gMotorVars.SpinTAC.InertiaEstimate_Aperkrpm and gMotorVars.SpinTAC.FrictionEstimate_Aperkrpm as
the values for these defines.
USER_SYSTEM_INERTIA (gMotorVars.SpinTAC.InertiaEstimate_Aperkrpm)
USER_SYSTEM_FRICTION (gMotorVars.SpinTAC.FrictionEstimate_Aperkrpm)
You can also estimate the motor inertia in less than 1 complete rotation. To do this, follow these
guidelines
Reduce the goal speed in gMotorVars.SpinTAC.VelIdGoalSpeed_krpm, this won’t spin the motor
as quickly during the test
o Start by setting this value to 1/10th of the rated speed of the motor
This value should be greater than the minimum speed resolution of your encoder
Reduce the torque ramp in gMotorVars.SpinTAC.VelIdTorqueRampTime_sec, this will have the
torque change quicker during the test
o Start by setting this value to 1.0
This value can be decreased further, but will introduce more jerk since the torque
is being changed faster
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
190
This lab showed how to use InstaSPIN-MOTION in a sensored system. It showed that it is easy to setup
a quadrature encoder and identify the system inertia is less than one revolution.
191
Lab 12b - Using InstaSPIN-MOTION with Sensored Systems
For applications where a sensor is required InstaSPIN-MOTION can provide the same advantage it
provides to sensorless applications. InstaSPIN-MOTION currently supports quadrature encoders; Hall
effect sensors may be available in a future release. Additional information about sensored systems can
be found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section 21 Sensored Systems).
This lab discusses using a physical sensor to provide feedback for the SpinTAC Speed Controller.
The motor inertia value has been identified and populated in user.h. This process should be completed in
Lab 12a – Sensored Inertia Identification. The quadrature encoder has also been confirmed working in
that lab.
Use the quadrature encoder to replace the FAST estimator for speed feedback
Control the speed of a sensored motor
This lab has a number of new API calls. Figure 56 shows the block diagram for this project. This lab is
based on Lab 5e - Tuning the InstaSPIN-MOTION Speed Controller in order to present the simplest
implementation of the quadrature encoder.
192
User_SpdRef
Torque HAL_writePwmData
Mode
Velocity Mode
PWM
Driver
STVELPLAN_run STVELMOVE_run STVELCTL_run User_IqRef
wSP wref
SpinTAC™ . SpinTAC™ . SpinTAC™
Motion wlim wref
Velocity .. Velocity Velocity
Sequence wlim HAL_acqAdcInt
Plan Move Control
FOC HAL_readAdcData
FLASH/RAM ROM ROM
~
w
STPOSCONV_run STVELID_run
For this lab it is important to ensure that the physical connections are done correctly. If the motor or
encoder wires are connected in the wrong order, the lab will not function properly. It will result in the
motor being unable to move. For the motor it is important to ensure that the motor phases are connected
to the right phase on the controller. Phase connections for the motors that are provided with the TI Motor
Control Reference Kits are provided in Table 59.
For the encoder it is important to ensure that A is connected to A, B to B, and I to I. Often +5V dc and
ground connections are required as well. Please refer to the information for your board in order to wire
your encoder correctly.
This project will setup the calibrated angle of the encoder. This ensures that both the encoder and the
motor are aligned on a zero degree electrical angle. This step is done when the FAST™ estimator is
recalibrating the Rs value of the motor. For AC Induction motors, this calibration is not required, since the
motor will always start at a zero degree electrical angle.
It is important for the setup and configuration of the ENC module that the number of lines on the encoder
be provided. This allows the ENC module to correctly convert encoder counts into an angle. This value
is represented by USER_MOTOR_ENCODER_LINES. This value needs to be defined in user.h as part
of the user motor definitions. This value must be updated to the correct value for your encoder. If this
value is not correct the motor will spin faster or slower depending on if the value you set. It is important to
note that this value should be set to the number of lines on the encoder, not the resultant number of
counts after figuring the quadrature accuracy.
193
There are no new project files in this lab.
No changes have been made in the forever loop for this lab.
The function calls for SpinTAC Velocity Identify have been replaced by the function calls for the SpinTAC
Speed Controller (see Lab 5e - Tuning the InstaSPIN-MOTION Speed Controller for more information).
No new API elements have been added to this lab. The one change that has been made is to the
feedback source used for the SpinTAC™ speed controller. Previously, the SpinTAC Velocity Control was
using the FAST estimator to provide speed feedback. This has been replaced with the speed feedback
from the SpinTAC™ Position Converter. The change is shown in Table 60.
194
After verifying that the correct encoder line count has been set as the value for
USER_MOTOR_ENCODER_LINES, use Code Composer to build lab12b. Start a Debug session and
download the proj_lab12b.out file to the MCU.
At this point the motor is under speed control using the quadrature encoder to provide both the speed
feedback as well as the motor angle information into the FOC. This process has removed the FAST
estimator from the system.
If the motor did not spin at this step there are a number of things that need to be verified:
The number of encoder lines in USER_MOTOR_ENCODER_LINES
The motor phase lines are connected in the correct order
The motor encoder lines are connected in the correct order
Set a speed reference to “gMotorVars.SpeedRef_krpm” in order to get the motor to spin at speed.
If the motor does not spin at this step it typically indicates a wiring problem.
o Double check the motor wiring to ensure that it is connected in the correct order.
o Double check the encoder wiring to ensure that it is connected correctly.
Notice that the motor should have even better speed response and control than with the FAST estimator.
Continue to update the value in “gMotorVars.SpeedRef_krpm” with the speed you would like the motor to
run. The acceleration can also be modified by adjusting the value in “gMotorVars.MaxAccel_krpmps”.
You should notice smoother starts from zero speed as well as the ability to spin the motor at lower
speeds than with the FAST estimator.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
195
This lab showed how to use InstaSPIN-MOTION in a sensored system. It showed that it is easy to setup
a quadrature encoder and get your motor spinning with a feedback sensor.
196
Lab 13a - Tuning the InstaSPIN-MOTION Position Controller
Tuning position control applications can be very difficult and time consuming. InstaSPIN-MOTION
provides a position-velocity controller that can be tuned using a single coefficient. This single gain
(bandwidth) typically works across the entire range of loads and transitions in applications, reducing their
complexity. This lab demonstrates how to connect the InstaSPIN-MOTION position controller and tune it
for your application.
This lab demonstrates the functionality of the position controller included in InstaSPIN-MOTION. The
position controller is provided as part of the SpinTAC Motion Control Suite.
The system inertia value has been identified and populated in user.h. This process should be completed
in Lab 12a – Sensored Inertia Identification. A source is available to provide the electrical angle of the
motor to the FOC & the SpinTAC Position Converter. An example of how to do this with a quadrature
encoder is provided in Lab 12a – Sensored Inertia Identification.
This lab has a number of new API calls. Figure 57 shows the block diagram for this project. This lab
builds from Lab 12b - Using InstaSPIN-MOTION with Sensored Systems in order to show how to add the
InstaSPIN-MOTION Position Controller once your quadrature encoder is functional.
197
User_PosRef
Torque HAL_writePwmData
Mode
Position Mode
PWM
Driver
STPOSPLAN_run STPOSMOVE_run STPOSCTL_run User_IqRef
qsp qref
Motion
SpinTAC™ wlim SpinTAC™ w. ref SpinTAC™
.
Position wlim Position wref Position
Sequence .. HAL_acqAdcInt
Plan wlim Move Control
FOC HAL_readAdcData
FLASH/RAM ROM ROM
qFdb
STPOSCONV_run STVELID_run
5
[Mrev]
-5
-10
0 1 2 3 4 5 6
Time [s]
198
To accommodate the differences between position control and velocity control a different main.h is
required. This new file is called main_position.h. This file holds the includes and global structures that
are required for position control. The includes that are different between main.h & main_position.h are
captured in Table 61.
Table 61: Important header files needed for the motor control
main_position.h Header file containing all included files used in main.c
spintac
spintac_position.h SpinTAC posiiton component setup and configuration.
The critical header file for the SpinTAC position components is spintac_position.h. This file contains the
code required to configure the SpinTAC Position Control. This header file is common across all position
labs so there will be more includes than are needed for this lab. The new headers are captured in Table
62.
There are no new global variables declared in this lab. For consistency, the global SpinTAC object has
the same name, but the contents have changed. The velocity components have been replaced by the
position components.
During the initialization and setup of the project the SpinTAC Position Control needs to be configured.
This is done by calling the function listed in Table 631. The lab is setup to configure the SpinTAC
Position Control module correctly.
Table 631: Important setup functions needed for the motor control
main
SpinTAC
ST_setupPosCtl Setups all the defualt values for the SpinTAC Position Controller.
One change has been made to the forever loop of this lab. When the FAST estimator is not in the state
EST_State_OnLine, we need to make sure that the SpinTAC Position Control is placed into reset. This is
done because when performing the Rs recalibration, the system is not ready to be under position control.
Once this step is complete the SpinTAC Position Control can be enabled. These functions are listed in
Table 642.
199
main
SpinTAC
STPOSCTL_setReset Sets the reset bit inside the SpinTAC Positiion Control
STPOSCTL_setEnable Sets the enable bit inside the SpinTAC Positon Control
The new functions that are required for this lab include functions in order to run the SpinTAC Position
Control. The new functions are listed in Table 653.
The functions that are required to run SpinTAC Position Control are listed in Table 664. These functions
provide the ability to provide references and feedback to SpinTAC Position Control and pass the output
from SpinTAC Position Control to the FOC.
200
In Code Composer, build proj_lab13a. Start a Debug session and download the proj_lab13a.out file to
the MCU.
At this point the motor is under position control using the quadrature encoder to provide both the position
feedback as well as the motor angle information into the FOC. It is important to note that the motor will
not spin in this lab. The position reference for this lab is set to 0.
If the motor spun unexpectedly, at this step there are a number of things that need to be verified:
The number of encoder lines in USER_MOTOR_ENCODER_LINES
The motor phase lines are connected in the correct order
The motor encoder lines are connected in the correct order
Manually rotate the motor to feel how the position controller is fighting to hold the position at 0. At this
point it should not be holding zero very strongly.
The value of the position error that is being introduced is available in “gMotorVars.PositionError_MRev.”
This value is in mechanical revolutions. As the motor is manually rotated, the current position error can
be watched here.
The position error variable can also be graphed to visually watch the error signal.
201
1. Right click on “gMotorVars.PositionError_MRev” and select Graph
202
3. In Graph Properties, set the Q Value to 24, and click OK
5. To fix the Y-axis scaling on the graph select the Graph Reset button
To tune SpinTAC Position Control you need to adjust the value in “gMotorVars.SpinTAC.PosCtlBwScale.”
This value sets the Bandwidth in the SpinTAC Position Control. As the Bandwidth is increased the motor
will be able to hold a zero position much tighter.
Increase the bandwidth scale “gMotorVars.SpinTAC.PosCtlBwScale” in steps of 1.0, continuing to
feel how tightly the motor is holding zero speed.
Once SpinTAC Position Control is tightly holding zero the bandwidth scale has been tuned.
If your motor starts to oscillate or vibrate, than the Bandwidth has been set too high and it needs to be
reduced by 10-20%.
203
Once you have identified the ideal bandwidth for your system it should be stored in user.h. This will allow
it to be the default bandwidth in future labs.
At the top of the USER MOTOR defines section in user.h there is a parameter called
USER_SYSTEM_BANDWIDTH_SCALE. Update the value for this define with the value you identified
during the tuning process.
USER_SYSTEM_BANDWIDTH_SCALE (gMotorVars.SpinTAC.PosCtlBwScale)
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
204
This lab showed how to use InstaSPIN-MOTION in a position control system. It showed how easy it is to
setup the SpinTAC Position Control. It also demonstrated how quickly SpinTAC Position Control can be
tuned to meet your performance requirements.
205
Lab 13b - Smooth Position Transitions with SpinTAC™ Move
InstaSPIN-MOTION includes SpinTAC Move, a motion profile generator that generates constraint-based,
time-optimal position trajectory curves. It removes the need for lookup tables, and runs in real time to
generate the desired motion profile. This lab will demonstrate the different configurations and their impact
on the final position transition of the motor.
InstaSPIN-MOTION includes a position profile generator as part of the SpinTAC Motion Control Suite.
This position profile generator is called SpinTAC Move. It is a position profile generator that computes
the time-optimal curves within the user defined velocity, acceleration, deceleration, and jerk bounds. It
supports basic ramp profile, as well as advanced s-curve and st-curve (Linestream Proprietary) curves.
The proprietary st-curve features a continuous jerk to provide additional smoothing on the trajectory.
This lab assumes that the system inertia has been identified and SpinTAC Position Control has been
tuned.
This lab adds new API functions calls to call SpinTAC Move. Figure 59 shows how SpinTAC Move
connects with the rest of the SpinTAC components.
206
User_PosRef
Torque HAL_writePwmData
Mode
Position Mode
PWM
Driver
STPOSPLAN_run STPOSMOVE_run STPOSCTL_run User_IqRef
qsp qref
SpinTAC™ wlim SpinTAC™ w. ref SpinTAC™
Motion .
Sequence
Position wlim Position wref Position
.. Control HAL_acqAdcInt
Plan wlim Move
FOC HAL_readAdcData
FLASH/RAM ROM ROM
qFdb
STPOSCONV_run STVELID_run
207
3
Pos [pu]
2 Trap
1 s-Curve
st-Curve
0
0 1 2 3 4 5 6
1
Vel [pu/s]
0.5
0
0 1 2 3 4 5 6
0.5
Acc [pu/s 2]
-0.5
0 1 2 3 4 5 6
1
Jrk [pu/s3]
-1
0 1 2 3 4 5 6
Time [s]
Figure 60 illustrates the differences between the three curve types available in SpinTAC Move.
The st-curve represents the smoothest motion, which is critical for systems that are sensitive to
large amounts of jerk. Jerk represents the rate of change of acceleration. A larger jerk will
increase the acceleration at a faster rate. Steps, or sharp movement between two positions,
can cause the system to oscillate. Control over jerk can round the velocity corners, reducing
oscillation. As a result, acceleration can be set higher. Controlling the jerk in your system will
lead to less mechanical stress on your system components and can lead to better reliability and
less failing parts.
208
Figure 61: Chart describing curves available in SpinTAC™ Move
Figure 61 shows the different characteristics of the three curve types provided by SpinTAC Position
Move. St-curve provides the smoothest motion by smoothing out the acceleration of the profile. For most
applications the st-curve represents the best motion profile.
SpinTAC Position Move operates on relative position transitions. It is not based on an absolute position
system. Each position command that is provided to SpinTAC Position Move is treated as a position step.
Therefore, if your system were to start at a position of 0.5 mechanical revolutions and you commanded
SpinTAC Position Move to move 1 mechanical revolution, the end absolute position would be 1.5
mechanical revolutions.
It is also important to note that in SpinTAC Position Move the ratio between the configured deceleration
and acceleration must be with the following range: [0.1, 10].
The critical header file for the SpinTAC position components is spintac_position.h. This file contains the
code required to configure SpinTAC Position Move. This header file is common across all position labs
so there will be more includes than are needed for this lab. The new headers are captured in Table 675.
209
There are no new global object and variable declarations.
During the initialization and setup of the project the SpinTAC Position Move needs to be configured. This
is done by calling the function listed in Table 686. The lab is setup to configure the SpinTAC Position
Move module correctly.
Table 686: Important setup functions needed for the motor control
main
SpinTAC
ST_setupPosMove Setups all the defualt values for SpinTAC Position Move
One change has been made to the forever loop of this lab. Until the motor has been identified, the
starting position needs to be provided to SpinTAC Position Move. Table 697 describes this function call.
The new functions that are required for this lab include functions in order to run SpinTAC Position Move.
The new functions are listed in Table 708.
In the previous lab, the references provided to SpinTAC Position Control were fixed at 0. In this lab,
these references are provided by SpinTAC Position Move. The new functions required to provide the
reference from SpinTAC Position Move are listed in Table 719.
210
Table 719: InstaSPIN functions used in ST_runPosCtl
ST_runPosCtl
SpinTAC
STPOSMOVE_getPositionReference_mrev This function gets the position reference [Mrev] from SpinTAC Position Move
STPOSOVE_getVelocityReference This function gets the velocity reference [pu/s] from SpinTAC Position Move
STPOSMOVE_getAccelerationReference This function gets the acceleration reference [pu/s^2] from SpinTAC Position Move
The functions required to run SpinTAC Position Move are listed in Table 72. These functions set the user
provided limits, curve type, and call SpinTAC Position Move.
211
In Code Composer, build proj_lab13b. Start a Debug session and download the proj_lab13b.out file to
the MCU.
SpinTAC Position Move will generate motion profiles every time it is triggered to run.
The motor will spin exactly one and a half revolutions, but not very quickly. To get the motor to rotate one
revolution much faster you need to increase the velocity, acceleration, and jerk limits.
“gMotorVars.MaxVel_krpm” configures the velocity used in the profile. Set this value to 4.0. This
will allow the motor to spin at maximum speed.
Set “gMotorVars.PosStepInt_MRev” to 1.0 then set “gMotorVars. RunPositionProfile” to true.
The motor still did not spin very quickly. This is because we did not modify the acceleration or jerk limits.
Despite setting the velocity limit to maximum, the trajectory isn’t accelerating fast enough to reach that
velocity.
“gMotorVars.MaxAccel_krpmps” configures the acceleration used in the profile. Set this value to
75.0. This is the maximum value for acceleration in this project.
“gMotorVars.MaxDecel_krpmps” configures the deceleration used in the profile. Set this value to
75.0. This is the maximum value for deceleration in this project.
It is important to note that the deceleration limit needs to be in the following range:
o [0.1 * gMotorVars.MaxAccel_krpmps, 10 * gMotorVars.MaxAccel_krpmps]
Set “gMotorVars. PosStepInt _MRev” to 1.0 then set “gMotorVars. RunPositionProfile” to true.
The motor rotated a little faster, but not a lot faster. This is because we have not yet modified the jerk
limit.
212
“gMotorVars.MaxJerk_krpmps2” configures the jerk used in the profile. Set this value to 400.0.
This is the maximum value for jerk in this project.
Set “gMotorVars.PosStepInt_MRev” to 1.0 then set “gMotorVars. RunPositionProfile” to true.
Notice that the motor made the same single revolution much faster now that the limits have been
increased.
SpinTAC Move supports three different curve types: trapezoid, s-curve, and st-curve. The curve type can
be selected by changing “gMotorVars.SpinTAC.PosMoveCurveType.” The differences between the three
curves are discussed in detail in the InstaSPIN-MOTION User’s Guide.
SpinTAC Move will alert the user when it has completed a profile via the done bit. When the profile is
completed, “gMotorVars.SpinTAC.PosMoveDone” will be set to 1. This could be used in a project to alert
the system when the motor has completed a movement.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
213
This lab showed how easy it is to use SpinTAC Move to generate constraint-based, time-optimal motion
profiles. This lab also shows the different curves that can be used with SpinTAC Move. The st-curve
provides a continuous jerk profile that will enable very smooth motion for jerk sensitive applications.
214
Lab 13c - Motion Sequence Position Example
InstaSPIN-MOTION includes SpinTAC Plan, a motion sequence planner that allows you to easily build
complex motion sequences. You can use this functionality to quickly build your application’s motion
sequence and speed up development time. This lab provides a very simple example of a motion
sequence.
SpinTAC™ Plan implements motion sequence planning. It allows for you to quickly build a motion
sequence to run your application. SpinTAC™ Plan features: conditional transitions, variables, state
timers, and actions. This lab will use a simple example to show how to quickly implement your
application’s motion sequence.
Lab 13c adds new API function calls for SpinTAC™ Position Plan. Figure 62 shows how SpinTAC™
Position Plan connects with the rest of the SpinTAC™ components.
User_PosRef
Torque HAL_writePwmData
Mode
Position Mode
PWM
Driver
STPOSPLAN_run STPOSMOVE_run STPOSCTL_run User_IqRef
qsp qref
SpinTAC™ wlim SpinTAC™ w. ref SpinTAC™
Motion .
Sequence
Position wlim Position wref Position
.. Control HAL_acqAdcInt
Plan wlim
Move
FOC HAL_readAdcData
FLASH/RAM ROM ROM
qFdb
STPOSCONV_run STVELID_run
215
limit, and jerk limit. These get passed into SpinTAC Position Move which takes these limits and
generates a profile to provide to SpinTAC Position Control.
The example motion sequence in this lab is an example of a simple motion sequence. It includes the
basic features provided by SpinTAC Position Plan. Figure 63 shows the state transition map for the
example motion sequence.
A B
State C
Transition
SpinTAC Position Plan only consumes the amount of memory that is required to configure your motion
sequence. A simple motion sequence, like the one in this lab, will consume less memory than a more
complicated motion sequence, like the one in the next lab. It is important that the allocated configuration
array is correctly sized for your motion sequence.
Additional details around the operation and configuration of SpinTAC™ Position Plan are found in the
InstaSPIN-MOTION User’s Guide.
The critical header file for the SpinTAC components is spintac_position.h. This header file is common
across all labs so there will be more includes in spintac_position.h than are needed for this lab.
Lab 13c adds global variables to monitor the internal states of SpinTAC™ Position Plan and to control
SpinTAC™ Position Plan. These variables provide an external interface to start, stop, and pause
SpinTAC™ Position Plan. These variables are also used to store the configuration of SpinTAC Position
216
Plan. This array needs to be declared in the user code so that it can be sized to fit the requirements of
the motion sequence defined by the user.
Table 73: Global object and variable declarations for SpinTAC™ Position Plan
globals
SpinTAC Plan
Used to handle controlling SpinTAC Position Plan. This defines the
ST_PlanButton_e
different states that can be set to control the operation.
The MACRO define used to establish the size of the SpinTAC Position
Plan configuration array. This value is calcualted based on the
ST_POSPLAN_CFG_ARRAY_DWORDS
number of elements that will be used in the SpinTAC Position Plan
configuration
stPosPlanCfgArray This array is used to store the SpinTAC Position Plan configuration.
During the initialization and setup, the project will call the ST_setupPosPlan function to configure and load
the motion sequence into SpinTAC Position Plan. This function is declared in the main source file for this
project. A detailed explanation of the API calls in ST_setupPosPlan can be found in the InstaSPIN-
MOTION User’s Guide.
ST_setupPosPlan This function calls into SpinTAC Position Plan to configure the motion sequence.
When the motion sequence in SpinTAC Position Plan is configured there are many different elements that
build the motion sequence. The elements covered in this lab are States and Transitions. Each of these
elements has a different configuration function. It is important that the configuration of SpinTAC Position
Plan is done in this order. If the configuration is not done in this order it could cause a configuration error.
STPOSPLAN_addCfgState(Position Plan Handle, Position Step Integer [MRev], Position Step Fraction
[MRev], Time in State [ISR ticks])
This function adds a state into the motion sequence. It is configured by setting the position step (in
integer and fraction) that you want the motor to accomplish during this state and with the minimum time it
should remain in this state.
217
the acceleration & deceleration to use to transition between the From State speed and the To State
speed. These values cannot exceed the acceleration & deceleration max that is configured for the motion
sequence. The jerk limit sets the jerk to be used in the speed transition. This value should not exceed
the jerk max that is configured for the motion sequence.
STPOSPLAN_addCfgState This function adds a State into the SpinTAC Position Plan configuration
Nothing has changed in the forever loop from the previous lab.
The main ISR calls very critical, time dependent functions that run the SpinTAC components. The new
functions that are required for this lab are listed in Table 765.
The ST_runPosPlan function has been added to the project to call the SpinTAC™ Plan component and to
use it to generate motion sequences. Table 77 lists the InstaSPIN functions called in ST_runPosPlan.
218
Table 776: InstaSPIN functions used in ST_runPosPlan
ST_runPosPlan
SpinTAC Position Move
This function returns if SpinTAC Position Move has completed running a
STPOSMOVE_getDone
profile
SpinTAC Position Plan
STPOSPLAN_getErrorID This function returns the error (ERR_ID) in SpinTAC Position Plan.
STPOSPLAN_setEnable This function sets the enable (ENB) bit in SpinTAC Position Plan.
STPOSPLAN_setReset This function sets the reset (RES) bit in SpinTAC Position Plan.
This function calls into SpinTAC Position Plan to run the motion
STPOSPLAN_run
sequence.
STPOSPLAN_getStatus This function returns the status (STATUS) of SpinTAC Position Plan.
This function returns the current state (CurState) of SpinTAC Position
STPOSPLAN_getCurrentState
Plan.
This function returns the position step (PosStep_mrev) produced by
STPOSPLAN_getPositionStep_mrev
SpinTAC Position Plan.
This function returns the velocity limit (VelLim) produced by SpinTAC
STPOSPLAN_getVelocityLimit
Position Plan.
This function returns the acceleration limit (DecLim) produced by SpinTAC
STPOSPLAN_getAccelerationLimit
Position Plan.
This function returns the deceleration limit (DecLim) produced by SpinTAC
STPOSPLAN_getDecelerationLimit
Position Plan.
This function returns the jerk limit (JrkLim) produced by SpinTAC Position
STPOSPLAN_getJerkLimit
Plan.
The ST_runPosPlanTick function has been added to the project to call the time-critical components of
SpinTAC™ Position Plan. Table 78 lists the InstaSPIN functions called in ST_runPosPlanTick.
219
In Code Composer, build proj_lab13c, connect to the target and load the .out file.
To start the motion sequence, the SpinTAC™ Position Plan button needs to be set to start once the
estimator state is set to online.
The motor will run through a very simple motion sequence where the motor spins one revolution anti-
clockwise and then spins 1 revolution clockwise.
Now modify the SpinTAC™ Position Plan configuration to transition from State C to State B instead of
State A.
In the function ST_setupPosPlan, find the line highlighted in Figure 64. Change the value from
STATE_A to STATE_B.
Now the motor will not stop transitioning from anti-clockwise to clockwise until
“gMotorVars.SpinTAC.PosPlanRun” is set to ST_PLAN_STOP.
Continue to explore the advanced features of SpinTAC™ Position Plan by making additional
modifications to the motions sequence. Some examples are provided below.
220
Add a State D to SpinTAC Plan
Add a transition to and from State D
Change the transitions to run the state machine from state C -> B -> A
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
221
This lab showed how easy it is to design motion sequences using SpinTAC™ Position Plan. This lab
configures SpinTAC™ Position Plan to run a simple motion sequence. This lab also showcases how
easy it is to modify the motion sequence and introduces the API calls that make up the SpinTAC™
Position Plan configuration.
222
Lab 13d - Motion Sequence Real World Example: Vending
Machine
SpinTAC™ Plan is a motion sequence planner. It allows you to easily build complex motion sequences.
This will allow you to quickly implement your application’s motion sequence and speed up development
time. This lab provides a very complex example of a motion sequence. Additional information about
trajectory planning, motion sequences, and SpinTAC™ Plan can be found in the InstaSPIN-FOC and
InstaSPIN-MOTION User Guide (see section Trajectory Planning).
SpinTAC™ Plan implements motion sequence planning. It allows for you to quickly build a motion
sequence to run your application. SpinTAC™ Plan features: conditional transitions, variables, state
timers, and actions. This lab will use the example of a rotating vending machine to demonstrate these
features.
This lab adds new API function calls for SpinTAC™ Position Plan. Figure 65 shows how SpinTAC™
Position Plan connects with the rest of the SpinTAC™ components.
User_PosRef
Torque HAL_writePwmData
Mode
Position Mode
PWM
Driver
STPOSPLAN_run STPOSMOVE_run STPOSCTL_run User_IqRef
qsp qref
SpinTAC™ wlim SpinTAC™ w. ref SpinTAC™
Motion .
Sequence
Position wlim Position wref Position
.. Control HAL_acqAdcInt
Plan wlim Move
FOC HAL_readAdcData
FLASH/RAM ROM ROM
qFdb
STPOSCONV_run STVELID_run
223
This lab contains an example of a rotating vending machine that can only dispense one item at a time.
Figure 662 shows an example of this type of vending machine.
The vending machine operates in a complex motion sequence. It features many interfaces to buttons as
well as conditional state transitions. The entire motion sequence can be implemented in SpinTAC™
Position Plan. Figure 67 shows the state transition map for the vending machine.
224
Item 1 Item 2
FwdButton == 1
Init || Item1Inv == 0
State Item 2
FwdButton = 0
State
TotalInv == 0
FwdButton == 1
|| Item1Inv == 0
Item 1
FwdButton == 1
State || Item2Inv == 0
FwdButton = 0
Item 3
State FwdButton = 0
FwdButton == 1
|| Item4Inv == 0
A Variable Item 3
State
Transition Item 4
FwdButton == 1
State || Item3Inv == 0
Condition
FwdButton = 0
Action
Item 4
Additional information about trajectory planning, motion sequences, and SpinTAC™ Position Plan can be
found in the InstaSPIN-FOC and InstaSPIN-MOTION User Guide (see section Trajectory Planning).
This lab adds global variables to monitor the internal states of SpinTAC™ Position Plan and to control
SpinTAC™ Position Plan. These variables provide an external interface to start, stop, and pause
SpinTAC™ Position Plan. These new variables are covered in Table 79.
225
Table 79: Global object and variable declarations in SpinTAC Plan
globals
Vending Machine
gVendFwdButton Advances the vending machine position
gVendSelectButton Selects an item from the vending machine, decrements the inventory
gVendInventory Array which holds the inventory of each item in vending machine
gVendAvailableItem Displays the item that is currentlly available to vend
There are no new function calls used to setup SpinTAC Position Plan. However the contents of
ST_setupVelPlan have been modified to run the example vending machine motion sequence.
When the motion sequence in SpinTAC Position Plan is configured there are many different elements that
build the motion sequence. These elements are States, Variables, Conditions, Transitions, and Actions.
Each of these elements has a different configuration function. It is important that the configuration of
SpinTAC Position Plan is done in this order. If the configuration is not done in this order it could cause a
configuration error.
STPOSPLAN_addCfgState(Position Plan Handle, Position Step Integer [MRev], Position Step Fraction
[MRev], Time in State [ISR ticks])
This function adds a state into the motion sequence. It is configured by setting the position step (in
integer and fraction) that you want the motor to accomplish during this state and with the minimum time it
should remain in this state.
226
maximum velocity that should be used when making this transition. This value cannot exceed the
maximum velocity that is configured for the motion sequence. Acceleration limit & Deceleration limit sets
the acceleration & deceleration to use to transition between the From State speed and the To State
speed. These values cannot exceed the acceleration & deceleration max that is configured for the motion
sequence. The jerk limit sets the jerk to be used in the speed transition. This value should not exceed
the jerk max that is configured for the motion sequence.
This function has been modified to configure SpinTAC Position Plan to run the motion sequence of a
washing machine. There are new function calls in order to take advantage of the advanced features of
SpinTAC Position Plan. The new functions are described in Table 809.
Nothing has changed in the forever loop from the previous lab.
Nothing has changed in this section of the code from the previous lab.
The ST_runPosPlan function has been updated to interface with the external components that make up
the buttons of the simulated vending machine. Table 81 lists the functions used to interface with external
components in the ST_runPosPlan function.
227
Table 81: InstaSPIN functions used in ST_runPosPlan
ST_runPosPlan
SpinTAC
STPOSPLAN_getVar This function returns the value of a variable in SpinTAC Position Plan
STPOSPLAN_setVar This function sets the value of a variable in SpinTAC Position Plan
This function returns the current state of the Motion Sequence being
STPOSPLAN_getCurrentState
executed
228
In Code Composer, build proj_lab13d, connect to the target and load the .out file.
To start the motion sequence, the SpinTAC™ Position Plan button needs to be set to start once the
estimator state is set to online.
The motor will run through a procedure that is designed to emulate a vending machine. It will hold the
current position until you set “gVendFwdButton” to 1. This will alert the vending machine that the user
wants to advance the machine one location. If you wish to remove an item from the vending machine set
“gVendSelectButton” to 1. This will remove an item from the inventory. When the inventory for a specific
item has been reduced to 0, the vending machine will bypass that location.
Now modify the SpinTAC™ Plan configuration to automatically advance items until the user clears that
“gVendFwdButton.”
In the function ST_setupPosPlan, find the lines highlighted in Figure 67. Comment out each line.
This will not reset the value for “gVendFwdButton” when exiting a state.
When you run this modified motion sequence it will automatically advance the item until the user manually
sets “gVendFwdButton” to 0.
Continue to explore the advanced features of SpinTAC™ Position Plan by making additional
modifications to the motions sequence. Some examples are provided below.
229
Add a button that increments the inventory, for when the vending machine gets restocked
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
230
This lab showed how easy it is to design complex motion sequences using SpinTAC™ Position Plan.
This lab configures SpinTAC™ Position Plan to run a washing machine profile that features complex
elements. This lab also showcases how easy it is to modify the motion sequence and introduces the API
calls that make up the SpinTAC™ Position Plan configuration.
231
Lab 13e - Smooth Velocity Transitions in Position Control
In addition to providing smooth position transitions, SpinTAC Position Move can also provide smooth
speed transitions while still operating in a position control system. This lab demonstrates how to
configure SpinTAC Position Move to generate speed transitions in position mode.
InstaSPIN-MOTION’s position profile generator can also generate velocity profiles. These velocity
profiles are time-optimal curves within the user defined acceleration, deceleration, and jerk bounds. It
supports basic ramp profile, as well as advanced s-curve and st-curve (Linestream Proprietary) curves.
The proprietary st-curve features a continuous jerk to provide additional smoothing on the trajectory.
This lab assumes that the system inertia has been identified and the SpinTAC Position Control has been
tuned.
This lab adds new API functions calls to call SpinTAC Position Move. Figure 69 shows how SpinTAC
Position Move connects with the rest of the SpinTAC components.
232
User_PosRef
Torque HAL_writePwmData
Mode
Position Mode
PWM
Driver
STPOSPLAN_run STPOSMOVE_run STPOSCTL_run User_IqRef
qsp qref
SpinTAC™ wlim SpinTAC™ w. ref SpinTAC™
Motion .
Sequence
Position wlim Position wref Position
.. Control HAL_acqAdcInt
Plan wlim Move
FOC HAL_readAdcData
FLASH/RAM ROM ROM
qFdb
STPOSCONV_run STVELID_run
s-Curve
0.5 st-Curve
0
0 0.5 1 1.5 2 2.5 3
1
Acc [pu/s 2]
0.5
0
0 0.5 1 1.5 2 2.5 3
1
Jrk [pu/s3]
-1
0 0.5 1 1.5 2 2.5 3
Time [s]
Figure 70: Velocity Trajectory Curves Available from SpinTAC™ Position Move
Figure 70 illustrates the differences between the three curve types available in SpinTAC™ Position Move.
The st-curve represents the smoothest motion, which is critical for systems that are sensitive to large
amounts of jerk. Jerk represents the rate of change of acceleration. A larger jerk will increase the
acceleration at a faster rate. Steps, or sharp movement between two speeds, can cause systems to
oscillate. The bigger the step in speed, the greater this tendency for the system to oscillate. Control over
jerk can round the velocity corners, reducing oscillation. As a result, acceleration can be set higher.
233
Controlling the jerk in your system will lead to less mechanical stress on your system components and
can lead to better reliability and less failing parts.
Figure 71 shows the different characteristics of the three velocity curve types provided by
SpinTAC Position Move. St-curve provides the smoothest motion by smoothing out the
acceleration of the profile. For most applications the st-curve represents the best motion profile.
The critical header file for the SpinTAC position components is spintac_position.h. This file contains the
code required to configure SpinTAC Position Move. This header file is common across all position labs
so there will be more includes than are needed for this lab. There are no new includes.
During the initialization and setup of the project the SpinTAC Position Move needs to be configured. This
is done the same as in Lab 13b.
One change has been made to the forever loop of this lab. SpinTAC Position Move should be held in
reset until the Estimator state has advanced to OnLine. This is done so that it will not begin generating
references until the motor system is ready.
There are no new functions calls in the Main ISR. The Main ISR is the same as Lab 13b.
234
The new functions required to run SpinTAC Position Move are listed in Table 821. The difference
between Lab 13b & Lab 13e is that we will be looking for a different trigger to enable SpinTAC Position
Move, will be configuring a different type of profile, and will be setting a goal velocity and not a goal
position.
235
In Code Composer, build proj_lab13e. Start a Debug session and download the proj_lab13e.out file to
the MCU.
SpinTAC Position Move will generate motion profiles every time the velocity goal is updated.
The motor will begin spinning at 1000 rpm. To get the motor to accelerate much faster you need to
increase the acceleration, and jerk limits.
The motor accelerated a little faster, but not a lot faster. This is because we have not yet modified the
jerk limit.
“gMotorVars.MaxJerk_krpmps2” configures the jerk used in the profile. Set this value to 400.0.
This is the maximum value for jerk in this project.
Set “gMotorVars.MaxVel_krpm” to “1.0”
SpinTAC Move supports three different curve types: trapezoid, s-curve, and st-curve. This curve can be
selected by changing “gMotorVars.SpinTAC.PosMoveCurveType.” The differences between the three
curves are discussed in detail in the InstaSPIN-MOTION User’s Guide.
SpinTAC Move will alert the user when it has completed a profile via the done bit. When the profile is
completed, “gMotorVars.SpinTAC.PosMoveDone” will be set to 1. This could be used in a project to alert
the system when the motor has completed a movement.
Set the variable “Flag_Run_Identify” to false to turn off the pwms to the motor.
Turn off real-time control and stop the debugger.
236
This lab showed how easy it is to use SpinTAC Position Move to generate constraint-based, time-
optimal velocity profiles. This operating mode can be easily mixed with the typical position profile
mode of operation. This lab also shows the different curves that can be used with SpinTAC
Position Move. The st-curve provides a continuous jerk profile that will enable very smooth motion
for jerk sensitive applications.
237