This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

can I use EST_Obj without CTRL_Obj (28027F)?

Hi Chris,

I think CTRL_Obj has included too much function. I've already  validated  my own vector control and state machine. If I  want to use only FAST lib,what can i do to deal with some ctrl fuction,such as CTRL_setUserMotorParams. Will some new labs without CTRL_Obj launch?

  • hi hao,

    you will notice that as you start the Project & Labs  you are running everything from on-chip ROM (on the F2806x at least, for the f2802x the ROM doesn't have all contents so you are already running with control code in user memory).

    I suggest doing a DIFF between the functions

    CTRL_runOnLine (code that is in ROM) and CTRL_runOnLine_User (now running the control code from user memory), both which are found in ctrl.h

    If you want to change any of the forward control elements - but still want to use our control system framework - you would updaet CTRL_runOnLine_User as you wish.

    It sounds like you want to go one step further though and not use anything to do with CTRL_ at all, correct?

    If you want to use the Motor ID features this isn't possible. You'll always have to keep the control framework and call things throught the CTRL_ interface that we provide (from ROM).

    But, if you don't want to use the Motor ID features and just want to load parameter into FAST (EST) and use as a software feedback sensor you CAN completely create your own control system, load seetings into the EST and just use
    EST_run

    to run the EST functions and then of course use the EST_get functions to retrieve feedback.

    For most customers I think this would be foolish to "re-invent the wheel" (and you might end up with a square one ;) ) but if you are a very experienced sensorless motor drive designer and just want to upgrade your estimator, this will work.  Again, because we consider some of the state machine as our IP, if you want to use the Motor ID feature it relies on running the entire control system and would not be worth the effort to try to get working with your own.

     

    We don't have any plans right now to create a project that doesn't use any of our control system, but just calls FAST.  I'll add this to our feature list tracking (but it will be low priority). 

     

  • Hi Chris,

        Thanks for your reply. It seems very hard to change the program architecture of instaSPIN.

        Our product is the inverter of traction motor. I use Fast estimator as a backup of speed sensor besides resolver or hall. You know,28027F don't have enough resources of Flash and Ram. If  useing 2806xF, I don't care this. 

        Another question,If I use High frequncy injection (of course 2806xF for IPM),Fast estimator will be run ok? I used to use this fuction to drive IPM at low speed. The current ripple is really not beautiful.

  • hao,

    "It seems very hard to change the program architecture of instaSPIN."

    No, we just haven't made this obvious, as we don't expect most to use InstaSPIN in this manner. 

    To run the Estimator (FAST) it is really as simple as running EST_run() with the currents, voltages, bus voltage, and at least a speed_ref_pu (although you can bypass, you still need to pass a variable data).  The control system will control the rate at which it runs, and EST_set and EST_get any other needed values.

    extern void EST_run(EST_Handle handle,
                 const MATH_vec2 *pIab_pu,
                 const MATH_vec2 *pVab_pu,
                 const _iq dcBus_pu,
                 const _iq speed_ref_pu);

     

    It should be possible to add this to your existing control system.

    "If I use High frequncy injection (of course 2806xF for IPM),Fast estimator will be run ok? I used to use this fuction to drive IPM at low speed. The current ripple is really not beautiful."

    If this this your own HFI in your own control sytestem then  yes, especially if you are just using FAST as a back-up software sensor, it should be no issue to run this in // with your HFI (and even your resolver/hall).  Then you can compare all three and decide which to use.

    We will begin showing some ways to use the InstaSPIN control system with various initial and slow speed rotor position (let's call them all IPD_xxx for simplicity)  techniques very soon - probably MW _13 - and how to seed our ForceAngle trajectory generation and switch back and forth between FAST and the IPD techniques.