Position Control with InstaSPIN-MOTION

Geoff,

Follow the same steps as outlined in the first post.

Install MotorWare version 11.

Run C:\ti\motorware\motorware_1_01_00_11\MotorWare.exe

and start going through the user guide for the Labs, specifically InstaSPIN-MOTION Lab 13 for Position Control.

C:\ti\motorware\motorware_1_01_00_11\docs\labs\instaspin_labs.pdf

The labs are set to work with three different kits and three different motors that have Encoders, but you can adapt to your own motor. The InstaSPIN-MOTION position control just requires an electrical angle feedback.

The kits and motors are here

http://www.ti.com/ww/en/mcu/instaspin/tools_software.shtml

The Motor ID feature will automatically tune the current controllers and then the intertia test and single parameter tuning for combined position+velocity will make the project go incredibly quickly.

Have fun!

Thanks Chris,

I'll have a look at what you've recommended.

A few other questions, I just thought of:-

1.  I guess the position control examples don't work with the BOOSTXL-DRV8301, which I've already got ? Do I need something like the DRV8301-69M-KIT ?

2. What does this actually mean in the press-release "LineStream Technologies is adding on-chip position control expertise to the InstaSPIN(TM)-MOTION software suite " ? It sounds like the position control functions are built into the processor, is that correct or is it purely software ?

3. Are there any video tutorials or documents to learn about using TI processors and development software and systems ?

Geoff

1. The position control examples run with TMDSCNCD28069MISO controlCARD interfacing with DRV8301 or DRV8312 EVM or HVMTR EVM.  You could port an example to the BOOSTXL-DRV8301 if you interfaced the controlCARD to the pinout, but you can NOT run InstaSPIN-MOTION using the LAUNCHXL-F28027F that primarily works with the BOOSTXL-DRV8301 because of the answer in #2

2. The InstaSPIN-FOC and InstaSPIN-MOTION solutions rely on certain libraries that are in on-chip ROM.  InstaSPIN-FOC relies on the FAST library in on-chip ROM of the F28062F, F28068F, F28069F, F28026F, F28027F MCU part numbers.  InstaSPIN-MOTION includes the FOC/FAST capability but additionally adds the SpinTAC motion suite, with the main control library in on-chip ROM of the F28068M and F28069M MCU part numbers.

Projects are built-up using our MotorWare infrastructure. So a software project includes source code drivers, modules,  libraries, and main.c code that calls certain functions from the on-chip ROM.

3. There are videos, but these generally give big picture capabilities, they aren't training on the details of how to use the development software.  For using MotorWare the best document is to use the User's Guide for the Projects and Labs, and supplement with the full User's Guide to fill in the knowledge gaps.

Run C:\ti\motorware\motorware_1_01_00_11\MotorWare.exe to browse all content

C:\ti\motorware\motorware_1_01_00_11\docs\labs\instaspin_labs.pdf

User's Guide: www.ti.com/lit/SPRUHJ1

Thanks for the advice again Chris.

Am I correct in thinking that the DRV8301-69M-KIT is a ready-built solution that would work with the new position control code, in that it comes with an F28069F controller card ?

Sorry that I'm so ignorant on the capabilities of your processors, but what's the best solution for my application, a direct-drive PMSM motor, coupled to an Avago AEAT-9000 absolute encoder ? The encoder gives 17-bit absolute position data on an SPI link, incremental outputs, and also sine and cosine outputs that can be used to give very high resolution position information, when used in conjunction with the processor's A to D's. Obviously, high resolution on position is important in a direct-drive application.

I'm wondering if I have a big job ahead of me to take your position control code and modify it, to take position feedback from the sine/cosine encoder outputs and absolute position information from the SPI output of the encoder. I've got plenty of C experience in this kind of application, but none with your processors and development systems. What would be your view on this ?

Geoff

"Am I correct in thinking that the DRV8301-69M-KIT is a ready-built solution that would work with the new position control code, in that it comes with an F28069F controller card ?"

Not sure what you mean by ready-built. The DRV8301-69M-KIT comes with the F28069M controlCARD (which is a superset of the F28069F) and can be used to develop an InstaSPIN enabled drive.  There is a GUI that can be used to demonstrate the sensorless capability and then multiple projects in MotorWare that can demonstrate

• sensorless (FAST software observer) Torque control using your motor
• sensorless Speed (PI) and Torque control using your motor
• sensorless Speed (SpinTAC) and Torque control using your motor
• sensored Speed (SpinTAC) and Torque control using LVSERVOMTR
• sensored Poistion+Speed (SpinTAC) and Torque control using LVSERVOMTR

"but what's the best solution for my application"

Depends on your experience level, but the InstaSPIN-MOTION suite will dramatically increase how quickly you can create a full control solution with premium performance. It's certainly what I would use if doing motion control.

"I'm wondering if I have a big job ahead of me to take your position control code and modify it, to take position feedback from the sine/cosine encoder outputs and absolute position information from the SPI output of the encoder. I've got plenty of C experience in this kind of application, but none with your processors and development systems. What would be your view on this ?"

