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.

FAST Flux Estimator Saturation

We're using the 28069 Control Card and a custom drive to control the output of a field-wound generator.  Other than an initial software hiccup, everything seems to be going well, but we encountered an oddity with the flux estimator.

We observed that the estimated flux is saturating, based on the value for USER_MOTOR_RATED_FLUX.  The measured limits are USER_MOTOR_RATED_FLUX/1.3 and USER_MOTOR_RATED_FLUX/0.7.  After reading the InstaSPIN User's Guide, and the code that reads the estimated value in per-unit (in the description of EST_getFlux_pu), it looks like the estimator a maximum value that's limited by a 0.7 scaling factor, which matches our measurements, but I can't find anything about a minimum value.  It also looks like the upper limit scaling factor is dependent on whether the machine is reported as an induction machine or a permanent magnet machine.

This is just based on what I was able to find in the manual and in that one function description, but here's my question(s).

Our flux constant is obviously going to change dramatically, dependent on how much current we apply to the field windings.  The estimator doesn't swing far enough to estimate the changing motor flux.  Is there a way to remove this limit?  What would happen if I declared the machine an induction machine?  Does the FAST estimator behave significantly differently?

If we can't remove this limit, is there any danger to re-writing USER_MOTOR_RATED_FLUX to the user params array and, subsequently, to the estimator while the system is operating?

Thanks,

