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.

Noticeable difference between using PWM block and timer block for PWM signals?

Other Parts Discussed in Thread: TM4C1294NCPDT

Hi all,

I thought I would just pop this question in here as I'm doing some tests myself. Has anybody noticed any difference when using the timer block to generate a PWM signal or when using the PWM block to generate a PWM signal on the TM4C1294NCPDT? I'm talking about mainly the resolution and accuracy of the signal.

I myself wouldn't think so because both of them use a 16bit timer, so using the same clock frequency there should be no difference, right?

Hopefully in this cary the theoretical case is closer to the practical case!

  • Is not the "dead-band" - mentioned & employed by you in earlier (similar) posts - "lost" when you migrate from the PWM Generator?

    You also expressed desire to control motor currents - something (very) well managed (& near automated) by the PWM Generator - not so much by a lowly timer...

    MCU Design teams - this vendor & others - made great efforts in developing the PWM Generators - may be unwise to bypass such capability...

  • @cb1-, the dead-band is indeed lost when I would migrate from the PWM generator to the timer block, however I was curious to see what would happen to other aspects of the signal, hence why I thought I would quickly ask here to see if anybody had already looked into this.

    In regards to controlling motor currents, how does the PWM generator manage to do this "well & near automated"?
  • Serious, focused read of the PWM Generator section - w/in the MCU manual - suggests & reveals.

    The PWM Generator provides a "PWM Fault Input" pin - which enables the instant (and automatic) suppression of the PWM output(s) - by a controlled and programmed PWM configuration. (again - only available via the PWM Generator)

    There's far more for you to read & consider - my goal was to "entice your study" - every application enjoys subtle differences.

    I can report that our small firm has long achieved robust & precise, "Cycle by Cycle" current limiting - through the use of the PWM Generator.
  • @cb1-, that's pretty interesting you managed to employ "Cycle by Cycle" current limiting through the use of the "PWM Fault Input" pin. I was more under the impression this was for something such as to disable the PWM signals when a short-circuit or over-temparature is detected.

    I presume your small firm does it by triggering an ADC digital comparator which compares the measured current to a certain threshold, and throttles the PWM signal if this measured current exceeds the threshold?
  • cb1- said:
    The PWM Generator provides a "PWM Fault Input" pin - which enables the instant (and automatic) suppression of the PWM output(s) - by a controlled and programmed PWM configuration.

    I have in the past had to implement such a feature in external hardware. While not difficult to do it would have nice to have support in the micro. Be careful about two things

    • short off times
    • negative currents

    Also motors are large inductors and have slow rise and fall times compared to resistors.

    Robert

  • As we (well) trained, NYC, high school French students state, "Mais certainement mon ami - mais certainement!"

    Yet we use "not" the MCU's "digital" comparator - we use the MCU's "analog" comparator! (the output of that comparator - as poster bp101 now notes - remains digital) There's a bit of indirection & test/verify too - and this method spectacularly reduces the impact of brief/transient "nuisance" over-currents - and in most all cases such faults are, "self-clearing!" (ideal that!)

    MCU manual "hints" - you must invest (some) time/effort to "tease out" fine detail.      Again a treasure trove of discovery awaits those of sufficient motivation...
    Still wish to employ the timer?     

    Is it not appropriate to Verify answer - btw?

  • @cb1-, I'm sort of understanding your approach when I do a closer read of the PWM section in the MCU manual. I'm a bit unsure as how you "control" your "Cycle-by-Cycle" limit.

    I understand I can throttle the PWM signal on a fault condition, in my case if my current exceeds my threshold, but from my (admittely limited) knowledge of the MCU, this would throttle the PWM signal simply by just pulling it low. It is not "regulating" the signal to a "logical low" or "0% duty cycle PWM signal".

    @Robert, cheers for pitching in with your experience, only aids in the quest to get this all up and running!

    Sorry this has sort of gone off-topic, but the comments and questions from your ends raised more comments and questions from my end! Although I can now safely say, I won't be using the timer ;-).
  • Minus the requested (and well earned - yet lacking) Verify - this reporter departs...

  • James Kent69 said:
    this would throttle the PWM signal simply by just pulling it low. It is not "regulating" the signal to a "logical low" or "0% duty cycle PWM signal".

    Think about how much the current decays during the extended off time (extended by the fault input).  Also read up on switch-mode power supplies.

    I am assuming you are not using a very low inductance motor or PWM frequency. Sketch out the waveforms, it's simple enough to do by hand and worth the knowledge gained by doing so.

    Robert

  • If I can join the debate,

    , why the "analog" comparator instead of the "digital" one? Any particular reason for that choice?
  • I don't know about cb1 but I would have two reasons for using the analog comparator

    • Independence.  It is purely analog and will continue to work even if the SW stops or the A/D stops
    • Speed, it should provide sub-uS response.  

    Robert

  • Luis Afonso said:
    , why the "analog" comparator instead of the "digital" one? Any particular reason for that choice?

    Several justifications:

    a) faster response from an, "Always there - always on" Analog Comparator - don't you agree?

    b) we sought to replace our long tried/tested "discrete analog comparator" design w/one embodied w/in MCU.

    c) I'm inexpert in this vendor's digital comparators - but those here (or elsewhere) did not have the resolution nor range of analog - both important for current limiting

    and d) [best for last] Once set up/configured the analog comparator is almost (perhaps completely) free from SW "mishaps!"     When trip-point is reached - the analog comparator's output (btw - just 2 pins away from PWM Fault Input) - kills all PWM outputs (for a programmable period) and then resets - ready for the next "current cycle."     Automatic - hands-off approach - is especially appreciated/valued by our firm's clients...

    I'm unaware of any debate here - down the dial - "debate rages."

    Thanks to you/Robert nearly 600 "hits" have landed on, "Tell T.I."    (few others seem to care - but headline writer - and you two - have done their jobs...)

  • @Robert, so if I got it right, it's because the current is limited within one PWM cycle there is no need to regulate it? With this I mean because it's all happening so fast, when it exceeds the threshold, it decreases itself at a rate dependant on the load, and then increases again when it gets to the next cycle.

    As for selecting a limit for the current, any guidelines? Or is it simply enough to match the in-rush current?
  • The "Cycle by cycle" current limiting I past described has long been an industry standard - and usually is chosen due to quick response and an "automatic & convenient" measurement interval.

    In our case - we drive our BLDC motor controls @ 20KHz (just above "most" human hearing) and our PWM Generator "triggers" our phased current measures very near "center" of the PWM waveform. Our clients often seek current or torque control - and the analog comparator - feeding the PWM Fault input - performs very nicely in this regard. (i.e. enables fully adjustable - and programmable - and dynamically changeable current control!)    (i.e. '3 for the price of 1!")

    When the measured current (as determined by the analog comparator) exceeds our adjustable set-point all PWM outputs are disabled - for a "user adjustable" time period. This enables the best "match" for a wide range of motor loads & operating conditions.

    Our Tek current probe indeed reveals the motor current near "flat-lining" when we approach - or even "transiently exceed" - the current limit. Should an over-current transient occur - the PWM disable will cause that current to quickly decay - and (most often) the PWM will be re-enabled during the next PWM cycle. (50µS @ our 20KHz PWM rate) This "self-clearing" of over-currents is fully automatic - does not rely upon any SW (after set-up/config) thus is greatly valued due to its robustness.

    Thank you for your verify - always appreciated.

  • James Kent69 said:
    Or is it simply enough to match the in-rush current?

    There should not be any inrush current when you are controlling with the micro.

    There should be a current limit that limits the torque/acceleration.  This will be determined by the maximum load at maximum acceleration. If you control this in SW then you can set a HW limit above that. At the very least the HW limit should be below the level that your power devices and motor can handle.

    I've often used multiple current limits in parallel, a fixed short term limit that limits peak to protect the power devices, usually in HW. A short term limit to limit the peak torque and provide longer term power protection. A long term limit to protect the motor from heating under sustained load.

    James Kent69 said:
    so if I got it right, it's because the current is limited within one PWM cycle there is no need to regulate it?

    Almost.  Because the current is limited in one cycle it is regulated. The motor inductance is large enough that the ripple is small.  When switching in the 10's of kHz the current decay constant through the free wheeling diodes is many cycles.  Consider the voltage drop in freewheel conditions is around a volt V/L will be small compared to the V/L when you apply power during the on cycle.  Current decay is longer than current attack.  Essentially you get a constant current when in limit is this fashion.

    Robert

  • One other advantage, comparators can often be simply paralleled (provided they are not push-pull output). In the OPs case, it might be worth added a comparator on the DC bus voltage so if regen raises bus voltage above a certain level the power stage turns off. If the fuse on the DC bus blows that rise can be very rapid.

    Robert
  • /\
    and this kind of posts is why some trips to the forum are better than theoretical classes (*keeps on reading*)
  • Robert Adsett said:
    Essentially you get a constant current when in limit is this fashion.

    As Robert states (above) and our earlier post noted, "flat-lining" of current as revealed by Tek current probe.     That "flatness" confirms near constant current.

    Robert raises a very important "safety" point.     Indeed - it proves mandatory to have an, "Undefeatable, upper current limit" in place!     Such insures that any/all power components - the motor - and the power supply never exceed their limits!     (more than once this has saved us & clients!)

    To make our control products more compelling - in addition to that fixed/unalterable upper current limit - we provide a fully adjustable limit - so that user may "dial-in" their desired current and/or torque limit.    

    This leads to the need for effective current measurement - as we further exceed and stray - from this thread's (beginning/announced) intent...

  • @cb1-, I know it’s been around for a while, but I was never under the impression something like this could be done using a TM4C LaunchPad, I’m getting more and more impressed with this thing.

    cb1- said:
    When the measured current (as determined by the analog comparator) exceeds our adjustable set-point all PWM outputs are disabled - for a "user adjustable" time period. This enables the best "match" for a wide range of motor loads & operating conditions.

    Robert said:
    There should be a current limit that limits the torque/acceleration.  This will be determined by the maximum load at maximum acceleration. If you control this in SW then you can set a HW limit above that. At the very least the HW limit should be below the level that your power devices and motor can handle.

    So if I’m understanding this all correctly, what you two are both saying here is that the “adjustable set-point” is essentially my maximum current which I’ve determined by measuring the maximum current drawn at load. I.e. my motor loaded and fully spinning would pull 2A, therefore for safety measures I’d make it 1.9A.

    Robert said:
    Almost.  Because the current is limited in one cycle it is regulated. The motor inductance is large enough that the ripple is small.  When switching in the 10's of kHz the current decay constant through the free wheeling diodes is many cycles.  Consider the voltage drop in freewheel conditions is around a volt V/L will be small compared to the V/L when you apply power during the on cycle.  Current decay is longer than current attack.  Essentially you get a constant current when in limit is this fashion.

    I’m sort of understanding this. It is basically due to the nature of the how the inductive load works in combination with the current being limited in one cycle that allow it to be “self-regulating”.

    Robert said:
    In the OPs case, it might be worth added a comparator on the DC bus voltage so if regen raises bus voltage above a certain level the power stage turns off. If the fuse on the DC bus blows that rise can be very rapid.

    With this you mean I’m comparing my bus voltage to actual voltage across my “system”, and shut it off when it exceeds this due to the current being built up in my load?

    Luis said:
    and this kind of posts is why some trips to the forum are better than theoretical classes (*keeps on reading*)

    I couldn’t agree more! I’m still amazed at the knowledge and amount of detailed responses I’m getting here. I find it fascinating how some of you have managed to find such practical solutions using the TM4C.

    cb1- said:
    This leads to the need for effective current measurement - as we further exceed and stray - from this thread's (beginning/announced) intent...

    I’m sorry for straying off-topic, but I wouldn’t want to continuously start new topics when it is probably for the best to keep it all compiled somewhere. Maybe I should edit the title so that fellow enthusiasts who are using the TM4C for similar applications may find this thread quicker.

  • My vote would be to start new thread for (serious) current measurement and resulting control...       An overload proves unwise - both in motor control AND tech "search/find/organizing."       One subject - per 8.5x11" paper note sheet - is easy to organize/file.      Ten subjects - same sheet - impossible to file & (later) find!

  • James Kent69 said:
    I’m sort of understanding this. It is basically due to the nature of the how the inductive load works in combination with the current being limited in one cycle that allow it to be “self-regulating”.

    That's the idea.  It's also how switch mode supplies generally work.

    James Kent69 said:
    Robert
    In the OPs case, it might be worth added a comparator on the DC bus voltage so if regen raises bus voltage above a certain level the power stage turns off. If the fuse on the DC bus blows that rise can be very rapid.

    With this you mean I’m comparing my bus voltage to actual voltage across my “system”, and shut it off when it exceeds this due to the current being built up in my load?

    What I mean is comparing the bus voltage across your H bridge to some limit.  If you exceed that limit you shut off the PWMs. This is your protection against the power section blowing up or catching fire due to an overvoltage.

    James Kent69 said:
    I.e. my motor loaded and fully spinning would pull 2A, therefore for safety measures I’d make it 1.9A.

    Not quite, that would shut down your motor if loaded for an extended period of time.

    There is a limit to the load your motor can handle without overheating.  It will be documented either in load curves or as a current. This is a long term limit, it general take minutes or 10's of minutes for this to happen so it is a limit on the long term current rather than the short term.  Best done in SW there are several ways to implement it.  You could shut down, you could use the long term average to limit the available short term peak, etc...

    Very short term your limit is coming from your power section limits, demagnetization limits (although modern PMs are less affected), brush limits etc..

    Short tem you limit to the amount of torque you want as the maximum. Peak torque available is usually considerably more than the thermal limit and usually whatever you are hooked up to has limits lower than the motor is capable of producing.

    James Kent69 said:
    . I find it fascinating how some of you have managed to find such practical solutions using the TM4C.

    I think you will find both cb1 and myself have used considerably less capable micros for this task. The TIVA series has a luxurious amount of peripheral support and computing horsepower in comparison.

    James Kent69 said:
    I’m sorry for straying off-topic

    That's often the most interesting part.

    Robert

  • Robert Adsett said:
    That's often the most interesting part.

       (i.e. straying from topic)

    Oh Robert!     (there you go again - encouraging breach of order!)

    Robert, "although modern PMs are less affected" - while (generally) true - we find that latest/greatest,  "Sintered, Rare Earth Magnets" (most powerful - by far) are sensitive to over-temperature - and may be weakened by such exposure.     To combat - we (and others) employ temperature sensors @ key points w/in the motors - to provide early warning - and prevent (expensive) damage!

    And just as Robert states - Cortex M4's power really is not required - far older (and lesser) MCUs have worked - although often require some, "assistance."     While not yet (ever?) gracing this vendor's portfolio - we've succeeded w/humble Cortex M0+.

    Our findings/recommendations - use the best MCU you kinow to, "Prove the concept - Win the order" and attempt to, "Cost/Size reduce" downstream - only as/if client & mission needs dictate...

  • cb1- said:
    Oh Robert!     (there you go again - encouraging breach of order!)

    Felix, you call me Oscar :)

    cb1- said:
    Our findings/recommendations - use the best MCU you kinow to, "Prove the concept - Win the order" and attempt to, "Cost/Size reduce" downstream - only as/if client & mission needs dictate...

    The TIVA's are probably less expensive than the 16bit micro +memory combination I was using.

    It would be worth the price for its extra capabilities for the small H-bridge controller (around 10kW IIRC) we did I think.

    Robert