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.

TMS320F28069: DRV8301-HC-Kit - problem with encoder in lab 12

Part Number: TMS320F28069
Other Parts Discussed in Thread: DRV8301-69M-KIT

Hello,

We are facing some issues with lab 12 ( encoder).

1- At start up, the motor starts some back and forth movements for few seconds and then starts moving normally. How can we fix this issue? RS calib and force_angle are both enabled.

2- Sometimes when we start spinning using CCS, motor spins in the reverse direction. why is that happening?

3- Also we have noticed that sometimes the motor does not respond to the speed commands or it takes a long time to change the speed after setting commands.

4- there is a huge overshoot when we change the speed. Does this have to do with PID coefficient? We have already tuned the bandwidth.

We have used the appropriate labs to detect motor parameters and configure the encoder. Any suggestions/comments on these issues will be highly appreciated.

  • The noise on encoder feedback can make this kind of issue if the bandwidth has turned well with a proper system inertia and friction.
    The input qualification feature is already enabled for the encoder GPIOs. But some user cases, It might not be enough for noise filtering without additional signal filtering like RC passive filter and ferrite core on encoder cable.

    So you need to check encoder feedback signal first by oscilloscope while motor is running.
    You can also adjust sampling window by using GPIO_setQualificationPeriod() function in hal.c

    This issue is not resolved with my comment, please attach the oscilloscope waveform of encoder feedback.
  • The one more thing you need to check is an align current. In this lab, rotor is aligned to zero angle position before start up by using Rs recalculation function. But if rotor does not move to zero position due to the high load torque, PMSM motors do not work properly.
    Please check if the Rs recalculation current(USER_MOTOR_RES_EST_CURRENT) is enough for moving rotor to electrically zero angle position.

  • Hi Steve,

    Thank you for your input. Please see the waveforms for the encoder which seems to be clean and also the phase current at max speed. also increasing USER_MOTOR_RES_EST_CURRENT didn't help. 

    Let me just add that we have one more issue which is the maximum speed which is limited to about 400 rpm where and does not go beyond that number. Actually we have tested this motor before with sensorless and we were able to go to 700 rpm. ( the rated speed of our motor is 800 rpm, voltage: 48VDC, bldc  motor, 8 pair poles). What's happening at high speed is that the motor phase current goes to high (40 arms)and motor gets  too hot  and stops working. The input current from power supply at max speed is about 12A at 48 VDC which is really high for the little  load that we have which makes think that we are injecting some unnecessary id  due to wrong offset of encoders maybe? note that enable force angle and enableoffsetcalc were both enabled in our testing.  Also we tried to increase the input DC voltage to see if it makes change but it didn't help. Any idea why our motor speeds is limited? we are trying to find out why the motor is drawing too much power! We areally appreciate your URGENT help on this.

  • I think the encoder setting "USER_MOTOR_ENCODER_LINES" in user.h has some issue. You need to carefully check the encoder resolution spec. For example, the resolution in the encoder below is the value of post-quadrature. It means that the resolution(counts/rev) should be divide by 4 for USER_MOTOR_ENCODER_LINES because this lab use eQEP feature with quadrature enabled.

    Could you share your encoder specification?

    What the value of USER_MOTOR_ENCODER_LINES ?

  • Hi Steve, Thanks again for your support and helping us on this issue which is highly appreciated. We agree that there might be an issue with the encoder settings but not with the USER_MOTOR_ENCODER_LINES. The motor encoder CPR is 2500. So are you saying that we should try 2500/4 =625  ? 

    What about encoder offset? How do we make sure the encoder offset is correct?

    And what does this number stand for ? #define ENC_ZERO_OFFSET 3813071.0     

    Thanks

  • if there is no any comment like "post-quad" on encoder , USER_MOTOR_ENCODER_LINES is 2500.
    The define "ENC_ZERO_OFFSET" is not used as a constant in code. Instead, the enc zero offset is calculated by forcing align to electrical zero posing through Rs recalculation function such as the code in mainISR() below.

    // if we are forcing alignment, using the Rs Recalculation, align the eQEP angle with the rotor angle
    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)));
    gEnc_offset = HAL_getQepPosnCounts(halHandle);
    }

    I’m still doubt if encoder feedback does not have noise.
    Could you check an encoder feedback again by running open-loop angle generation? You can add some data logging module, and can check encode count value or electrical angle while running motor with constant frequency and constant current with open-loop angle generation.

    Did you check the encoder count direction by any chance?

  • 1- which lab should we use for open loop generation?

    2- can you elaborate on how to check encoder counts?

    3- How do we ensure that the offset is correct for the encoder?

    Thanks again for your urgent support.

  • Also does lab12b uses the index signal of the encoder?
  • A1 A2) . the attached file is for open loop test, and has data logging module for graph. please find the following test procedure.

     step1. replace the origital proj_lab12b.c file with the attached file (proj_lab_12b_1.c).

     step2. add "sw\modules\angle_gen\src\32\bangle_gen.c" file into the project 

     step3. compile & downloading & run

     step4. gMotorVars.Flag_enableSys = 1 

     step5. gMotorVars.Flag_Run_Identify = 1

     step6. Set target speed (gMotorVars.SpeedRef_krpm)

    if gMotorVars.EstState becomes EST_State_Online, set the target speed with "gMotorVars.SpeedRef_krpm". 10~30% of rated speed is enough for this encoder test. You can increase Id current with gMotorVars.IdRef_A if you need more current for more high speed. The default value of Id reference current is same with Rs estimation current.

     step6. Data logging enable (Graph_Flag_Enable_update = 1) once rotor reach to the target speed.

     step7. Check encoder data by using CCS graph tool. Graph setting is as following.

    The sample of test result should be like this. Electrical angle from encoder have to be positive direction and same frequency with phase current. 

    A3) Because an incremental encoder is just used in this lab, the offset is automatically calculated through forced align to zero angle. Generally, if encoder angle is not aligned with rotor angle, more current will need for torque output. 

     A4) Index signal is not used in this lab.

     

    proj_lab12b_1.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_lab12b.c
    //! \brief SpinTAC Velocity Controller using a quadrature encoder for feedback
    //!
    //! (C) Copyright 2012, LineStream Technologies, Inc.
    //! (C) Copyright 2011, Texas Instruments, Inc.
    //! \defgroup PROJ_LAB12b PROJ_LAB12b
    //@{
    //! \defgroup PROJ_LAB12b_OVERVIEW Project Overview
    //!
    //! SpinTAC Velocity Controller using a quadrature encoder for feedback
    //!
    // **************************************************************************
    // the includes
    // system includes
    #include <math.h>
    #include "main.h"
    #ifdef FLASH
    #pragma CODE_SECTION(mainISR,"ramfuncs");
    #endif
    // Include header files used in the main function
    // **************************************************************************
    // the defines
    #define LED_BLINK_FREQ_Hz 5
    #define _GRAPH_
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi Steve,

    The code is not working. The motor does not start spinning with this code. Also, Graph_Flag_Enable_update cannot be get updated using CCS and stays zero all the time. Any idea? Can we just add the data logging code to the encoder code and run this test instead of trying to run it in open loop using your code?
  • Also can you advise how to reverse the direction of the motor in lab12b ? We tried negative speed commands but after a couple of times, it killed the driver . (Not sure that was the reason for damaging driver tho)
  • I'm wondering why the open-loop test code is not working. If you are using DRV8301-69M-KIT without any modification, this code should work. Did you check the motor A-phase current with oscilloscope? If you’ve done setup properly your motor parameters in user.h, you can see an align current at start-up and rotating current while motor running.

     

    The reason I provided the test code is that I wanted to confirm two things: the encoder signal integrity, the direction of encoder angle. The encoder angle have to be same direction with rotating flux. For example, if rotor is running with positive torque, the direction of encoder angle have to be up-count like the waveform I attached on above answer.

     

    Can you attach your user.h file for checking your motor parameters and board settings?

  • I'm sorry to hear that your kit was damaged. I hope you have extra new one.

    I think your motor phase and encoder pulse direction are not matched. If so, you can resolve the issue by simply exchanging the encoder A/B connection each other or exchanging only the motor two phases connection(U<->V or U<->W or V<->W).

  • 4278.user.h

    User.h attached. Thanks for your help!

  • phase current waveform.docxI have also attached the Phase current waveform at max speed when it starts oscillating

  • Steve,

    I have also attached the motor datasheet for your reference. The maximum speed is 800rpm. As mentioned, we cannot go above almost 500 rpm. we don't have the motor characteristics to see what we should expect from the motor at high speed. Is this normal that for a rated 800 rpm motor, you can't get a higher rpm than 500 ?

  • The waveforms you requested (phase current and elec angle) are also attached

    encoder.docx

    FL80SV80-48V-800 (Rev. A), 10.9.2018.pdf

  • The encoder angle with phase current waveform looks good.
    There is something suspicious about motor parameters in user.h you shared.
    If the rated input voltage(40V) and max speed(800rpm) are correct, some motor parameters like inductance and flux should be more high. For example, BEMF voltage at max speed is about 2V.
    BEMF_V = RPM/60*PP*FLUX = 800/60*8*0.02 = 2.13V
    The max output voltage at 40V input is about 21V (=40V/sqrt(3)). Compare to 21V, the BEMF 2V at max speed is too small even if ignoring resistance and inductance voltage drop.

    Also the inductance is too small for low speed motor. Generally, low speed motors have relatively high value of inductance and flux than high speed motors.
    I think you need to check your motor parameters again with lab2c.

    I found out your motor datasheet show the motor parameters. When you run lab2c, the parameter results should be reasonably similar with the following values. If the motor identification lab does not work well, You can manually calculate them by using the values in motor datasheet. Please use the following motor parameters for testing.

    #define USER_MOTOR_Rs (0.35) //0.7 ohm line-line
    #define USER_MOTOR_Ls_d (0.00075) //1.5mH line-line
    #define USER_MOTOR_Ls_q (0.00075) //1.5mH line-line

    #define USER_MOTOR_RATED_FLUX (0.22654) //37Vrms/krpm (=37*1.414/sqrt(3)/(1000/60*8)). 37Vrms will be line-line voltage, not phase voltage for 40V rated input.
    #define USER_MOTOR_RES_EST_CURRENT (2.0) // About 20% of rated current is enough for general applications
    #define USER_MOTOR_MAX_CURRENT (10.0) //Rated Torque: 4N.m

    The rated toque of your motor is 4N.m. It mean that the Iq current will be about 10A for the rated torque if encoder interface does not have issue for a rotor angle calculation.
    Iq_A = RATED_TORQUE/(1.5*PP*FLUX(Wb)) = 4/(1.5*8*0.22654/(2*pi)) = 9.25A

    I hope my answer does help to resolve your issue.

    Thank,
    Steve
  • Hi Steve,

    We had tried the values that you suggested. In fact, we started with those values and the maximum rpm we get using those values is 360 rpm. increasing  #define USER_MOTOR_MAX_CURRENT from 10 to 20 helped to get up to 500 rpm. After that, increasing max current didn't help. Increasing input voltage didn't help either. Do you think we are hitting the maximum power this motor can handle? also do you think field weakening or over modulation might help?

  • Hi Eduardo,

    If the max speed was not changed when you increased input voltage, field weakening does not help for getting up max speed.
    The no load current in your motor should be very small (< 0.5A) according to the motor datasheet. I think rotor angle calculation with encoder feedback still does not work properly.
    I think It would be better to contact TI local FAE in your site if the issue was not resolved yet.