Matt

  • Yes, you can configure this as an ACIM, and should work ok, as long as you set your magnetizing current as zero, and your Rr as 0. For example, a PMSM motor with this parameters:

    #elif (USER_MOTOR == Anaheim_BLY172S)
    #define USER_MOTOR_TYPE                 MOTOR_Type_Pm
    #define USER_MOTOR_NUM_POLE_PAIRS       (4)
    #define USER_MOTOR_Rr                   (NULL)
    #define USER_MOTOR_Rs                   (0.3968007)
    #define USER_MOTOR_Ls_d                 (0.0006708066)
    #define USER_MOTOR_Ls_q                 (0.0006708066)
    #define USER_MOTOR_RATED_FLUX           (0.03433958)
    #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          (5.0)
    #define USER_MOTOR_FLUX_EST_FREQ_Hz     (20.0)

    Needs to be changed like this:

    #elif (USER_MOTOR == Anaheim_BLY172S)
    #define USER_MOTOR_TYPE                 MOTOR_Type_Induction
    #define USER_MOTOR_NUM_POLE_PAIRS       (4)
    #define USER_MOTOR_Rr                   (0.0)
    #define USER_MOTOR_Rs                   (0.3968007)
    #define USER_MOTOR_Ls_d                 (0.0006708066)
    #define USER_MOTOR_Ls_q                 (0.0006708066)
    #define USER_MOTOR_RATED_FLUX           (0.03433958)
    #define USER_MOTOR_MAGNETIZING_CURRENT  (0.0)
    #define USER_MOTOR_RES_EST_CURRENT      (1.0)
    #define USER_MOTOR_IND_EST_CURRENT      (0.0)
    #define USER_MOTOR_MAX_CURRENT          (5.0)
    #define USER_MOTOR_FLUX_EST_FREQ_Hz     (20.0)

    The value of USER_MOTOR_IND_EST_CURRENT needs to be changed to 0.0, otherwise you will get a configuration error.

    A change like this though does not support motor ID, only running the motor with known parameters.

    Also, the flux limits for ACIM change to:

    Maximum: USER_MOTOR_RATED_FLUX * 1.2

    Minimum: USER_MOTOR_RATED_FLUX * 0.05

    So make sure your rated value is set somewhere in the middle, depending on the expected range.

    Give this a try and let us know how it works for you.

    -Jorge

  • Jorge,

    That worked pretty well. The full range doesn't quite get us to our maximum operating range, but it does cover all but the most extreme cases, and should actually work for what we need it to do.

    I'd like to try the alternative at some point, where we update the rated flux in the estimator while it's running. Is there any concern with stability if we do that? For this particular system it's not a big deal; we can actually freeze the field winding output at a fixed value and "reboot" the entire estimator, and once it's locked we can resume regulation. However, we anticipate at some point using this processor to drive a 3-phase inverter simultaneously with the field windings, and would need the system to operate smoothly through the transitions.

    Thanks again,

    Matt
  • I am glad it worked for you.

    Unfortunately there is no way of changing the rated flux while the motor is running. You need to stop the motor, and pretty much start all over again to configure a new rated flux, which isn't very practical.

    -Jorge

  • OK, that's good to know if we decide to use this for more field-wound generators.

    Is there a way to synthetically increase and decrease the limits on the flux estimator, before starting it? It's working really well so far, and it would be great if we could get all the way up to our maximum operating point.

    Matt
  • Yes you can change the value before starting the motor, but you need to call these functions with the final value of your rated flux (in this example using lab 11):

    USER_setParams(&gUserParams);

    EST_setEstParams(estHandle,&gUserParams);

    And also, you need to modify these functions so that it reads a variable from gUserParams as opposed to using the #define which you will be changing prior to running the motor:

    USER_computeTorque_Flux_Iq_pu_to_Nm_sf()

    USER_computeFlux_pu_to_Wb_sf()

    USER_computeFlux_pu_to_VpHz_sf()

    If you let me know which lab you are using, I can give you more details. The difference is that lab 11, 11a and 11b use a simplified interface to the ROM libraries, by not having a controller object which makes things a bit confusing if all you need is using the estimator.

    -Jorge

  • Jorge,

    We're presently using lab 4 as our template. We didn't have much time to adapt to lab 11 for this project, but we're going to definitely explore it when we get some extra time, in the name of simplifying our code.

    Are you talking about the rated flux value or the saturation limits? As far as I can tell, Est_setEstParams (or, in our case, CTRL_setEstParams) just updates the estimator with the values in gUserParams, which don't have any explicit limits. Perhaps those limits are related to the pole locations? I can't really tell, because there isn't a definition for those functions anywhere in the code, and there doesn't seem to be much discussion in the InstaSPIN User's Guide.

    I understand the issue with the computation functions.

    Thanks again,

    Matt
  • The limits are calculated based on the rated value and the motor type, so when you call CTRL_setEstParams(), which is executed in ROM, it takes the configured rated flux, and depending on the motor type it sets the limits and other scale factors. So if you call this function with the right parameters before running the motor, it should work.

    -Jorge
  • Jorge,

    Understood. What I really want to know is, are there any ways to break in and set those limits besides trying to trick the estimator into thinking it's an induction motor? The trick works for the most part, but it doesn't let us operate across the full range of our system. We'd like to be able to work at the operating limits without having to write our own flux estimator.

    Matt
  • I need to create a small .lib file that would do this. Give me a couple of days and I will send it to you. I need to know what device you are using though, is it a 2x, 5x or a 6x?

    -Jorge

  • Jorge,

    That would be awesome.

    We're using the 28069 for this project.

    Matt

  • Give this library a try, it only reads and writes the min and max flux value in per units (IQ24), and it does have some limits of minimum of _IQ24(0.51) and maximum of _IQ24(127). Let see if that works for you.

    EST_Flux.lib

    You need these prototypes:

    //! \brief      Gets the minimum flux
    //! \return     The minimum flux, pu
    _iq EST_getFluxMin_pu(void);
    
    //! \brief      Gets the maximum flux
    //! \return     The maximum flux, pu
    _iq EST_getFluxMax_pu(void);
    
    //! \brief      Sets the minimum flux
    //! \param[in]  min     The minimum flux value, pu
    void EST_setFluxMin_pu(const _iq min);
    
    //! \brief      Sets the maximum flux
    //! \param[in]  max     The maximum flux value, pu
    void EST_setFluxMax_pu(const _iq max);

    And this is how you call the functions:

    _iq gFluxMin_read_pu;
    _iq gFluxMax_read_pu;
    
    _iq gFluxMin_write_pu;
    _iq gFluxMax_write_pu;
    
      gFluxMin_read_pu = EST_getFluxMin_pu();
      gFluxMax_read_pu = EST_getFluxMax_pu();
    
      EST_setFluxMin_pu(gFluxMin_write_pu);
      EST_setFluxMax_pu(gFluxMax_write_pu);

    What I suggest is to use the "get" functions to see what the default values are depending on the rated value you set in your user.h, and then change it with the "set" functions, keeping in mind the limits mentioned above.

    -Jorge

  • Jorge,

    That worked great.  It does exactly what we needed it to do.  I only have one more question.  It seems like the value of the rated flux in User.h is actually about 1.7pu.  I did the calculation in est.h in the description for EST_getFlux_pu, and all that works out just fine, but I'm curious about what a flux of 1pu is equal to.

    All in all, you've been extremely helpful.  Thanks a million.

    Matt

  • I am glad it worked. The per unit value conversion into real world units is done by scaling it by this value:

    gFlux_pu_to_Wb_sf = USER_computeFlux_pu_to_Wb_sf();

    That function is in user.c, and it depends on a few defines as you can see.

    -Jorge

  • Jorge,

    I have that part figured out. I was just curious about what the significance of 1pu meant, if anything. It seems that 1.7pu = rated flux, so I wasn't sure if there was anything physical correlating rated flux to 1.7pu, or if it was a somewhat arbitrary scalar.

    Matt