For Position control the InstaSPIN-MOTION solution just needs an electrical angle as feedback, which you have readily available. It will be very straightforward and you should have a fully working project in less than a day (and once you have some experience you should be able to do the same in about an hour).

Chris, 

I'm working though the Motorware labs right now and I notice there isn't much text in the "InstaSPIN Projects and Labs User's Guide" for labs 7 - 10.  I'm very interested in lab 9 (field weakening) but I'm curious if this lab even works.  I'm running lab 9 right now (reaching the speed limits of my motor with 100% current in the Q-axis) and when I enable field weakening, I do not notice a difference in my motor speed. I'm attempting to watch Id_A, Iq_A and Is_A in the watch window but the variables are jumping all over the place.  I'm using the DRV8301 with the 28069 chip but I have a reletivly small motor for this board (18v, 3A).  Is my ADC reading not accurate enough for this low of power?

Geoff,

For you application, you can start using the incremental outputs to control your motor and prove the solution using a TI evaluation kit.  When you design your own board, you could add hardware in order to decode the sine/cosine outputs and convert that into an electrical angle or use the SPI link in order to get absolute position information.  

We are working on developing a guide to getting your own motor to run in position control with InstaSPIN-MOTION.  I will be happy to share once it is completed.  

Here is the short version:

• Run lab 2a (or 2c if you motor is low inductance) to get your motor's parameters
  • Make sure that your motor spins anti-clockwise when doing the parameter identification
• Run lab 5c to get your system's inertia & friction
• Run lab 12 to confirm your encoder wiring
• Run lab 13a to tune InstaSPIN-MOTION Position Control

Thanks very much for the valuable advice Adam.

I'd intended to use the absolute position via the SPI link for the electrical angle, then use the sine/cosine outputs to form a high resolution position value for the position loop feedback signal. 

I'd be very grateful if you'd let me have a copy of your user guide when it 's finished. In the meantime, would the DRV8301-69M-KIT be the best evaluation system to buy for this application?

Geoff,

Once it is available we will pass it along.

If the DRV8301-69M-KIT meets the current and voltage requirements I would recommend it as the best evaluation system.  

Hi Adam,

I've bought the DRV8301-69M-KIT now, as it seems clear that you and TI have done so much of the work on FOC already. Also, the 69M has the INSTA-SPIN and SPIN TAC routines built-in, plus it has, amongst other things, much better ADC capability than the processor I'd intended to use. One question, is there any specific advantage to having library routines in ROM ?

Do you have any idea when the guide document you're writing will be completed ?

Geoff

Goeff,

There are a couple big advantages to having library routines in ROM.  The first one is that if you use the library routines in your project they can be linked from that memory location and won't need to be stored in FLASH/RAM.  Those library routines also have a faster execution time when called out of ROM, since it has the same wait states as RAM.  And finally, the ROM allows us to protect our intellectual property.  Both TI & LineStream have invested in the intellectual property that are in the ROM of the F28069M device and the ROM allows us to provide it with out the possibility of it being stolen.

The guide that I'm working on for how to commission a position controlled motor is almost complete.  It is in the review stages right now.  It will be available next week.

Adam,

Looking at the near 500-page User's Guide on InstaSPIN, it's easy to see just how much effort you've put into this and How you'd want to protect it.

Great news that the position control guide is nearly finished and I look forward to seeing it next week

Geoff

Hi Adam,

How's it going with your guide on how to commission a position controlled motor, because I think I really need it !?

I've spent the last couple of days getting familiar with CCS, getting my motor spinning with the Insta-Spin GUI, and starting to work through the Labs.

I must say that the amount of documentation and code in the Labs is very daunting, and difficult to follow. I really hope your guide can help me because I can see it taking me a long time to get where I want to be.

I'm hoping that I'll quickly be able to get the motor following a position profile with your help but then there's the question of adding things like CAN communication to an external device, interfacing to sine and cosine signals on my encoder and decoding position etc. I'm fine with the C code I've already got for these tasks, but I've currently no idea how to add this into the 69M code.

Is there any way to get detailed help on all of this and cut down the effort on my part ? I'm wondering what TI and your company can offer in this ?

Geoff

Geoff,

I apologize about the delay in completing this document.  I wanted to make sure it was the most helpful.  I've attached the first version.  It should help you walk through the steps to get your motor up and running in position control.  It does rely on the MotorWare lab guide for instructions for each specific lab.

Things like adding CAN communication and sine/cosine encoder interfacing can be done using the drivers that are provided in MotorWare.  There are drivers included for all of the peripherals on the 69M device.  The forums or your local TI rep would be the best support path for working through adding these features to your product.

5582.InstaSPIN-MOTION Position Commissioning.pdf

Hi Adam,

Please don't apologize, I'm just very grateful that you've taken the trouble to produce this guide. I've had a quick look at it but will study it properly tomorrow and try to get the motor and encoder going.

I must say that I've been very impressed with the forum support, but there just seems such a contrast between the extreme simplicity of making insta-spin do what it says with a motor, and studying and understanding the complexity of the code to make it do this.

