CCS/tm4c123gh6pm: Question about using GPtimer for counting hole-pulse with direction of the motor

On first read - I thought you meant, "Whole Pulse" signal - rather than "Hole Pulse." Yet - upon reflection - it may be that you are describing an optical encoder - which may indeed have "gaps" (which you note as holes) - and it is those pulses which you seek to, "Edge Count."

While an encoder is always helpful - certain more advanced motors (BLDC come to mind) may escape such requirement - as it is fairly easy to count the "commutation cycles" which relate directly to speed. (and also provide direction)

Your description of your motor - and the presence of an "encoder" (if any) will clarify - save "helper" guess-work - and yield a more "fact based" response...

Hello cb1_mobile,

Thank you for your reply.

We use the motor drive IC and FET to drive blushless motor,and using TM4C pwm module , the pwm signal output is connected to motor drive IC input pin.
the motor drive IC outputs the signal that is toggled when the electric phase of the blushless motor (U,V,W) has changed.
The motor doesn't have encoder , and we would like to know the position of the motor rotation by using two signals, one is the toggle signal (toggled when the electric phase of the blushless motor has changed) , and the other is motor direction signal that is driven by the motor drive IC. The motor drive IC determines the direction automatically.
And We would like to know the motor rotation by the two signals.

I tried to do that, and set the GPtimer as "Edge count"mode.
We could count well when driving the motor without changing the direction.
And tried to change the "count direcion of the GPtimer " when the direction signal changed, the count value doesn't match.
And we would like to know the attention point about it.

I would make efforts to describe more fact based .
Thank you for your advice.

Hiroyasu

Hiroyasu Matsubara said:

We use the motor drive IC and FET to drive brushless motor,and using TM4C pwm module , the pwm signal output is connected to motor drive IC input pin.

Thank you - thus there is No Encoder.      May we ask you to specify the maker & model number of the "motor drive IC?"     My suspicion is that what you (now) call "motor drive IC" - is more regularly noted as a "GATE-DRIVER!     Such gate-drivers are able to provide the (though brief) high-currents - required to fully/properly enhance (thus turn ON/OFF) the Power FETs.     Kindly confirm my understanding.

A classical means to determine, "Brushless Motor Speed" is to, "Count the number of Motor Commutations occurring w/in a measured time interval."      Such has long been "standard operating procedure" - and should prove "easy" for a Cortex M4.    (We - and others - have accomplished "just that" via lower cost, and simpler, Cortex M0 MCUs.)

It is likely that you "flip" your "Commutation Table" to achieve, "Direction Change."    You (surely) KNOW when that is done - thus "Motor Direction" should provide minimal (i.e. NO) challenge.    Most MCU designs provide an MCU input pin - which may be toggled (high or low) to "bring about" such "Direction Change."

There is (some) danger should you attempt to, "Change the BLDC Motor's Direction - when it is running at, "Beyond Low Speed!"    Our firm's software deals w/such issue by requiring that the BLDC Motor be "UNDER a specified speed - before we enable (any) "Change in Direction."     It is suspected that the issue you may be experiencing when "Detecting Motor Speed after "Direction Change" - results from your not maintaining a consistent measure of, "Number of Motor Commutations occurring w/in a measured time interval."    Such should be "unaffected" by the motor's direction.     Note that "certain" BLDC Motors are "biased" to run faster in one direction - if that is what you are noting - you should inquire of the motor manufacturer.    You should also confirm that your PWM Envelope Waveforms are consistent - independent of motor direction.   (of course w/motor adjusted to "the same speed" in each direction...

I believe this writing to reasonably answer your issues...

Hello,

Thank you for your reply.

The part number of MOSFET driver we use is , Allegro Microsystems A3930.

Hiroyasu

Hello,

I have a question about configuring GPTimer.
When we change the count direction (up/down) of the timer , for example , from down to up,
the timer restarts from value "0" .

For counting the pulse count of the motor continuously, I think two methods:
1. We set the timer register the value ( before changing the direction of the timer) when reconfiguring the GPtimer.
2. We save the value before changing the count direction of the timer , and ,
read the timer count ,and add the saved value to the timer count value.

Could you please tell us some advice about it ?

Hiroyasu

Thank you - our receipt acknowledged.

Your methods differ from our own! (ours being "reasonably" standard/conventional)
I've insufficient time to provide needed detail (now) - yet will be back after client visit - likely early afternoon today. (Chicago, US time)

My friend - your method is "different from the conventional" - my preference is to employ "KISS" (simple, direct, measurable) and stray from that (as/if required) only once, "All is working."    May we stick w/that approach?

