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.

TMS320F28379D: tmdxiddk379d : encoder angle issues

Part Number: TMS320F28379D
Other Parts Discussed in Thread: TMDXIDDK379D

Hello,

I am modifying tmdxiddk379d example code for my own fast current loop sensored FOC application. I was initially using a 2048 PPR encoder for my application, and everything was working as expected. I've now switched over to a 32,768 PPR encoder, and am having some issues.

It seems that there is a jump in the angle during operation. With each rotation I can hear a mechanical "pop", which I am guessing is a result from the field making a jump with the angle. You can see the jump in angle below.

If I go any faster than ~150 RPM, the motor losses synchronization and the control becomes unstable. However, when I deenergize and spin the rotor by hand, the angle is correctly reported in the waveform plotter, a smooth ramp up to 1.0 p.u., and then back down to 0.

Any insight into why this might be occurring with the new encoder would be helpful. I'm thinking it may have to do with the count value at the index being loaded into the counter at each rising edge of the index pulse, because the jump seems to happen once per revolution. However, I don't understand why the value would be incorrect. The initialization routine should take care of that.

Here are some of my QEP initialization parameters:

 

 // Init QEP parameters
    qep1.LineEncoder = ENC_SLOTS;    // set the number of slots in the encoder
    qep1.MechScaler  = 0.25 / qep1.LineEncoder;
    qep1.PolePairs   = POLES / 2;
    qep1.CalibratedAngle = 0;    // Parameter: Raw angular offset
                                 //            between encoder index and phase A

    // Configure the decoder for quadrature count mode, counting both
    // rising and falling edges (that is, 2x resolution)
    // For US Digital HB6M Encoder, A leads B for positive speed
    EQEP_setDecoderConfig(EQEP1_BASE, (EQEP_CONFIG_2X_RESOLUTION |
                                       EQEP_CONFIG_QUADRATURE |
                                       EQEP_CONFIG_NO_SWAP));

    EQEP_setEmulationMode(EQEP1_BASE, EQEP_EMULATIONMODE_RUNFREE);

    // Configure the position counter to be latched on a unit time out
    // and latch on rising edge of index pulse
    EQEP_setLatchMode(EQEP1_BASE, (EQEP_LATCH_RISING_INDEX |
                                   EQEP_LATCH_UNIT_TIME_OUT));

    // Configure the position counter to reset on a maximum position
    EQEP_setPositionCounterConfig(EQEP1_BASE, EQEP_POSITION_RESET_MAX_POS,
                                              (4 * qep1.LineEncoder) - 1);

    // Disables the eQEP module position-compare unit
    EQEP_disableCompare(EQEP1_BASE);

    // Enable the unit timer, setting the frequency to PWM Frequency
    EQEP_enableUnitTimer(EQEP1_BASE, QEP_UNIT_TIMER_TICKS);

    // Configure and enable the edge-capture unit. The capture clock divider is
    // SYSCLKOUT/128. The unit-position event divider is QCLK/32.
    EQEP_setCaptureConfig(EQEP1_BASE, EQEP_CAPTURE_CLK_DIV_2,
                                      EQEP_UNIT_POS_EVNT_DIV_256);

    // Enable QEP edge-capture unit
    EQEP_enableCapture(EQEP1_BASE);

Any ideas on how to resolve this issue would be much appreciated. The encoder code in the CLA is unmodified from the example. Thanks!

  • The ENC_SLOTS value is 32,768.

  • Hi Ryan,

    You can try running the motor in open-loop and see if the position is reported correctly. See section 7.5.2 'Verification of Position Encoder Orientation' of https://www.ti.com/lit/spracl1 for more details as well.

    It seems that there is a jump in the angle during operation. With each rotation I can hear a mechanical "pop", which I am guessing is a result from the field making a jump with the angle. You can see the jump in angle below.

    If this issue is happening every rotation shouldn't we see the "jump" in angle every cycle (0-1.0 pu) in the graph?

    Any insight into why this might be occurring with the new encoder would be helpful. I'm thinking it may have to do with the count value at the index being loaded into the counter at each rising edge of the index pulse, because the jump seems to happen once per revolution. However, I don't understand why the value would be incorrect. The initialization routine should take care of that.

    What count value should be loaded at index pulse? Does it match the value jumped to when the issue occurs? This may be a way to confirm this thought.

    Best,

    Kevin

  • Thanks for the comments Kevin. To clarify, the angle shown in the plot is the electrical angle, not the mechanical angle, thus no jump in each cycle. I was able to resolve the jump in angle. It turns out that encoder being used wasn't able to support the speeds I was attempting to command from the system. I'm back to using my encoder with 2048 ppr.

    However, I have another question related to this topic. This paragraph is from the document "Quick Response Control of PMSM Using Fast Current Loop" under Build Level 4, pg. 27:

    "If the motor rotation direction is reversed occasionally due to any malfunction, try restarting it by setting runMotor to MOTOR_STOP and then MOTOR_RUN again. With a QEP, it may need some fine tuning in transitioning from lsw = ENC_WAIT_FOR_INDEX to lsw = ENC_GOT_INDEX. This can be used as an exercise to fix it."

    Does TI know the cause of this issue? It occurs every time I run my motor. Initially I start by aligning the rotor angle to the alpha axis, and I zero the angle count (ENC_ALIGNMENT). Then, I force an angle and inject some q axis current until I hit the index pulse (ENC_WAIT_FOR_INDEX). This offset value is saved and reloaded into the counter every time the index pulse fires. At this point the motor is ready to run (ENC_CALIBRATION_DONE). I initially have a speed command of 100 RPM (7500 RPM base speed). The speed and current regulators perform properly and get the motor up to speed. Then, after about 1 or 2 seconds, the speed feedback drops off and the motor will begin to spin backwards, the current command then increases because of the error and the control ends up tripping from an overcurrent event. Here is a plot of the speed response during this event:

    Red is the speed command, green is the speed reference with acceleration limits, white is the speed response from the encoder. Any idea why the sudden drop off occurs and the speed goes negative?

    Thanks.

  • Hi Ryan,

    Sorry for the delayed response. Are you receiving any other reported faults when this trip issue occurs? You mention over-current, but any others possibly before that?

    Does TI know the cause of this issue? It occurs every time I run my motor.

    Let me as a colleague if he's familiar with this behavior.

    Best,

    Kevin

  • Hi Kevin, this issue has been resolved. The encoder set screw was not tight enough on the shaft of the machine, so as the speed increased there would be a slight amount of slip until the angle was such that torque was being generated in the opposite direction - which explains the sudden deceleration and instability. Everything is working as expected now.