I'm in the UK so is there be a local rep over here with the necessary knowledge to help in this area in addition to the excellent forum help ? Maybe someone from TI needs to answer this question ?

Looking forward to trying your guide tomorrow !

Geoff,

I don't disagree with you in principal.  There are things we could do to encapsulate even more of the code logic into simple function calls. There are obvious examples where this would simplify the main.c code significantly for a user.

For this solution to really work across all inverters, motors, and applications - and for us to have any chance of making a supportable and reproduceable control system -  there certainly does have to be some flexibility (which leads to complexity) in the way the entire control system operates.

It certainly is daunting for many.

Unfortunately I don't think you will find any expertise in our solution at the local level from a TI or distribution partner. They just don't have the bandwidth to focus and specialize on certain solutions. 

Chris,

I can see that you have a bit of a conflict between flexibility and ease of use. Where I find things difficult  is facing all the complexities at once, of unfamiliarity with your processors, CCS, and object-oriented C design, amongst other things.

However, I can see that there's not an easy answer to that, so as long as you don't mind me bombarding you with what may be trivial issues to you, then I feel a lot happier. Your support and Adam Reynolds' has certainly been great so far.

Adam,

I've started going through your Position Commissioning Guide today, and it's thrown up a few questions

1. In section 4, you say that the motor must spin in an anticlockwise direction to align the motor and encoder. I don't fully understand this because the direction depends on which end of the motor shaft you're looking at doesn't it ? Clockwise at one end is anti-clock viewed from the other end isn't it, so presumably you mean in some relation to the encoder ?

2. When I use the GUI to identify the motor parameters, I get some sensible values like Rs= 3.01 ohms (the datasheet value is 2.8 ohms), but Lsd and Lsq are silly values like 9.9e-7, when the datasheet value is 0.85 mH. Also the motor starts spinning at about 18%, stops and then ditthers between 26 and 36 %, then starts rotating again in a slightly stuttering manner up to about 80%, then stops and immediately the progress bar shoots up to 100%. Does that make sense ?

3. In the identification settings in the left pane, Motor Pole Pairs is defined as 4, and my motor has 9. Does that matter for the motor ID routine ?

4. Where does the encoder alignment fit into this routine ? There's nothing to tell the GUI that an encoder is connected is there, so does this routine always check for a connected encoder ?

That's it for now. Sorry if some of my questions are a bit simple with perhaps obvious answers.

Geoff

Geoff,

1. With the motor shaft facing you, the shaft should spin in the anti-clockwise direction.  We need to get to the point where the motor and the encoder think that positive is the same direction.

2. It sounds like you will need to change the identification parameters on the left side of the GUI window in order to identify your motor.  If you mouse-over the fields on the left side there should be tool-tips that pop up in order to help you set those values.

3. The pole pairs don't matter for the motor identification routine, they are only used in the speed calculation.

4. We will setup the encoder once we are working on MotorWare Lab 12.  Prior to this step we need to identify the motor and the system inertia.  We typically do those identifications sensorlessly.  

No problem, I'm happy to help out.

Regarding Motor ID, you can try the GUI, but it sounds like you have a low inductance motor, in which case you will need to use lab2c which implements some rescaling to get correct values.  This is discussed in the Quick Start Guides.

If you post what you know about the motor we can give you advince on the ID parameters. Voltage, current, rated speed, poles.

Adam,

It's a bit different in my case because there isn't a motor shaft as such. The motor is frameless so there's a 130mm/ 5 inch plate at one end and the encoder at the other end, but for this purpose I guess the plate is the shaft.

I still don't quite get how the GUI knows to look at the encoder if it's doing sensorless identification. Is the GUI routine programmed to always look for an encoder ?

Thanks

Geoff

The InstaSPIN-MOTION GUI is just for sensorless demonstration, and can help with initial ID (though some motors can't be ID'd with the GUI and need to use the  MotorWare projects like 2c)

You need to use the MotorWare projects for examples of using the encoder as feedback for velocity or position feedback.

Chris,

What do you class as low inductance ?

The motor I'm using is an Aerotech S-130-39A, frameless direct-drive unit. Full details are available on the net, but for starters the Rs is 5.6 ohms and L is 1.7 mH (both are line-to-line values as given on the datasheet). BEMF is 75 volts/Krpm, but bear in mind that the application is for a direct-drive camera head, so the max rpm would certainly be less than 120rpm, more likely 60rpm.

Thanks

That's not low inductance by itself, but the ratio of R/L is over 2000, which is an issue for the standard motor ID.

You need to use lab2c which rescales some of the variables to allow for proper identification of the Ls.  That's if you are using sensorless.  You can just snter the values from the datasheet into the user.h file if you like, especially since you are going to use the encoder.

Very interesting motor with huge Bemf. You should be able to run this motor very slow sensorlessly, likely under 1 Hz.

What is the speed range of this motor?  The R/L suggests a high speed motor, and the Flux / Ls suggests a relatively large short circuit current.  Strange design to have the Ls so low if it is meant to be driven slow...I guess for start-up torque capability?