Let's review some BLDC Motor basics - a "typical BLDC Motor" (if there is such a thing) is likely to have 4 poles - and employ 3 hall sensors - thus:

• a single motor revolution will yield (4*3=12) solid Hall impulses/revolution
• Motor Speed thus is a "frequency"

Now Calculation of "frequency" demands:

• counting of arriving signal(s)
• accurate measurement of (some) unit time

It is important that we "Enable such counting" - (only) during our chosen time interval.    Can we agree upon these statements - in support of this (basic) measurement method?

You speak to "Pulse Count of the motor continuously."    To my mind - most always - such proves "over-kill."    For example - if we, "Enable hall signal counting for 0.5 Second" - there is not great concern if we encounter, "one or even several" flawed calculations - during our "120 readings" - every minute!

The method you describe - which involves: "Reconfiguring the Timer, changing its count direction, and then "adding the saved value"" - to me - adds great complication - while (pardon) achieving little...

The arrival of hall impulses should be "direction independent."    As should be the, "Timed Period" in which those impulses are counted.    The greater the number of impulses captured - the faster the motor's speed.

Now you (must) have "some reason" for deeming this "direction change" critical.    Yet you've not shared that - and minus that input - I'm little motivated to provide more than that presented.

The method I've presented is NOT my invention - has been "long known" employed by many (firms both large & small) and has "so often" proved sufficient.   (surely, "Good for Gov't Work!" - one of my firm's (chartered & continuing) objectives...)

Hello,

Thank you for your reply.

We would like to use GPTimer for measuring the accurate position(total motor rotation number) of the motor,more than measuring speed.

I tried to change the direction of the GPtimer with the "Edge Count" mode.

I read the TM4C123GH6PM manual (SPMS376E GPTimer),and we could treat to save the timer count value, when changing from "down count

to up count". As mentioned on the manual, when changing the direction from down to up, the timer restarts to count up from value "0".

But,when trying to change the direction "from up to down",the saved timer count value is not accurate I think.

For example,before changing the direction, the count value is about 22000,but immediately after changed the direction,the timer count value is

10378,

I thought,

Changing the direction from down to up : restarts the count from "0"

from up to down : restarts from the previous timer count value

Is it correct ?

Hiroyasu

Hiroyasu Matsubara said:

use GPTimer for measuring the accurate position (total motor rotation number)

And your earlier post stated, "The motor doesn't have encoder , and we would like to know the position of the motor rotation by using two signals, one is the toggle signal (toggled when the electric phase of the brushless motor has changed) , and the other is motor direction signal that is driven by the motor drive IC."

Earlier I questioned your definition of "motor drive IC" - you noted the "A3930" which performs functional control (far) beyond a normal, "Gate Driver."    (gate driver required to adequately drive/enhance the Power FETs - which drive each of the BLDC Motor's 3 phases).     I've (now) made the time/effort to review A3930's data - I do not believe it provides the, "Accurate Positional Data" you seek.   Not close!    (nor do I know of "other" devices - with such capability - unless one employs (as I initially suggested) some form of "Motor Encoder!")

For clarity (& confirmation) - I present the key finding from my review of A3930 spec - which signals its "inability" to meet your "Accurate Position" detection:   (follows a true copy)

Do note that "Tacho" provides a, "Motor Speed" based signal - yet is FAR REMOVED from (any) "Accurate Position" detection/reporting!    This is so as the description (above) notes: "At each commutation point - the Tacho output changes!"    Those "commutation points" occur w/each/every Hall Signal change - and those Hall Signal changes are, "MANY motor rotational degrees apart!"   Thus - the "Tacho" signal from A3930 proves "far too coarse" to provide any "accurate" (your word/definition) positional information.     (and - even to "attempt to do so" - requires great software effort!)  

Thus - as I earlier noted - your "method of attack" is (pardon) flawed - has (little) chance for success.    (you may be able to "interpolate" between Hall impulses - yet that's (highly) non-standard - and outside the interest of (most all) here.)

As earlier suggested - motor encoders exist for "good reason" - your desire for, "Accurate Position" being "Number One" dictating Encoder's Use.   ("convention" - at times (most times?) indeed has its place!)

Your struggle w/Timer's change of direction seems - "no longer required" - in light of these findings...

Hello,

Thank you for your reply.

I understood what you mean and why using encoders is good for detecting accurate position.

Hiroyasu

You may note that "using an encoder" proves "beyond good" - likely "required" - should accurate positional information be sought...