• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 2298 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.

FOC PMSM with Hall feedback for position sensing

Richard Shank
Expert 2245 points

Hi,

I posted this topic before and thought I had an answer but as I study the eQEP module more, I now have more questions.  I'm not sure what I want to do is even possible but I'm leaning on the experts here to see if I can use the eQEP in a creative way.

I'm trying to use my Hall input as my period T and count system clocks between the period T as position.  It looks like the eQEP module wants to count QCLKs (which come from my Hall input) and use the system clock to determine the period T.  The nice thing about the eQEP module is it gives me speed and position that I need for FOC.  I'm of the understanding that I need 500+ counts (per electrical rotation) to get enough resolution to run the FOC.  The most I could ever hope for from 3 Halls is 6 edges and that's just not enough resolution for FOC (or am I wrong?).

My idea is to count the time between Hall A pulses and use that to determine speed and position.  How?

HallA to HallA = period T

Count system clock (deltaT) from HallA to HallA => n * deltaT = period T.  Period T needs to be stored in (QPOSCMP?) every time the counter gets reset by the next Hall A.

Speed is k1/T, where k1 is in units of RPM * t.   The shorter T, the higher the RPM.  A similar constant (k2) can be used to calculate angular velocity for the FOC.

Position (or theta in angular rotation) is 2pi*(n*deltaT)/(period T).  If there are 2000 clock counts between HallA ticks (QPOSCMP?) and there are 500 clocks in the register (QPOSCNT?), I'm at 90 degrees.

It appears the eQEP module has everything necessary to do the above but I just have to stand it on its head because it wants to count QCLKs instead of system clocks and it wants to use UTOUT (derived from SYSCLOCK) as the period T.

I may not be exactly correct yet in my math above but right now I'm going for concept.  I just tried to put enough math in to give the idea of what I'm trying to accomplish.

It looks like I need to use the eQEP Edge Capture function but again, I need to swap the use of my HallA and UTOUT. 

Thanks,

Rick

  • 0
    Prodigy 210 points

    hi,

    think about a luenberger observer, which gives you information about your system/machine, which is not measurable like the actual rotor position.

    you can fit your observer with the measured hall position and you get an angular rotor position, the actual speed and load torque with high resolution.

    martin

  • 0 in reply to martin izaak
    Expert 2245 points

    Hi Martin,

    I think that's exactly what I'm trying to do except simpler.  I'm assuming that I will have constant rotor speed over the period T where the period T is the time between each HallA pulse.  Also, I'm thinking that because my rotor speed is a constant the eQEP module will act as my observer and I have minimal coding to do.

    I'm looking at this some more and on page 26 of SPRUG05A it shows QCTMR ramps between UPEVNT.  UPEVNT is clocking twice per QEPA.  I think I can set that to once per QEPA (by setting QCLK to tick once per QEPA and then UPEVNT to tick once per QCLK) and then I have what I need from QCTMR.  QCTMR will give me deltaT (or t(k) in the diagram) and periodT (which is DT in the diagram).  Now, how do I get this info out on the fly?  It looks like the only thing available is the QCPRD.  I can't read QCTMR on the fly.

    Also, just for the record, I don't care about direction from the QEP (yet).  I'm only running in one direction.  My application is a vacuum generator.  I'm going to derive direction later to use as error checking.

  • 0 in reply to Richard Shank
    Prodigy 210 points

     

    ,hi rick

    i am sorry but i do not understand why you want to use the qep for this. if you use the qep (and it will work) your rotor angel between two sample times will increase smoothly, but how cares you can not react. you can also add the delta position according to your speed each sample time.

    in my opinion the hall sensors will do good work for a vacuum generator (usually high speed) and maybe you switch to brushless-dc.

  • 0 in reply to martin izaak
    Expert 2245 points

    Hi Martin,

    I'm sorry but I don't understand your point in either paragraph.  Please bear with me.  This is my first time with this.  I've never done an FOC before.

    The reason for using FOC was because we're running at high speed (40,000 RPM) and because the customer was worried about torque ripple, with trapezoidal drive (BLDC).  The reason I want to use a Hall rather than sensorless or a QEP encoder is because I read that sensorless tend to get lost with rapid load changes (which we may have in this application) and I can't find any decent information on QEP encoders or where to buy one (let alone for a 1.5" diameter motor.)

  • 0 in reply to Richard Shank
    Prodigy 210 points

    hi rick,

    sorry for confusing you. i do not know your knowledge about FOC or more details about your project. so it is very difficult for me to give you some useful hints.

    and by the way, sensorless works very fine at high speed, especially if you know your connected motor. it looks for me that you have one specific motor for one specific vac generator, so i would prefer a sensorless system. i had good experiences with sensorless systems, no problems with rapid load changes. our "customers" come to us and want a sensorless system because the hall or the encoders are often the cause for a break down.

    as i can see you have a maximum of 30 current control cycles per electrical rotation at rated speed (asuming one pair of poles). so you have to put a lot of care into this current controler to reduce torque ripple.

    i wish my post was not confusing you.

    nice weekend

    martin