According to the datasheet the rated speed is only 2000rpm, stall current is shown as 15.2 amps. I won't be using this motor in my final design as I need one with a lower winding impedance to run off lower volts, but obviously with more amps. It'll be the same frameless direct-drive type though.

In my application the motor will normally be either static or moving very slowly, well below 1Hz, with occasional 'rapid' movements, which means 1Hz or slightly above.

Positional accuracy needs to be very good so I'm using a sine/cosine encoder that will give me a few million counts per rev.  It also needs to be very stiff and hold position against disturbances.

Would you suggest bypassing the 2c identification, entering the parameters from the datasheet into user.h, and moving on to which lab ?

2000 RPM with 18 poles (per datasheet) is only 300 Hz. This motor has an R/L of 3KHz.  Not designed very well, but it may be related to the overall Isc they want with the flux capability they have designs.

Since you are using a position encoder only, they only purpose of the InstaSPIN motor ID would be to set some initial current controller settings for you, based on R, L, and the controller frequency.  In this case I would just enter the Line-neutral values of the Rs and Ls in the user.h and just forgo motor ID entirely.

I would start with instaspin_motion proj_lab12 for inclusion of the encoder, and then move on to the _lab13a-e series for position control.  BTW - the MotorWare.exe didn't get updated properly to show/market the lab13s, but they are in the Lab User Guide and source is included.

C:\ti\motorware\motorware_1_01_00_11\docs\labs\instaspin_labs.pdf

C:\ti\motorware\motorware_1_01_00_11\sw\solutions\instaspin_motion\src

Thanks Chris,

I've been looking at the Lab1 today, just to try to get some understanding of how your system of peripheral drivers works, e.g. all the handle based code, and I must say I'm not getting very far.

Is there any documentation or tutorials that explain all this ?

