• State Resolved
  • Locked Locked
  • Replies 34 replies
  • Subscribers 84 subscribers
  • Views 5126 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

align the eQEP angle with the rotor angle

sanet arezki
Intellectual 815 points
Other Parts Discussed in Thread: CONTROLSUITE, MOTORWARE

Hello,

In lab_13a project, I'd like to align the eQEP angle with the rotor angle without using the following code in proj_lab13a.c :


if((EST_getState(obj->estHandle) == EST_State_Rs) && (USER_MOTOR_TYPE == MOTOR_Type_Pm))
{
ENC_setZeroOffset(encHandle, (uint32_t)(HAL_getQepPosnMaximum(halHandle) - HAL_getQepPosnCounts(halHandle)));
}

any solutions?

best regards,

  • 0
    TI__Guru** 118800 points
    you can change the logic to instead provide an IdRef_A value at start-up, instead of using the RsRecal feature

    you need to do SOMETHING to try to force the rotor to align with the D axis so that you align mechanical and electrical angle.
  • 0 in reply to ChrisClearman
    Intellectual 815 points

    Hi Chris,

    I don't want to force the rotor at starting of the motor.

    Otherwise, Knowing inside my motor a hall effect sensor is implemented, I want to occur the zero offset of the encoder. currently 'enc_zero_offset' =0.

    But at starting we don't know this offest, that is why I'd like to integrate some code of hall sensors into instaspin motion, just for getting this offset and refresh the

      " temp += enc->enc_zero_offset " .

    thank you in advance for your collaboration.

    Best regards

  • 0 in reply to sanet arezki
    TI__Guru** 118800 points
    I suppose you could do this, but it really won't be that accurate. hall sensors will give you 15 degrees maximum.

    there are a few threads about adding hall sensor readings to MotorWare. Most have just used the examples in controlSUITE. It's not something we officially support, but it is on our to-do list to show hall start-up then transitioning to FAST.
  • 0 in reply to ChrisClearman
    Intellectual 815 points

    Hi chris,

    " but it really won't be that accurate "

    what's the best method for the alignment without forcing the rotor?

    "hall sensors will give you 15 degrees maximum"

    Why 15 degrees?

    "there are a few threads about adding hall sensor readings to MotorWare"

    I have some threads (code C to configure hall sensors), but I encountered difficulties to adapt it with project lab_13a, are you have some diagrams or steps to follow, for getting a best configurations ?

    think you in advance

    Regards, 

  • 0 in reply to sanet arezki
    TI__Guru** 118800 points
    "what's the best method for the alignment without forcing the rotor?"
    depends on your sensors. absolute encoders and resolvers do this automatically. incremental encoders need some sort of alignment to electrical for FOC and it is typically done with forcing the rotor to a magnetic position. sometimes they also just make sure that the encoders are attached/mounted very specifically so that the mechanical aligns to a known electrical.

    if you absolutely can't do any of these than your HALL alignment will have to do. It will likely be close, just be aware of the limitations.


    "Why 15 degrees?"
    this is based on having 6 states and 3 sensors. You can only say the rotor is in a sector, not at a specific location.
  • 0 in reply to ChrisClearman
    Intellectual 815 points

    " this is based on having 6 states and 3 sensors "

    I found a sector of 20 degrees, 360/6 = 60 degrees electrical angle, and 60/3 = 20 degrees (3 sensors). I am a taker if you exhibit the mode operating of the three hall sensors!

    " You can only say the rotor is in a sector, not at a specific location "

    Is that by using eCAP setup?

    In this case, how can I encode the digital states of the hall sensors ?

  • 0 in reply to sanet arezki
    TI__Guru** 118800 points
    there are some hall examples in controlsuite
    ex:
    C:\ti\controlSUITE\development_kits\DRV8312-C2-KIT_v128\BLDC_Sensored

    we actually just use GPIO, not eCAP.
  • 0 in reply to ChrisClearman
    Intellectual 815 points

    Hi Chris,

    Now I am with the configuration of the hall sensor.

    I have another question about the direction of the motor, knowing I ran labs 12 and 13 successfuly, my motor give sometimes a positive torque, and sometimes a negative torque!

    any suggestions?

    Regards, 

  • 0 in reply to sanet arezki
    Guru 12800 points
    You should be able to get both positive and negative torque from the motor, depending on the sign of the requested q-axis current.
  • 0 in reply to Adam D. Reynolds
    Intellectual 815 points
    Hi Adam,
    Yes that is sure, But my problem is when q-axis current is positive the motor produce a positive torque in one direction and sometimes for preserving this torque (on the shaft) I had change the sense of the q-axis current!
  • 0 in reply to sanet arezki
    Guru 12800 points
    I'm not following what the problem is. Sometimes in order to produce a positive torque you had to apply a negative q-axis current?
  • 0 in reply to Adam D. Reynolds
    Intellectual 815 points

    When these changes are happened, it's not good for my project.

    adam, usually each time the motor is runnig must produce the same torque for the same iq_reference.

    I miss something!

  • 0 in reply to sanet arezki
    Guru 12800 points
    I agree that the motor, when using a properly aligned sensor, should produce the same torque for the same Iq reference.

    I am failing to understand what problem you are seeing.
  • 0 in reply to sanet arezki
    TI__Guru** 118800 points
    I'm also not following the issue, sanet.

    "usually each time the motor is runnig must produce the same torque for the same iq_reference."

    Torque produced will depend on the load. Just because you command a specific amount of Iq_Ref_A for the stator does not mean that the motor will produce an equivalent torque. The motor will only pull UP to what you command but it's still minimizing current usage to meet the torque demands of the motor.

    You can see this for yourself. In proj_lab10a the Is/Iq/Id values are calculated. You can copy the updated
    void updateGlobalVariables_motor(CTRL_Handle handle)

    function from 10a to proj_lab05a Torque Control project.

    then you can run in torque mode and monitor the actual currents and torque as you command Iq_Ref_A and load/unload the machine.
  • 0 in reply to ChrisClearman
    Intellectual 815 points

    Hi Adam & Chris,

    I am sorry to bother you, perhaps I have a beug in my project.

    Can you take a look (torque control with an incremental encoder):

    sanet_project.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    /* --COPYRIGHT--,BSD
    * Copyright (c) 2012, LineStream Technologies Incorporated
    * Copyright (c) 2012, Texas Instruments Incorporated
    * All rights reserved.
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the distribution.
    *
    * * Neither the names of Texas Instruments Incorporated, LineStream
    * Technologies Incorporated, nor the names of its contributors may be
    * used to endorse or promote products derived from this software without
    * specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
    * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
    * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
    * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
    * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
    * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
    * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
    * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
    * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    * --/COPYRIGHT--*/
    //! \file solutions/instaspin_motion/src/proj_lab13a.c
    //! \brief Tuning the InstaSPIN-MOTION Position Controller
    //!
    //! (C) Copyright 2012, LineStream Technologies, Inc.
    //! (C) Copyright 2011, Texas Instruments, Inc.
    //! \defgroup PROJ_LAB13A PROJ_LAB13A
    //@{
    //! \defgroup PROJ_LAB13A_OVERVIEW Project Overview
    //!
    //! Tuning the InstaSPIN-MOTION Position Controller
    //!
    // **************************************************************************
    // the includes
    // system includes
    #include <math.h>
    #include "main_position.h"
    #ifdef FLASH
    #pragma CODE_SECTION(mainISR,"ramfuncs");
    #endif
    // Include header files used in the main function
    #include "sw/modules/ctrl/src/32b/ctrl.h"
    // drivers
    #include "sw/drivers/qep/src/32b/f28x/f2806x/qep.h"
    // etait juste "hal_obj.h"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      

    thank you in advance

  • 0 in reply to sanet arezki
    TI__Guru** 118800 points

    no, we will not review your code line by line looking for "bugs"

    you haven't even described the problem fully

  • 0 in reply to ChrisClearman
    Intellectual 815 points

    Hi Chris,

    As I told you on the previous posts :

    I am contolling the motor on the torque by inspiring from lab5a and 13a. I run my project successfully, I gave a positive Iq_ref as

    current reference , then my motor ( has a load on the shaft ) spins in one direction, but after several tests,  the direction changes the

    sense and of the same reference of Iq_ref ,in this case, for preserving the first direction I was obliged to change the sense of current

    reference (then negative one). 'I checked all parameters : IQ math format, frequencies, ...'

    I hope it's clear clearman  ^-^ 

    Best regards,  

  • 0 in reply to sanet arezki
    TI__Guru** 118800 points
    what you describe can't happen in proj_lab05a with sensorless operation

    so you are using an encoder, but removing the position and velocity outputs from proj_lab13 to treat it as a torque control only?

    My first thought is there is an issue with the encoder alignment or how you are handling the roll over of the encoder counts.

    when you run in torque mode are you still setting a speed reference with the same sign as the torque Iq_Ref_A? This is critical to insure a matching direction. Note how we do this in proj_lab05a. When we set the IqRef we set a speed reference with the same sign.
  • 0 in reply to ChrisClearman
    Intellectual 815 points

    Hi Chris,

    " so you are using an encoder, but removing the position and velocity outputs from proj_lab13 to treat it as a torque control only?  "

    that is correct 

    " encoder alignment  "

    I run lab 12 and 13 successfully 

    " when you run in torque mode are you still setting a speed reference with the same sign as the torque Iq_Ref_A? " 

    as you can see it in my project, I set "  updateIqRef (ctrlHandle); "  before  " updateKpKiGains(ctrlHandle); " , and  updateIqRef

    (ctrlHandle)  insure a matching direction as :

    void updateIqRef(CTRL_Handle handle)
{
  _iq iq_ref = _IQmpy(gMotorVars.IqRef_A,_IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A));

  // 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 < _IQ(0.0))
        {
          CTRL_setSpd_ref_krpm(handle,_IQ(-0.01));
        }
      else if(iq_ref > _IQ(0.0))
        {
          CTRL_setSpd_ref_krpm(handle,_IQ(0.01));
        }
    }

  // Set the Iq reference that use to come out of the PI speed control
  CTRL_setIq_ref_pu(handle, iq_ref);

  return;
} // end of updateIqRef() function

    note that I disabled the 'forced angle', I still setup my effect hall sensor to define my enc.offset.

    Best regards,

  • 0 in reply to sanet arezki
    Intellectual 815 points

    So chris !, I just follow the example in lab5a

  • 0 in reply to sanet arezki
    TI__Guru** 118800 points
    I don't have any other ideas. We have never seen this happen. It must be a SW issue you introduced when modifying lab 12 or 13.
    you are still doing an encoder calibration by using RsRecal to alight the encoder to the electrical angle?
  • 0 in reply to ChrisClearman
    Intellectual 815 points
    No, I disabled RsRecal, and I setup the hall effect sensors, now I am in the final touches to adapt this hall offset to the encoder one.
  • 0 in reply to sanet arezki
    TI__Guru** 118800 points

    if you have disabled RsRecal and aren't taking care of it in some other way, you aren't performing the zero'ing offset between the mechanical encoder and the electrical angle.

  • 0 in reply to ChrisClearman
    Intellectual 815 points

    I know that altering my control strategy, but not the direction as I know, isn't it ?

    So, that is my problem now .!  

    I am configuring the hall sensor as the example defined in this Rich's answer :

    "

    https://e2e.ti.com/support/microcontrollers/c2000/f/902/p/411516/1563017#pi316717=4

    "

    after computing the Hall offset, can I put it directely into 'enc.enc_zero_offset'?

  • 0 in reply to sanet arezki
    Intellectual 815 points

    Hi Chris,

    After computing electrical angle by hall sensors, I took care of the mechanical and electrical angle.  

    knowing " ElecAngle =  hallBits * SEGMENT_SIZE + MID_EDGE ", I found that varying "MID_EDGE" value  is altering the sense of

    rotation.

    I don't find how to fix "MID_EDGE" value in my datasheets , do you have any suggestions?

    Best regards,

  • 0 in reply to sanet arezki
    Prodigy 240 points
    Hi sanet,

    I saw your post and I am wondering which sample project are you using? Is it one of the sample projects in ControlSuite?
    Also I was wondering how you set the angle ZERO? Do you put some current on the d axis and when it settle down you read the Hall sensors bits and decide what the offset need to be?

    Thanks.
  • 0 in reply to Wil
    Intellectual 815 points

    Hi Wil,

    - I am using projects in motor ware wich are based on the InstaSpin FOC & Motion.

    - By default, in Labs12 & 13 with encoder (sensored projects), the angle zero is set it by the  FAST observer (no code because it is defined in the library 'ROM'), this alignment is done by moving the rotor on open loop, when it settle down the FAST read this angle (enc.offset), which is integrated with electrical angle as : <electricalAngle = p * mechanicalAngle + offset >, where p=pole pair, offset is this angle which you called angle zero.

    - Now, especially to my project, I read directely the hall sensors once, without FAST, so I replaced :

    if((EST_getState(obj->estHandle) == EST_State_Rs) && (USER_MOTOR_TYPE == MOTOR_Type_Pm))
{
ENC_setZeroOffset(encHandle, (uint32_t)(HAL_getQepPosnMaximum(halHandle) - HAL_getQepPosnCounts(halHandle)));
}

    by my code.

    Best regards,

     

    if((EST_getState(obj->estHandle) == EST_State_Rs) && (USER_MOTOR_TYPE == MOTOR_Type_Pm))
    {
    ENC_setZeroOffset(encHandle, (uint32_t)(HAL_getQepPosnMaximum(halHandle) - HAL_getQepPosnCounts(halHandle)));
    }

  • 0 in reply to sanet arezki
    Prodigy 240 points
    Hi Sanet,

    Thanks for the explanation!


    Best regards,
  • 0 in reply to sanet arezki
    Prodigy 240 points
    Hi Sanet,

    Sorry to bother you again, so when you read the hall sensors how do you determine how much offset angle it needs. I saw your other post, and you codes look like this in the following

    if (HallAngles[*hallBits] == 65535)
    {
    // do not update motorElecAngle
    *mapErrors += 1;
    }
    else
    {
    *inDegrees = (HallAngles[*hallBits] * SEGMENT_SIZE) + MID_POINT_FROM_EDGE_OFFSET;
    }

    I was wondering if the SEGMENT_SIZE means the (QEP total counts)/( total poles pairs)/6 , and how do you determine the MID_POINT_FROM_EDGE_OFFSET?

    And when you mentioned last time to use open loop to find the HALL sensors reading, do you mean by just move the motor to any position and then read the hall sensors so that you can see how much offset you are from the angle zero?

    I would really appreciate if you can help me to clarify above questions. Thanks!
  • 0 in reply to Wil
    Intellectual 815 points

    Hi Wil,

    ok. I try to help you.

    " HALL sensors reading " --> these sensors measure the presence of a magnetic field, then just at start-up I read the position by coding the hallBits without moving the motor (from GPIOs as shown in last post where I posted my diagram), after some transformation (IQ24, pu, ..) I put gMotorElecAngle_pu  as my enc.offset.

    concerning the segment_size and mid egde I reffered to Rich's answers as :

    refering to my maps, I have six discrete angles that I can observe with three bits (2 ^ 3 - 2). That's 180 / 6 which is 30 degrees. The midpoint from edge offset then needs to be half of that so that my reported angle is in the middle of the angle segment. So in this case is 15 . And the segment size is 30."

    In your case Wil I don't know what you have as mapping halls!. you can follow my discussion with Rich and deduct your own mapping.

    Best regards,

  • 0 in reply to sanet arezki
    Prodigy 240 points
    Hi Sanet,

    Thanks for getting back to me.

    I've already mapped the hall but I don't know how it really map to the FOC commutation sectors, I know you are using the InstaSpin but I might not have what you already have. Anyhow, I will try to seek more information from my side...

    How's your results go? Does it run smoothly in low speed? And I was wondering if you are still doing FOC or Trapezoidal?
  • 0 in reply to Wil
    Intellectual 815 points

    Hi Wil,

    Yes, I am still doing FOC, I can read my offset correctely but the program is not stable, so I have the problem of change direction of the motor!

    If you want post me your hall sensors datasheet for getting more information.

    Best regards,

  • 0 in reply to ChrisClearman
    Intellectual 815 points
    Hi Chris,
    how can I verify that my zero hall offset is the best one for what Instaspin needs at startup?
    best regards,
  • 0 in reply to sanet arezki
    TI__Guru** 118800 points
    I'm not sure there is a way to verify. if the angle is off too much you will lose torque generation, and eventually synchronization.