Using FAST alone

Roger,

My recommendation is that you start with a proj_lab##.c that best fits what you want to do....then follow through that proj_lab##.c looking at every CTRL_ command.  For each CTRL_ command you should go understand the code that is being run and note if it's for part of the forward FOC or for the Estimator: ctrl.c and ctrl.h

You should pay special attention for anything that references the estHandle of course.

CTRL_ is OUR control system....you already have your OWN control system. So you will see what you need to pull out for using the functions we use in CTRL in your own CTRL.

Example, let's use proj_lab5b.c, and find all the CTRL_ function:

You can tell that most of the CTRL_ functions are interacting with things in the forward control loop just by their naming.

The ones that may be of interest and you should realy dig into ctrl.c to understand:

CTRL_setParams(ctrlHandle,&gUserParams);
// key fucntion for you has to do with the estHandle
  // set the default estimator parameters
  CTRL_setEstParams(obj->estHandle,pUserParams);

CTRL_setup(ctrlHandle);
CTRL_run(ctrlHandle,halHandle,&gAdcData,&gPwmData);
// you will notice that if the motor is ID, you will runOnLine_User (which is what you will be doing, CTRL from user code, not the ROM), so it will be important for you to see how the EST is used in this function: 

          if(EST_getState(obj->estHandle) >= EST_State_MotorIdentified)
            {
              // run the online controller
              CTRL_runOnLine_User(handle,pAdcData,pPwmData);
            }

from ctrl.c go through each place where estHandle is referenced...that's interacting with the EST_

back to the proj_lab05.c:
Some _setFlag that seem like they might interact with the EST_:
CTRL_setFlag_enableDcBusComp(ctrlHandle, true);
CTRL_setFlag_enableUserMotorParams(ctrlHandle,gMotorVars.Flag_enableUserParams);
CTRL_setFlag_enableOffset(ctrlHandle,gMotorVars.Flag_enableOffsetcalc);
CTRL_setFlag_enablePowerWarp(ctrlHandle,gMotorVars.Flag_enablePowerWarp);

and of course the software patch which clearly loads new values into the EST_:
void softwareUpdate1p6(CTRL_Handle handle)
  // store the results
  EST_setLs_d_pu(obj->estHandle,Ls_d_pu);
  EST_setLs_q_pu(obj->estHandle,Ls_q_pu);
  EST_setLs_qFmt(obj->estHandle,Ls_qFmt);

You should also search the proj_lab##.c  for EST_ and note that most of the time we are just using EST_get to get values from the estimator. But there are few places we _set or take some logic based on a state/flag setting that could be useful for you in your own CTRL system.

 Line 234:         EST_setFlag_enableRsRecalc(obj->estHandle,gMotorVars.Flag_enableRsRecalc);
 Line 301:         if(EST_isMotorIdentified(obj->estHandle))
 Line 304:             EST_setMaxCurrentSlope_pu(obj->estHandle,gMaxCurrentSlope);
 Line 341:             gMaxCurrentSlope = EST_getMaxCurrentSlope_pu(obj->estHandle);
 Line 359:         EST_setFlag_enableForceAngle(obj->estHandle,gMotorVars.Flag_enableForceAngle);

Maybe you were looking for more of this work done for you already...but it isn't.  Plus, to really understand how to use the EST_ you really do have to see how we are using it in our own CTRL_ system.

Hello Chris,

Thanks for this info. However it does not really answer the question. I don't really want to develop my own software by reverse engineering someone elses code. That seems the wrong way to go about things! I don't do that in hardware or software design & I think leads to not understanding exactly what is going on. I'm not looking for the work to be done for me, in fact exactly the reverse.

To write your code you must have had some specs as to what things do what? Having that or some version of it would be the best starting point for those of us who want to fully understand and develop their own thing.

R

All of the functions are documented in the code. These can most easily be viewed in MotorWare.exe where the Doxygen comments are pulled into HTML.

That is the extent of what we make available.

Chris,

Yes OK.....

One more question before I give up!

EST_enable() is not declared in /modules/est/src/32b/est.h, but is declared in /modules/est/src/float/est.h ??

And it does not appear to be in the lib fast_spin_rom_symbols either float or not??

I made an (obviously wrong?) assumption that calling this may make the EST go from Idle to OnLine States. Or is that the EST to be enabled by actually enabling the CTRL (which I am not using)?

R

Running the estimator without the controller is not supported. The CTRL object is split into a public set of functions and a private set of functions in ROM that configure the estimator. Removing the controller completely is not supported.