Stepping through the code doesn't really help; for example, if I step through from obj->oscHandle = OSC_init(........., all that seems to happen is that this function is called with numBytes=3, a check is done for numBytes < sizeof(OSC_Obj), and because the sizeof (OSC_Obj) = 0, the test decides that this is true (8 < 0 ??), so it then does a 'return((OSC_Handle)NULL'; and exits the function.

No doubt all of this makes sense but I find it very confusing. I don't understand why it thinks 8 is less than 0, and why should it do nothing with this function other than set obj->oscHandle to a NULL value ? I had assumed this was setting up the processor's oscillator but it appears to be doing nothing.

I hope you understand how difficult it is to follow what's going on with even this very simple lab. Maybe I don't need to know all the details of how every little bit of code works, but I don't even have an overview understanding at the moment.

Even if I can get the more complex Labs running with my encoder, I would have no idea at all how to modify a program to change from say the quadrature encoder inputs to values obtained from the encoder's SPI absolute value, or how to decode a position value from the sine/cosine outputs. I know how to do all of the basic C code, such as the arctan decoding of sine and cosine, but not how to work this into this style of coding.

Hope you can help.

Geoff

Trey,

Thanks for your answer. I'll have to take some time to study it to know whether I understand or not, and as I'm in the UK, it's getting a bit late to do that today.

In the meantime can you explain why in the example I gave, a < test for 8 <0 equates to TRUE, or did I get something wrong in the way I read it ?

More importantly, are there any training workshops or documentation that would give an Idiot's Guide to the way you use this "object" style of programming. Maybe you could give an example of how a peripheral like SPI would be added and used in one of your labs ?

Which document explains in detail all the different objects for the drivers ?

Geoff

I've not had time to do anything on the Labs software since last week, so started looking again today.

Just to save me time can you explain how I cross-reference peripheral settings between all the documents ? For instance, I know that the PWM peripheral generates a trigger signal to start ADC conversions, so what's the best way of finding how and where the trigger point is set in the pwm waveform, where this is done in the InstaSpin software, and where the trigger value can be altered by the user ?

Which documents are the best to look at for full details on each peripheral, like the pwm and adc's ?

thanks

Start with the Software Coding standards, found in MotorWare.exe under resources, or directly at

C:\ti\motorware\motorware_1_01_00_11\docs\motorware_software_architecture.pdf

anything to do with the peripherals will be in the drv files, which are inverter board and device specific

ex:

C:\ti\motorware\motorware_1_01_00_11\sw\drivers\drv\boards\drv8301kit_revD\f28x\f2806x\src

I recommend using a text editor like Notepad ++. It's easy to expand/collapse code and search for items.  You can also use CCS. I don't like the editor as much, but inside a project all of the files and #defines are linked, so it's easier to follow their reference.

Regarding documentation.

For the software: use MotorWare.exe and browse the index'ed HTML based doxygen documenation.

For the peripherals: Review the Technical Reference Guide for your device, ex:

http://www.ti.com/lit/pdf/spruh18  from

http://www.ti.com/product/tms320f28069m

I'm running Lab01 and trying breakpoints and single stepping in the program, and I have two questions.

1.  If I put a breakpoint on a line like DRV_writePwmData(drvHandle.............); in the mainISR, then run the program in debug, the code doesn't halt at the breakpoint. A breakpoint further back in the routine at gLEDcnt=0; does work. Why is this ?

2. When single stepping through the C code, sometimes the flow seems to go backwards then forwards again. Why is that ?

Thanks

Adam,

I've not been able to do much on trying out your Position Control Guide recently, but got back onto it today, without much success.

The Lab 2a and 2c both seem unable to identify my motor parameters correctly, with 2c identifying Rs correctly, but getting the inductance values way below what the datasheet specifies them as.

I then put values into user.h for the instaspin_motion lab05.c project and tried that, but it wouldn't run the motor and there was a lot of screeching and jittery movement of the rotor. Is this because the current loops haven't been tuned by the lab 02 ?

I really don't know where to go from here, as I don't really understand where loop tuning is supposed to occur to allow lab05c to work.

Below are the values I placed in user,h --

#define USER_MOTOR Aerotech_S130_39_A

#if (USER_MOTOR == Aerotech_S130_39_A)           // Name must match the motor #define
#define USER_MOTOR_TYPE MOTOR_Type_Pm                    // Motor_Type_Pm (All Synchronous: BLDC, PMSM, SMPM, IPM) or Motor_Type_Induction (Asynchronous ACI)
#define USER_MOTOR_NUM_POLE_PAIRS (9)            // PAIRS, not total poles. Used to calculate user RPM from rotor Hz only
#define USER_MOTOR_Rr (NULL)                      // Induction motors only, else NULL
#define USER_MOTOR_Rs (2.8)                          // Identified phase to neutral resistance in a Y equivalent circuit (Ohms, float)
#define USER_MOTOR_Ls_d (0.0085)              // For PM, Identified average stator inductance (Henry, float)
#define USER_MOTOR_Ls_q (0.0085)                   // For PM, Identified average stator inductance (Henry, float)
#define USER_MOTOR_RATED_FLUX (0.288)                  // Identified TOTAL flux linkage between the rotor and the stator (V/Hz)
#define USER_MOTOR_MAGNETIZING_CURRENT (NULL)                   // Induction motors only, else NULL
#define USER_MOTOR_RES_EST_CURRENT (1.0)                            // During Motor ID, maximum current (Amperes, float) used for Rs estimation, 10-20% rated current
#define USER_MOTOR_IND_EST_CURRENT (-1.0)                             // During Motor ID, maximum current (negative Amperes, float) used for Ls estimation, use just enough to enable rotation
#define USER_MOTOR_MAX_CURRENT (3.82)                                  // CRITICAL: Used during ID and run-time, sets a limit on the maximum current command output of the provided Speed PI Controller to the Iq controller
#define USER_MOTOR_FLUX_EST_FREQ_Hz (20.0)                    // During Motor ID, maximum commanded speed (Hz, float), ~10% rated
#define USER_MOTOR_ENCODER_LINES (2048.0)                    // Number of lines on the motor's quadrature encoder
#define USER_MOTOR_MAX_SPEED_KRPM (3.0)                        // Maximum speed that the motor
#define USER_SYSTEM_INERTIA (0.02)                                        // Inertia of the motor & system, should be estimated by SpinTAC Velocity Identify
#define USER_SYSTEM_FRICTION (0.01)                              // Friction of the motor & system, should be estimated by SpinTAC Velocity Identify

Geoff,

In lab 05c,  we are still using the sensorless estimator in order to spin the motor.  We also automatically tune the current loops using the motor parameters that are set in the user.h.  This is done by the function calcPIgains in the main source file.  If you take a look at lab 05a it talks about adjusting the tuning values of the current loop.  If you want to manually tune your current loops that would be the place to start.

When you entered the motor parameters in the user.h did you take a look at section 6.8.1 of the user guide (http://www.ti.com/lit/pdf/spruhj1)?  This section talks about manually entering your motor parameters from a datasheet.  

Adam,

Yes, I did follow the recommendations in section 6.8.1 of the user guide, so I'm pretty sure I got the values for resistance, inductance and flux correct. They are all set to the datasheet values in the user.h file of both the relevant instaspin_foc and instaspin_motion sub-directories.

I have now followed the instructions for Lab 05a, calculated the value for Ki series, built and run the Lab software, and looked at the value of Ki_Idq in gMotorVars. This and all other values in gMotorVars = 0.0. Single stepping through the program, I can see that the correct values from user.h are copied into pUserParams but these values are never transferred into gMotorVars, and consequently the application does nothing to run the motor.

Can you suggest where I'm going wrong as I think I've followed the instructions for running Lab 05a correctly ?

Also, I still don't understand why it is that when I single-step through the code that the cursor and program-flow often takes a step backwards before proceeding forwards. Why does this happen ?

Geoff

Chris, 

I'm trying to work through the InstaSpin Labs and finding the process pretty frustrating. 

I don't understand why it is that when I single-step in C, the flow moves backwards frequently, instead of moving forwards as expected.

For instance, I'm at line 111 in user.c "pUserParams->motor_ratedFlux = USER_MOTOR_RATED_FLUX;", I press F5 to single-step and the cursor moves back to line109, why??. Then it moves on to line 110, then on to line 111, where I started, then on to 112. Similarly I'm at line 136, press F5 and the cursor jumps to line 140, then goes back to 136, then 137, 138, misses 139, then ends up back at 140.

I'm already finding it difficult following the flow of this code, but all this jumping around makes it 10 times worse !

Also, if I use the "Search" button to find occurrences of some text such as USER_MOTOR_NUM_POLE_PAIRS in the workspace, it reports 30 instances and details them in the search window, but it doesn't find an occurrence  in Lab05a, which is the one I'm working on, and which of course definitely does contain this text.

Can you help me out on this ?

Geoff,

Sorry you are feeling frustrated, I've been there myself.  I can tell you that single stepping through all the support files isn't going to help you understand the flow, it's only going to confuse you more. 

If you want to understand the architecture I'd look at one of the proj_lab##.c files as a starting point.  And working through the InstaSPIN Projects & Labs User's Guide teaches you about all the necessary software interactions.

Take your 5a for example, you will notice the structure is

globals & some ifdefs
main
mainISR
and then three functions defined: updateGlobalVariables_motor, softwareUpdate1p6, calcPIgains

mainISR is straighforward:
- toggle LED @ rate
- ACK the main Interrups
- Read ADC values
- CTRL_Run: you will want to review this in ctrl.c as it is the main control system. The actual run-time functions are in ctrl.h as either
CTRL_runOnLine_User (from user memory) or
CTRL_runOnLine  (from ROM)

- Write PWM values
- Setup controller for next run
- Return

main
- the first section may be new to you due to how we pass data by handles to let different code functionality access the same information, and set-up initial variable values. This is how we use the user.h information as inputs in the the Driver, Control, and Estimation systems:
- USER_setParams(); from user.c you can see that this function passes variables through from user.h definitions to a UserParams structure with pointer
- DRV_setParams(); from your board/mcu specific drv.c you can see that this function uses information in the UserParams structure to set-up everythign related to a peripheral driver
- CTRL_setParams(); from ctrl.c you can see that this function uses information in the UserParams structure to set-up everything related to the control system, which includes setting up the default EST parameters

- following this is normal initialization and enable functions

then we go into the background for();; loop which is two paths, Disabled or Enabled
- While Disabled it disconnects the Iq reference, disables the PWM outputs, and runs the CTRL_setParams function again (so anytime you toggle to Disable it resets the entire system)

- While Enabled
- creates an object so you can access the CTRL variables in RAM
- counter update
- user interface from gMotorVars to the Flags for enableUserParams, RsRecalc, and OffsetRecacl
- CTRL State Handling before the "motor is identified flag" which allows you to start the control
- State logic once motor is identified

a) write over the MaxcurrentSlope in the estimator (too high by default)
b) set the gMotorVars flag that the EST thinks the motor is identified
c) if the softwareupdate check hasn't been done, do it; this is a fix for a bug in how the Ls variable is passed from user.h to UserParams for the Estimator
d) recalcualte the PI gains (insures proper gains are calculated) & fetch into the gMotorVars structure

