• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 84 subscribers
  • Views 1396 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.

DRV8312 Kit PMSM Sensorless FOC Project Clarification request

Ariel Faynerman
Prodigy 200 points


Hi, I am working on a DRV8312-C2 Kit with the and wanted to clarify some of the documentation that came with the kit.

I am attempting to use the level 6 build level of this project to employ a SENSORED FOC control of our own PMSM motor(not the one that came with the kit). I will describe the encoder used below.

I adjusted motor parameters PM_Sensorless-Settings.H as follows:


// Define the PMSM motor parameters
//#define RS         0.79                       // Stator resistance (ohm)
#define RS         3.67                       // Stator resistance (ohm)
#define RR       0                       // Rotor resistance (ohm)
//#define LS       0.0012                     // Stator inductance (H)
#define LS       0.0019                     // Stator inductance (H)
#define LR       0                        // Rotor inductance (H)     
#define LM       0                        // Magnetizing inductance (H)
//#define POLES   8                        // Number of poles
#define POLES   4                        // Number of poles

// Define the base quantites
#define BASE_VOLTAGE    38.29            // Base peak phase voltage (volt), maximum measurable DC Bus(66.32V)/sqrt(3)
#define BASE_CURRENT    4.3                // Base peak phase current (amp) , maximum measurable peak current
//#define BASE_CURRENT    8.6
#define BASE_FREQ          100               // Base electrical frequency (Hz)  

Then I had no problems going through build levels 1 2 and 3. Graphs matched appropriately as shown in project documentation Sensorless FOC of PMSM.pdf.

Then at build level 4 I verified accurate enough tracking of id and iq signals using pid1_id.Fdb, pid1_iq.Fdb along with pid1_iq.Ref and pid1_id.Ref as part of the level 4A project documentation pdf.

Level 4B QEP/SPEED FR test is where i experienced some issues.

I initialized the QEP module as follows:

// Initialize QEP module
    //qep1.LineEncoder = 2048;
    qep1.LineEncoder = 8192;
    qep1.MechScaler = _IQ30(0.25/qep1.LineEncoder);
    qep1.PolePairs = POLES/2;
    qep1.CalibratedAngle = 0;
    QEP_INIT_MACRO(qep1)

Then i detect the calibration angle and call the QEP module.

// ------------------------------------------------------------------------------
//    Detect calibration angle and call the QEP module
// ------------------------------------------------------------------------------
    if (lsw==0) {EQep1Regs.QPOSCNT=0; EQep1Regs.QCLR.bit.IEL = 1;} // Reset position cnt.

    if ((EQep1Regs.QFLG.bit.IEL==1) && Init_IFlag==0)     // Check the index occurrence  
       {qep1.CalibratedAngle= EQep1Regs.QPOSILAT; Init_IFlag++;} // Keep the latched pos. at the first index

    if (lsw!=0) QEP_MACRO(qep1);

I have a quick question about what CalibratedAngle is supposed to mean. Below the f2803xqep.h file defines CalibratedAngle as the offset between the encoder index and phase a but from the code above it looks like it is just the counts(angle) from where the motor initially started and the index pulse. Am i correct in assuming QPOSILAT just sits at qep1.LineEncoder*4 after the Init_IFlag is incremented to 1.  Thus it would seem that it just figures out the angle between the initial rotor position and the index pulse. Could you please clarify.

 int32 CalibratedAngle; // Parameter: Raw angular offset between encoder index and phase a (Q0)

Aside from the above statement, the QEP module seems to work fine, i see a sawtooth shape for both rg1.Out and qep1.ElecTheta and their periods match. However, qep1.ElecTheta is slightly leading rg1.Out as shown below across two iterations.

Documentation states it should be slightly lagging. Can you explain why I would want it to be slightly lagging rather then identical to the rampgen module rg1.Out waveform?

Documentation dictates i adjust the calibration angle until it is slightly lagging. Thus judging from the above samples I found out it is offset by around 1/5th of the period so i added an offset value of (qep1.LineEncoder *quadX)*(1/5), with quadx = 4,  which didn't align it until i multiplied by a factor of two, which i assume is because of the ele cycles per mechanical cycles.Then i added a fudge factor offset to make it slightly lag.

After the calibration i skipped to build level 6 because of my encoder.I connected the software modules as shown in build level 6A block diagram however i commented out the volt macro, smo macro, and se macro as i am using an encoder to detect the rotor position(flux) angle. Thus if you opened up the HVPM_Sensored code from the high voltage kit it would look like the block diagram shown in Level 4B. Next I wanted to tune the speed1 PID controller.  However, I am getting very bad resolution at  speeds lower than 0.25*BaseRPM(with BaseRPM = 3000RPM). I seemed to get much better results before i closed the speed loop with only about +-0.8% error at 750RPM(.25pu). Could it be that i just need to tune the speed PID more. I feel there is a little more going on here then just that, the angle seems to be very important as it determines the commutation and is part of the speed feedback through the speed estimator. The resolution seemed terrible even though i have a very high encoder line count. The error was on the average of +-4.0% at 750 rpm or (.25pu) and got progressively worse the further down i went up to where it just stopped rotated clock wise then stopped and rotated counter clock wise at around 60 rpm (.02pu). Any feedback would be greatly appreciated, thanks again.

