• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 83 subscribers
  • Views 727 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Motor Control SDK EQEP questions

Chaitanya Sindagi
Intellectual 300 points

Part Number: TMS320F28379D

I'm using a QEP encoder with the motor control SDK for an EV application and am trying to understand the behavior of the vehicle on startup before the controller has detected the index pulse from the encoder. There is a variable in the source code shown below - 

float32_t lsw1Speed = 0.02;         // initial force rotation speed in search
                                    // of QEP index pulse

When this "force rotation" period is going on, is there any way that the motor moves backward before finding the index and then moves forward? I want to ensure this does not happen. 

Also, in the motor parameter definition section in the header file, how are "slots" of the encoder defined? I have an encoder that outputs 2048 "cycles" of the encoder which is effectively 8192 rising/flling edges per rotation. Is my slot number equal to 2048 or 8192? Below is a screenshot from the datasheet of the encoder I'm using(RM44), my "counts per rev" is 8192.

Thanks in Advance

Chai

  • 0
    Intellectual 300 points

    The image didn't get inserted above, trying again

  • 0 in reply to Chaitanya Sindagi
    TI__Mastermind 24095 points

    Hi,

    From your description, it seems like the number you should use is 8192 which is 4 times the slot number equal to 2048.
    I'm not sure about the definition of "Slot" as it could encoder specific terminology.
    What you would need is the total number of edges of A and B inputs between 2 index pulses - that is one rotation.

  • 0
    Intellectual 300 points

    My question about the possibility of the motor operating in reverse still stands. I've dug into the code further and arrived at this - 

    In buildLevel3, the "lsw = ENC_ALIGNMENT" state forces the id ref value is set to some constant. The PI controller attempts to achieve this and after 20000 times that the motor exceeds id=id_ref, it is determined that it has "settled". During this period the comments use the term "lock the rotor" which makes sense since pi_iq.ref is set to 0 during this period so it cannot move once it has aligned the electrical axis. While the rotor is locked, POSCNT and pAngle are set to 0 defining this as 0 motor angle. Is this correct? 

    Next "lsw = ENC_WAIT_FOR_INDEX" where iq is now IqRef and id=0, which will cause the motor to rotate in the forward direction since we aligned the motor to the encoder in the previous step. In terms of torque and speed control, this step is unnecessary, only useful for position control and to prevent any missed A/B pulses from allowing the motor to drift over time. If this step wasn't performed and index pulse never triggered the reset of POSCNT the motor would operate normally as long as there were no missed encoder pulses and POSMAX was set correctly. Is this correct too? Its mostly a hypothetical question but I'm simply trying to understand the functioning of the provided library.

    On to my primary issue now. I am developing this motor controller for use on an electric vehicle where each wheel is driven by an independent motor. In this case, the motor cannot freely rotate during the alignment phase. Moreover, it cannot involuntarily move in a reverse direction. I currently am thinking of a solution that works like this - 

    During initial assembly, the offset between electrical and mechanical angle is noted using the free-moving method discussed above. This POSINIT value is stored and loaded on every subsequent boot. During subsequent operation, since the POSINIT value has already been measured, the motor is forced to move at a low speed till the index pulse is detected and after that, FOC control can be used to control the motor. Is this feasible to implement by using the ramp control module like in buildLevel1 to generate a low-frequency sine wave output? 

    Thanks in Advance

    Chai

  • 0 in reply to Chaitanya Sindagi
    TI__Mastermind 27240 points

    Check if the sense of rotation of the encoder angle and the electrical angle are same. 

  • 0 in reply to Ramesh Ramamoorthy
    Intellectual 300 points

     I don't quite understand what you mean. Could you elaborate?

  • 0 in reply to Chaitanya Sindagi
    TI__Mastermind 27240 points

    Well, there seem to be multiple questions. If the encoder has a opposite orientation to that of the motor sequence, then the rotor will attempt to rotate in reverse direction. Probably, this is not your issue right now.

    Chaitanya Sindagi said:

    While the rotor is locked, POSCNT and pAngle are set to 0 defining this as 0 motor angle. Is this correct? 

    Yes

    Chaitanya Sindagi said:

    Next "lsw = ENC_WAIT_FOR_INDEX" where iq is now IqRef and id=0, which will cause the motor to rotate in the forward direction since we aligned the motor to the encoder in the previous step. In terms of torque and speed control, this step is unnecessary, only useful for position control and to prevent any missed A/B pulses from allowing the motor to drift over time. If this step wasn't performed and index pulse never triggered the reset of POSCNT the motor would operate normally as long as there were no missed encoder pulses and POSMAX was set correctly. Is this correct too? Its mostly a hypothetical question but I'm simply trying to understand the functioning of the provided library.

    No, FOC demands the angle anyways to do park transform

    Chaitanya Sindagi said:

    During initial assembly, the offset between electrical and mechanical angle is noted using the free-moving method discussed above. This POSINIT value is stored and loaded on every subsequent boot. During subsequent operation, since the POSINIT value has already been measured, the motor is forced to move at a low speed till the index pulse is detected and after that, FOC control can be used to control the motor. Is this feasible to implement by using the ramp control module like in buildLevel1 to generate a low-frequency sine wave output? 

    If you already calibrate each motor and know the offset already, then you can preprogram it.