- finally, updating of the global variables as appropriate. This is necessary because some of the variable information is inside the CTRL or EST memory region and must be access and pulled to a gMotorVars structure.

Geoff,

Expect to spend 1 year to learn TI C2000 Piccolo digital signal controllers. Especially it takes time to learn their ADC and EPWM modules.I found Learning CD ROM disc for students and use it. Also see C2000 Piccolo Multi-Day Workshop.

It is a powerful DSC for power electronics but requires investment of time.

Chris,

Thanks a lot for your very detailed reply, I'll print it out and try again with 05a.

On a more general point, in some ways it's reassuring that I'm not the only one that finds this complicated, but seeing Andrey's observation :-

"Expect to spend 1 year to learn TI C2000 Piccolo digital signal controllers. Especially it takes time to learn their ADC and EPWM modules.I found Learning CD ROM disc for students and use it. Also see C2000 Piccolo Multi-Day Workshop.

It is a powerful DSC for power electronics but requires investment of time."

which was in the next post after yours, it's also a bit disturbing. The fact is that I can't afford to spend a year, or anything like that, learning about this processor. Perhaps mistakenly , I assumed that "instaSpin" meant something approaching what it implies, and that by using all the code you've developed, I could get my project up and running fairly quickly. Not that I expected it to be completely straightforward, but just getting the Labs going seems to be quite a task.

The bottom line is, am I pursuing something that I'm not going to get going without investing months of learning time, or is it feasible that I can continue to get the kind of detailed help you've just given me ? I just don't want to waste my time trying to do something that's not possible in a reasonable timescale.

Geoff

Andrey,

Thanks for your observation on the scale of the task to learn about the C2000.

I've used your post to ask Chris at TI whether I'm wasting my time trying to attempt my project this way. I simply can't afford to spend the length of time you're indicating on studying and learning this.

I had hoped that using all the Instaspin code developed by TI would get me going quickly, but it doesn't seem to be that easy.

Geoff

No offense to Andrey, but he hasn't evaluated InstaSPIN or MotorWare (I saw a post where it looks like he as started).  His comments were on our MCUs.