-Ari

  • 0
    Intellectual 970 points

    Hi Ariel:

    Base Current Value is determined by the hardware. If you look at the op-amp circuit that amplifies the shunt voltage, you'll find that the max. measurable swing in each direction is ~8.6A. So changing the value while using the provided hardware will cause unintended behaviour. 

    When you "enable" the program meaning lsw=0 state - the rotor is locked to Phase A. Here QPOSCNT remains 0 while the program is in lsw=0 state.  In your case, that would be two positions. As the rotor crosses the Index signal for the first time, the offset (read from QPOSLAT) is logged as calibration angle. The value in QPOSLAT, depending on the initialization, is updated on each index event with the value in the QPOSCNT register. 

    For low speeds, refer to http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/52724.aspx#186719 

    At low speed you will have to change the way you are calculating speed such that you measure the time taken to traverse a certain number of encoder counts.

    Hope this helps.

  • 0 in reply to newtothis
    Prodigy 200 points

    Thanks for clearing up my hesitations about the base current, i figured it had something to do with the kit board.

    However, I am still unsure about a few things regarding the calibration angle. As I understand this calibration angle is very important as the entire system requires the rotor position(flux) angle to be able to commutate optimally and correctly.

    Lets say i initialize the qep module as follows:

    // Initialize QEP module
        //qep1.LineEncoder = 2048;
        qep1.LineEncoder = 8192;
        qep1.MechScaler = _IQ30(0.25/qep1.LineEncoder);
        qep1.PolePairs = POLES/2;
        qep1.CalibratedAngle = 0;
        QEP_INIT_MACRO(qep1)

    Then at build level 4 for instance of the PMSM sensorless project I detect the calibration angle as follows:

    // ------------------------------------------------------------------------------
    //    Detect calibration angle and call the QEP module
    // ------------------------------------------------------------------------------
        if (lsw==0) {EQep1Regs.QPOSCNT=0; EQep1Regs.QCLR.bit.IEL = 1;} // Reset position cnt.

        if ((EQep1Regs.QFLG.bit.IEL==1) && Init_IFlag==0)     // Check the index occurrence  
           {qep1.CalibratedAngle= EQep1Regs.QPOSILAT; Init_IFlag++;} // Keep the latched pos. at the first index

        if (lsw!=0) QEP_MACRO(qep1);

    Am I correct in assuming I could have any number of calibration angles dependent on how i turn off the system. But if i turn off the system by setting lsw = 0 first and then DRV_RESET to 1 and power off, i can assure only two calibration angles depending on the direction of rotation? And in that case calibration angle would essentially be the distance between phase a and the index pulse?

    My final question which was puzzling me a little bit still was related the waveform i should see from my qep.ElecTheta angle. I understand it should be of sawtooth form and have the same period as rg1.out in for instance the level 4 build level of the PMSM Sensorless project. However, project documentation also states it should be slightly lagging the rg1.Out waveform. Can you explain why I would want it to be slightly lagging rather then identical to the rampgen module rg1.Out waveform? Also can i say 1/5th of a period would be a good representation of "slightly"? Any feedback on this question would be greatly appreciated, thank you.

  • 0 in reply to Ariel Faynerman
    Intellectual 970 points

    The Calibration Angle would only yield a proper rotor angle if it is w.r.t. Phase A. This is because of the way the QEP_MACRO has been written. In Build level 4, you will start with lsw = 0 which "locks" the rotor to phase A. In your motor's case that will be two orientations. Then depending on your direction of rotation, a calibration angle will be detected. So in your case you should have two calibration angles depending on which pole locked onto Phase A. Of course, you'll see that even if you start from the same orientation twice, the code detects calibration angles with a difference of a few encoder counts. Where you turn the system off doesn't matter, because on each start up the rotor is being locked to phase A. 

    I think the reason for the lag is that qep1.ElecTheta is based on the centre of a physical pole in the rotor while rg1.Out catches the leading edge of the pole. The lag, in my opinion then, is the electrical angle equivalent of the distance between the leading edge and the centre of the pole. 

    Perhaps some TI folks can confirm/correct the second issue.

  • 0 in reply to newtothis
    Prodigy 200 points

    Thanks that definitely helped clear up most of it. Yeah hopefully some TI people after this holiday break can clear the second issue up for me. thanks again

  • 0
    Intellectual 500 points
    Hey, I am trying to use this board for a regenerative braking project -energy harvesting for school.

    I saw that you successfully completed build level 2 (A n B i assumes). How did you separately test the phase voltage macro and clarke module? Did you comment out one..then the other? Please be specific..steps if possible would really help.

    I am really trying to understand. Thank you.
  • 0 in reply to Karlquisha Sargeant
    TI__Guru 60865 points
    Hi Karlquisha,

    The previous post is almost 4 years old. You will probably have better luck creating a new thread where you detail your question, and also provide a link to this thread and saying that your question is similar/related.