Also, do not use anything from "float" folders as they are not used today. They will be used in a future floating point implementation of the libraries.

-Jorge

to add to Jorge's comments,

1. The "float" folders should not have been released. They are part of our working software infrastructure and should have been scripted out of MotorWare _12

2. I still think your initial request - intergrate FAST into your own CTRL system -  is valid and an acceptable use case. As I noted, without our CTRL_ you certainly can NOT use the Parameter ID portion (the state machine logic is in ROM and only accessed through CTRL_), but it also means you can NOT use Rs ReCalc, Offset ReCalc, Rs Online, or PowerWarp. That's pretty limiting.

 In our next generation of InstaSPIN (2015 new silicon) we have architected this a bit differently so that the CTRL_ we provide is quite simple (just PID processing, even modulation is pulled into its own function), and all of these state machine features are completely incapsualted and interfaced to through EST (ROM).

So in the the existing implementation:
- Many features in EST_ require our specific CTRL_ to configure and interface

In future implementations:
- Features in EST_ will NOT require our specific CTRL_

We are going to put it onto our to-do list to see if we can create a project example with today's implementation to give best flexibility in using your own CTRL...but if we find out this is going to be too limited and not worth the effort we will just want for next implementation.

Chris, Jorge,

Thanks for this. Yes that makes sense as the float stuff raised more questions than it answered.

It would be helpful if you could create that example you mentioned, as the '069 chip will be around for a while, then I could use it here.

As for the new silicon that sounds a good idea for the future but patience is not my virtue! When you write your examples for the new stuff do you think you could lay off all that object oriented stuff? This application is close to the hardware. Things aren't going to change much being burnt into ROM. And it is painful seeing all those functions to call that have 10-20 lines of code, and all its doing is what could be done in just one line! Plus can we have direct access to the structures in memory, It seems EST uses the reserved area of RAM in L8 on the '069. There's apparently no reason why we cannot write/read direct to structures in that area and that would simplify stuff greatly as well (yes we can figure out where these are I think, but easier just to document it). Yes let's keep it as simple as possible, if others want to write complex software overlays on top let them.

Regards Roger

Hello Chris,

I'm also wishing to use FAST algorithm without CTRL. Are there any news to this topic?

Is it at this time in some way possible to use FAST as a complete stand alone part of InstaSPIN? (Ideally even in a separate circuit, getting only current/voltage measurements and the motorparameters. Just replacing a mechanical encoder.)

Thanks.

-Martin

Martin,

MatLe said:

I'm also wishing to use FAST algorithm without CTRL. Are there any news to this topic?

as mentioned above we are not supporting / documenting this use case in today's implementation.

MatLe said:

Is it at this time in some way possible to use FAST as a complete stand alone part of InstaSPIN? (Ideally even in a separate circuit, getting only current/voltage measurements and the motorparameters. Just replacing a mechanical encoder.)

I know of a customer doing this today, but they are still using the CTRL system as is (although they are not doing anything with the forward control, the PWMs are turned off, in fact they are not even connected to any sort of circuit).  They have an interface board which they use to get currents and voltages from motor phases, then run the CTRL system (including EST), and then use the EST_get functions to pull relevant angle, speed, and torque information. They transmit this back to the industrial controller over SPI or CAN.

The limitations to this are that they can't do motor ID, so parameters have to be provided. They have no control over the inverter at all, this is just a way to use FAST purely as a sensor.

I had hoped this information was available. Since in order to write the combination EST/CTRL code there must be documentation on the EST code? All we need is a copy of that documentation I assume?

Roger 

Hello Chris,

I am also using Insta SPIN only as an encoder because I have my own current controller (insetad of standard PID).

Are there plans for future Insta SPIN version to provide FAST obeserver access without using CTRL_run() and CTRL_setup()?

Regards,
Wadim

In today's implementation on F2806x, 5x, and 2x you must use CTRL, though you can change out the speed, current, and modulation components as needed...but you still have to use the CTRL structure.  Yes, it's not ideal but we had to leave it that way to launch the product on time in 2013.

There will be NEW devices in 2015 that use a new version of the ROM. One of the changes will be that the EST can run independently.  That's all the details I can share on a public forum. This new ROM will ONLY be on new devices. The existing devices are NOT changing.

Hi Chris,

I gonna take this task..just visited this customer last week. We have NDA and I did show the upcoming devices and gonna point to the right one.

Thank you for ur support.

cheers

Karim