I'd say that most applications that use a C2000 do take 18-36 months from kickoff to full production. Power electronics is very complex (even for simple projects) and most customers do extensive field/quality testing before they take a product to market that has an electric motor.

I will agree that in general our C2000 isn't the easiest to use for a beginner vs. general purpose MCUs. There is a tremendous amount of flexibility we have built into the peripherals based on 20+ years of power electronics control...and customers still come up with new waveform and sampling patterns that send us back to the drawing board.  And in the past our software has been of a different variety than what many are used to.  The controlSUITE software is actually very user friendly if you are new to writing software.  There is a pretty clean framework, and you wire up modules like blocks, setting an output of one as an input to another.  But we never abstracted any of the peripheral configuration, so you have to go down to the peripheral register and set the modes of each register.

With MotorWare and our InstaSPIN solutions we took a more modern approach.  The code is all in latest object oriented C, peripherals are all abstracted into functional API calls, code that can be re-used across MCU and Inverters are modularized, and we've built an entire state / control / timing system that is rigid in it's form but flexible its functionality. 

The MotorWare InstaSPIN solutions are incredibly easy to use to adapt a project to your settings (voltage, current, filter, PWM timing, sampling, etc).  We can take the same set of projects and very quickly have it running on a new MCU, new inverter, and new motor. That is revolutionary!

As a user, this is a huge benefit.  If you just want to add some simple communications and base your design off of ours, you can spin a product VERY quickly.  I know a customer evaluated it and then 1 month later had his product at a tradeshow running with InstaSPIN!!!

But, if you are the type who wants to single step through every line of code, you are going to see that to reach this level of flexibility and portability there is a tremendous amount of infrastructure in place that we had to construct.  You may not want to know how the sausage is made!

Further confusing the situation is the ROM aspect...or really the fact that this overall state / control / timing subsystem must be followed, and a portion is in ROM.

As a new user you may say, "why don't you just give me a FAST function" to call that returns the angle, speed, and torque estimated?  Well, FAST depends on the inputs from the system, and those must be taken at certain times and updated at certain times, so you end up needing to insure that for customers to be happy with the results things need to happen on a schedule.  Add in that we want to provide Motor ID and auto tuning capability and you quickly see the need for a "rigid state framework with built-in flexibility".  It's as flexible as we made it....and with that comes some additonal complication & confusion.

I can't tell you how long it will take you to digest what is needed for you to make a product.  It depends on how deep you want to go and if you speak the same "modern, object oriented C language".  I can tell you that I do NOT speak that language natively and it certainly slowed me down.  Others are fluent and I've seen peope on this forum take to InstaSPIN/ MotorWare much faster than I ever did.

I will also add that what InstaSPIN provides in sensorless speed/torque or sensored position/speed applciations is far, far, far superior to anything else available from an MCU supplier in terms of quality of solution, time to spin, and time to full control.  Magnitudes of order different.

It's not perfect yet, but we're working on it!

Chris,

Hope I didn't come across as being critical of what you've produced because that wasn't the intention. I really just want to get a realistic picture of what magnitude of task I have to get something going.

I've already spent a lot of time on this project trying to get an FOC solution going on a PMSM, using a more general purpose microcontroller, with some, but not complete success. That means I'm at least pretty familiar with the fundamental aspects and requirements of FOC. I've also built a motor drive using your DRV8301 successfully.

What I came to realise was that the MCU hardware I was using was inadequate for the task (and to some extent the firmware code), whereas the F28069M clearly has the required capabilities, along with the well proven and advanced code modules. I'd really like to use your solution but the Object Oriented C is a bit of a nightmare for me to get to grips with.

So, I just want to ascertain whether I can realistically do this in the time available. I fully realise that you can't say how long it's going to take me to learn this, but can you tell me if there are any routes to speeding the learning process such as tutorials, documentation, courses etc ?

I'm based in the UK, which I guess makes things difficult in terms of getting local support and help, and maybe courses as well ? Have I already got all the learning materials available to me ?

I guess my ideal would be to be able to sit down with someone who could walk me through the code, but I doubt if that's not going to happen, even if I paid for it.

By the way, do you have any explanation for the apparently odd behaviour when single stepping through code, e.g. stepping backwards, and jumping lines of code ?Is it related to the route through the assembler code ? I accept that single-stepping is not the way to learn, but it will probably be required if I do get to the point where I need to add my own code.

Geoff

Geoff,

Maybe we should do a reset. Where are you at with the evaluation today?

Can you ID your Ametek motor and run with InstaSPIN-FOC in sensorless (FAST feedback) mode

using the GUI?

using lab2a?

using lab5b?

I believe you are also trying to use an encoder for feedback, correct?  Is this speed or position control?

Where does this portion stand?

"By the way, do you have any explanation for the apparently odd behaviour when single stepping through code, e.g. stepping backwards, and jumping lines of code ?Is it related to the route through the assembler code ?"

I do not, I'm trying to get an answer for you. 

Chris,

Sounds like a good idea.

By the way it's an Aerotech S-130-39, Direct-Drive motor, not an Ametek. I should let you know that I'm also having an email discussion with Adam Reynolds on this problem, and he's been doing his best to help me.

Also, I'm sorry that this is going rather slowly at my end, but I'm trying to keep two different projects going at the moment.

As far as the current state is concerned, I did run the motor from the GUI and Lab2a, but I'm pretty sure it didn't identify the parameters correctly, and it certainly got a value for stator inductance way below what it should have been.

I then went on to run Lab05a, entering values into user.h in line with the calculations shown in this lab, from datasheet values. I ran the motor using these values and the performance wasn't good. Adam thought that the Ki value was correct for the L and R of the motor to get PI loop stability, but the Kp value of around 36 created a lot of screeching from the motor which only reduced to an acceptable level when Kp was reduced to around 3. In addition to the screeching, the rotor was randomly kicking by a few degrees. Adam has suggested that the rotor electrical angle may not be being calculated correctly from the sensorless algorithm.

When I entered a non-zero current loop demand value, the rotor did spin in the appropriate direction for the demand polarity, in an open-loop fashion as expected.

That's where I am at the moment. Adam's has asked me to send him a copy of my user.h file, which I haven't done yet.

The final design is to use an optical encoder with sine/cosine outputs in addition to incremental outputs. I will probably only use the sine/cosine outputs in the end, feeding them into ADC's and doing an arctan calculation to give me high resolution position. The control needs to be position control with the motor rotor having a very low speed range, from zero rpm to about 60 rpm max. None of the encoder functions are currently working, it just has the incremental outputs wired into the development board.

Hope this makes things clearer. 

Thanks again for your continuing help.

Geoff

Geoff,

Let's look at this motor:

If you are using the B winding:

160V Bus, with 150V of Bemf @ 4,000 RPM (600 Hz on 18 poles)
5.4A RMS
Rs = ~ 0.7 ohm L-N
Ls = ~0.2mH L-N

R/L = 3500

This is over the limit of 2000 in our code, so you must use proj_lab2c for motor parameter identification.  In this project we rescale the resolution of the variables for Ls, gains, etc. to complete ID. Once you have the values you can move to the projects as normal.

The problem is that we only released proj_lab2c for the DRV8301 based kits, because these types of high R/L motors are typically low voltage / higher current. It's very rare to find a high voltage version.

You have two options
1. Use a DRV8301 kit with ~50V bus. You should still get good parameters for this motor at the reduced bus voltage.
2. Set-up the proj_lab2c for your HVKIT.  You are using the HVKIT, right?

On option 2

I copied over

motorware_1_01_00_11\sw\solutions\instaspin_foc\boards\drv8301kit_revD\f28x\f2806xF\projects\ccs5\proj_lab02c

to

C:\ti\motorware\motorware_1_01_00_11\sw\solutions\instaspin_foc\boards\hvkit_rev1p1\f28x\f2806xF\projects\ccs5\proj_lab02c

in the three project files there are 3 references to "drv8301kit_revD" that need to be updated to "hvkit_rev1p1" and there is one linked file for "gate.c" that can be deleted completely (only for the DRV8301, not used by other inverters).

With that I can now import and build

C:\ti\motorware\motorware_1_01_00_11\sw\solutions\instaspin_foc\boards\hvkit_rev1p1\f28x\f2806xF\projects\ccs5\proj_lab02c

I haven't testing the operation yet, but it should work.

I've ziipped up the proj_lab02c folder and attached as a .piz file. Just rename .zip and place at

C:\ti\motorware\motorware_1_01_00_11\sw\solutions\instaspin_foc\boards\hvkit_rev1p1\f28x\f2806xF\projects\ccs5\

Geoff,

Just reading through the thread again and it seems like you have the BOOSTXL and DRV8301 EVM, so you should be set on using proj_lab2c to ID this motor.  I would certainly use the DRV8301 EVM for this and run at ~50Vbus if you can.  You should get expected values. 

But I want to point out that the motor you have runs off 160V bus for full performance. Running at 50V means you will get less than 1/3 of the maximum speed.

It seems to me that if you want to use this motor to its maximum level you should use TMDSHVMTRINSPIN kit for testing.

Chris,

Thanks for your latest advice. There are just a few points I thought I should clear up.

1.   My motor is the A winding, not the B, so R=2.8 ohms, and L=0.85mH, and R/L is still 3294 which is obviously over your 2000 limit.

2.     I'm doing all the development work on a DRV8301-69M- KIT, not an HVKIT and not the BOOSTXL.

3.     I'm not worried about getting the best performance in terms of speed out of this motor, in fact I require very little in the way of speed. The motor will be rotating its load, a camera, which is mounted directly on the rotor. The motor will normally never move more than one complete rotation, at a speed nor greater than one rev per second. Most of the time it will be rotating at speeds MUCH lower than one rev/sec, and by a fraction of a rotation. Positional accuracy is of paramount importance, not speed.

4. The final design will use a motor with a much lower stator resistance, to allow operation from a 24 to 36 volt battery, but this is the test-bed motor for now.

One question is, does the motor supply have to be no less than 50 volts for Lab02c to do the ID correctly ?

Geoff