L9110 motor controller

RS_JimRS_Jim Posts: 1,005
edited December 2014 in Propeller 1 Vote Up0Vote Down
Hi,
Has anyone done an L9110 pwm motor control object?
Jim

Comments

  • 24 Comments sorted by Date Added Votes
  • Bill HenningBill Henning Posts: 6,434
    edited November 2014 Vote Up0Vote Down
    I used the PWM32 object with an L9110S in my Elf robot (RoboPi + Raspberry Pi)

    PWM32 works well for controlling motor speed.

    http://www.mikronauts.com/robot-zoo/elf-2wd-pi-robot/
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • Duane DegnDuane Degn Posts: 9,984
    edited November 2014 Vote Up0Vote Down
    PWM32 works well for controlling motor speed.

    I don't think PWM32 is really intended to drive inductive loads where the PWM frequency can be very important.

    From the comments:
    This implementation is
    unique in that it does not lump the high times and low times together per period.
    Instead, high/low times are distributed evenly across a period.
    

    I take the above to mean the usual terms "duty cycle", "frequency" and "period" don't apply to PWM32.

    Many motors are very finicky about the PWM frequency and I don't think the frequency of the PWM32 is always easy to figure out. I believe PWM32 was written with driving LEDs rather than motors in mind.

    I have a bunch of different motor control drivers floating around. I think one of the simpler ones is limited to two motors and uses the Prop's counters to generate the pulses (with a method borrowed from the PEK).

    I believe the code attached to this post is usable.

    While I'm pretty sure it would work with a L9110 controller, I haven't tried using one with it. If you have any trouble let me know and I'll find one of my L9110 boards and test it out.

    I intend to use the code to test various motors at different frequencies The speed (duty cycle), resolution and frequency can all be adjusted on the fly using a terminal window as input.
  • RS_JimRS_Jim Posts: 1,005
    edited December 2014 Vote Up0Vote Down
    Thanks DD,
    I hopefully will be able to check it out Wed. From now until after Christmas I am working 6 days a week so hobby time is severely restricted.
    Jim
  • Bill HenningBill Henning Posts: 6,434
    edited December 2014 Vote Up0Vote Down
    Hi Duane,

    The original PWM32 in Obex does pwm by specifying how many "cycles" the signal is on, and how many it is off for, which is different from the classic period and duty cycle - however it can be mapped to it.

    I modified it such that on/off cycles can be specified in a 5us grain (at 100Mhz) so I can control the pwm frequency and period reasonably well, with the limitation that higher PWM frequencies have a more limited resolution.

    For example:

    100kHz pwm can only be 0%, 50%, 100%

    10kHz pwm can be 0%-100% in 5% steps

    2kHz pwm can be 0%-100% in 1% steps

    200Hz pwm can be 0%-100% in 0.1% steps

    Currently I find this level of control to be sufficient for my purposes, and it works fine with the L9110S drivers and Magician chassis (ie Elf) ... but I am pretty sure a different method would be better for brushless motor.

    I have been considerign enabling two high speed / high frequency / high precision PWM's using the counters in the PWM cog, and two more in the command interpreter cog.
    Duane Degn wrote: »
    I don't think PWM32 is really intended to drive inductive loads where the PWM frequency can be very important.

    From the comments:
    This implementation is
    unique in that it does not lump the high times and low times together per period.
    Instead, high/low times are distributed evenly across a period.
    

    I take the above to mean the usual terms "duty cycle", "frequency" and "period" don't apply to PWM32.

    Many motors are very finicky about the PWM frequency and I don't think the frequency of the PWM32 is always easy to figure out. I believe PWM32 was written with driving LEDs rather than motors in mind.

    I have a bunch of different motor control drivers floating around. I think one of the simpler ones is limited to two motors and uses the Prop's counters to generate the pulses (with a method borrowed from the PEK).

    I believe the code attached to this post is usable.

    While I'm pretty sure it would work with a L9110 controller, I haven't tried using one with it. If you have any trouble let me know and I'll find one of my L9110 boards and test it out.

    I intend to use the code to test various motors at different frequencies The speed (duty cycle), resolution and frequency can all be adjusted on the fly using a terminal window as input.
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • RS_JimRS_Jim Posts: 1,005
    edited December 2014 Vote Up0Vote Down
    I am back to working 5days with a bit more reasonable hours. Bill, could you send me a copy of your modified pwm32 to try out. It seems that it has disappeared from obex. DD I looked at your link and it was for the LM 397.
    Jim
  • Pwm32 has found its way back into obex and I downloaded it and started studying it. It is really very simple. I made a test version to run 2 motors with my L9110 and it worked like a charm, once I overcame minor hardware issues. Now to figure out the best PWM frequency to use with my motors.
    Jim
  • RS_Jim wrote: »
    DD I looked at your link and it was for the LM 397.

    Yes, I don't think my driver would work well with the L9110. My driver assumes there's an enable pin to pulse (such as the L298 or MC33926.

    I think you'll want to use a relatively high PWM with the L9110 since it doesn't have a coast state. The driver has to be used with pulse/brake rather than pulse/coast. H-bridges such as the L9110 will cause the motor to brake between high pulses. This can really sound horrible when used with a metal gears and low frequency PWM. I believe the noise from the motors braking between drive pulses can be minimized with a higher PWM frequency but I don't know how high of a frequency is possible with the L9110.

    Pulse/brake type h-bridges will use more power than pulse/coast h-bridges since the motion imparted during the high pulses is partially removed during the braking phase of the PWM cycle.

    I'm pretty sure one wouldn't want to use pulse/brake with a large motor but the technique seems to be pretty common for small motors.

  • MJBMJB Posts: 884
    edited September 2015 Vote Up0Vote Down
    Duane Degn wrote: »
    RS_Jim wrote: »
    DD I looked at your link and it was for the LM 397.

    Yes, I don't think my driver would work well with the L9110. My driver assumes there's an enable pin to pulse (such as the L298 or MC33926.

    I think you'll want to use a relatively high PWM with the L9110 since it doesn't have a coast state. The driver has to be used with pulse/brake rather than pulse/coast. H-bridges such as the L9110 will cause the motor to brake between high pulses. This can really sound horrible when used with a metal gears and low frequency PWM. I believe the noise from the motors braking between drive pulses can be minimized with a higher PWM frequency but I don't know how high of a frequency is possible with the L9110.

    Pulse/brake type h-bridges will use more power than pulse/coast h-bridges since the motion imparted during the high pulses is partially removed during the braking phase of the PWM cycle.

    I'm pretty sure one wouldn't want to use pulse/brake with a large motor but the technique seems to be pretty common for small motors.
    just had a look at the datasheet and now understand what you are saying.
    while a 'normal' bridge can put the motor terminals in high-Z (coast)
    the L9110 can only drive forward 10 or backward 01 or goes into 00 grounding both pins, therfore leading to mentioned braking.
    ... didn't see this when I ordered them :-(

    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • Peter JakackiPeter Jakacki Posts: 6,316
    edited September 2015 Vote Up0Vote Down
    Interesting as I though MJB was talking about my PWM32 object but I didn't realize that there was already one by the same name in the obex. However they are not the same, my PWM32 is a fixed frequency up to 7.6kHz for 8-bit resolution and it is possible to have higher frequencies on some channels by reducing the resolution on those channels. So for motor control you would probably choose a lower frequency but all 32-channels operate without any problems or jitter etc although it sounds like the L9110 can't be PWM'd anyway. The phase can be adjusted for any channel as well.

    I think I will rename my object in view of all this then.
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Brisbane, Australia
  • Interesting as I though MJB was talking about my PWM32 object but I didn't realize that there was already one by the same name in the obex. However they are not the same, my PWM32 is a fixed frequency up to 7.6kHz for 8-bit resolution and it is possible to have higher frequencies on some channels by reducing the resolution on those channels. So for motor control you would probably choose a lower frequency but all 32-channels operate without any problems or jitter etc although it sounds like the L9110 can't be PWM'd anyway. The phase can be adjusted for any channel as well.

    I think I will rename my object in view of all this then.

    @Peter: I wasn't talking about PWM here.
    And I don't think there is too much confusion about it anyway.
    Non-Tachyon people talk about the PASM/SPIN object from OBEX,
    and in the Tachyon thread we talk about the Tachyon-PWM32.

    Maybe calling the Tachyon PWM32 module an OBJECT can cause confusion,
    since in the normal Forum speak Objects relate to SPIN/PASM.
    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • @MJB

    Have you looked at what it does for 11 ?
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • MJB wrote: »
    Interesting as I though MJB was talking about my PWM32 object but I didn't realize that there was already one by the same name in the obex. However they are not the same, my PWM32 is a fixed frequency up to 7.6kHz for 8-bit resolution and it is possible to have higher frequencies on some channels by reducing the resolution on those channels. So for motor control you would probably choose a lower frequency but all 32-channels operate without any problems or jitter etc although it sounds like the L9110 can't be PWM'd anyway. The phase can be adjusted for any channel as well.

    I think I will rename my object in view of all this then.

    @Peter: I wasn't talking about PWM here.
    And I don't think there is too much confusion about it anyway.
    Non-Tachyon people talk about the PASM/SPIN object from OBEX,
    and in the Tachyon thread we talk about the Tachyon-PWM32.

    Maybe calling the Tachyon PWM32 module an OBJECT can cause confusion,
    since in the normal Forum speak Objects relate to SPIN/PASM.

    Then you have indeed been wrongly attributed. I checked and that was Duane saying that PWM32 couldn't be relied upon for a stable frequency.
    @Duane: So this is the output of 20 channels of Tachyon-PWM32 at 7.6kHz. Phase of each channel can easily be adjusted.


    Screenshot%20from%202015-09-10%2023%3A15%3A23.png
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Brisbane, Australia
  • I checked and that was Duane saying that PWM32 couldn't be relied upon for a stable frequency.

    Peter,

    My initial comments about the PWM object were directed towards the one in the OBEX which was intended for use with LEDs. I'm still under the impression it's not suitable for motor control. Apparently Bill has modified the object for use with motors. The comment in code blocks is a quote from the object.

    My latest comment concerned the limitations of the h-bridge hardware.

    I realize in hindsight my comments about pulse/brake and pulse/coast assumed people were already familiar with these terms. MJB did a good job of filling in the important details I had left out.

  • Peter JakackiPeter Jakacki Posts: 6,316
    edited September 2015 Vote Up0Vote Down
    Duane Degn wrote: »
    My latest comment concerned the limitations of the h-bridge hardware.

    I realize in hindsight my comments about pulse/brake and pulse/coast assumed people were already familiar with these terms. MJB did a good job of filling in the important details I had left out.

    Coast vs brake, what's the difference? :)

    I remember one design I did which had a metal grinding disk with rather nasty looking edges on a 12V motor and even though this part of it wasn't a bridge it had a couple of those hefty "120A" MOSFETs in parallel and had to soft start the motor otherwise the 14A PSU couldn't cope unless a battery was used. Anyhows, when that grinding disk got up to speed I had to allow for an emergency stop but I found out very quickly that you don't put the electronic brake on this baby as the grinding disk unscrewed itself and in the manner of Oddjob's razor-edged bowler hat, left the building slicing within an inch of me as it made its exit!!! My client sitting opposite me didn't say too much, the look was enough, after that we kept a respectful distance from it when testing this part of it.

    The trouble I see with being stuck with braking PWM on this L9110 though is that besides the mechanical dynamics of doing so, it also has to dissipate that energy back through one of clamp diodes at least and that means heat. When I didn't put a brake on the grinding wheel it would continue to power the whole unit and the other motors even after the power was cut. I had to use a TO220 dual Schottky to isolate that part of it which meant the grinding wheel took even longer to spin down. You couldn't really say "dems the brakes" :)


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Brisbane, Australia
  • MJBMJB Posts: 884
    edited September 2015 Vote Up0Vote Down
    kwinn wrote: »
    @MJB

    Have you looked at what it does for 11 ?

    just 2 0r 3 clicks away
    datasheet L9110
    it does the same as 00 and grounds both motor lines - i.e. brakes :-(

    looks like the difference between coast and brake is the currents flowing, while the motor is not powered.
    Ideally in coast you would want the drivers really High-Z, so no currents means no braking moment.
    But of course in semiconductors at some reverse voltage you need some freewheeling protection
    for the device, like diodes or z-diodes otherwise the voltage will fry them.
    But here it looks both lower FETs are connecting to ground at low resistance.
    I will measure it when I am back at the bench.
    So this will allow big currents to flow and hence brake a lot.

    And as Peter said - this energy needs to be dissipated.
    if the FET is really low R, than that happens in the motor coil resistance and not the driver chip.

    OR do I miss something ??

    I did not realize before I ordered a number of them - but for my application it is OK
    Just to drive a ball-valve motor at 3-5V.
    3V is even better since it is slower and I can better adjust the temperature mix in my solar and heating system.

    from the MAX20082 dual, full-bridge controller datasheet
    The H-bridge can be driven in forward mode (clockwise),
    reverse mode (counterclockwise),
    braking mode, and coast mode.
    In braking mode, both the low-side MOSFETs are turned on (synchronous slow decay).
    In coast mode, all the MOSFETs in the H-bridge are off (asynchronous fast decay).
    The power MOSFETs are protected from shoot-through by a resistor-adjustable dead-time circuit.
    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • Duane DegnDuane Degn Posts: 9,984
    edited September 2015 Vote Up0Vote Down
    The trouble I see with being stuck with braking PWM on this L9110 though is that besides the mechanical dynamics of doing so, it also has to dissipate that energy back through one of clamp diodes at least and that means heat.

    I see lots of pulse/brake type h-bridges in hobby robotics. Apparently it's easier to control a motor's speed using pulse/brake than when using pulse/coast. If a small robot doesn't have encoders, then pulse/brake apparently will allow more precise control of the robot.

    IMO, the disadvantages of using pulse/brake type h-bridges makes them unsuitable for all but the smallest of motorized projects.

    I raised this question over on the Pololu forum since at least one of their h-bridge shields ties the enable pin high and pulses one of the direction pins for speed control.

    As I mentioned in this post, I found a dramatic difference between pulse/brake and pulse/coast. At 200Hz, pulse/brake causes the gears to produces a sound suggesting the gearbox is about to come apart. It sounds awful. In contrast pulse/coast sounds like a nice friendly growl. I didn't record the numbers, but there was a significant difference in the current draw between the two types of drive with pulse/coast the clear winner.

    Ben at Pololu seems to think there are times when pulse/brake is the better choice though the link he kindly provided for me confirmed my thoughts about pulse/brake.



  • Duane Degn wrote: »
    As I mentioned in this post, I found a dramatic difference between pulse/brake and pulse/coast. At 200Hz, pulse/brake causes the gears to produces a sound suggesting the gearbox is about to come apart. It sounds awful. In contrast pulse/coast sounds like a nice friendly growl. I didn't record the numbers, but there was a significant difference in the current draw between the two types of drive with pulse/coast the clear winner.

    Ben at Pololu seems to think there are times when pulse/brake is the better choice though the link he kindly provided for me confirmed my thoughts about pulse/brake.
    great link - thanks


    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • MJBMJB Posts: 884
    edited September 2015 Vote Up0Vote Down
    If you really want to understand it better ...
    more detail about this theme is here

    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • MJB wrote: »
    If you really want to understand it better ...
    more detail about this theme is here

    I see what I'm calling "brake" is known as "slow decay mode" which the article confirms is a fast way to stop a motor but I didn't see any info about coasting.

  • MJBMJB Posts: 884
    edited September 2015 Vote Up0Vote Down
    Duane Degn wrote: »
    MJB wrote: »
    If you really want to understand it better ...
    more detail about this theme is here

    I see what I'm calling "brake" is known as "slow decay mode" which the article confirms is a fast way to stop a motor but I didn't see any info about coasting.
    it is in there ... - very good explantion
    When it comes to DC motors, however, there is a very interesting effect while using this decay mode. 
    While on fast decay mode the DC motor rotor coasts down in speed, 
    with slow decay mode the rotor stops very quickly. 
    This is because as can be seen by the above picture, you are shorting the DC motor terminals. 
    This in essence implies the BACK EMF voltage source inside the motor to be shorted. 
    And if there is no BACK EMF, there can be no speed. One is directly tied to the other. 
    call this phenomenon braking the DC motor or the collapse of the Back EMF. 
    Braking is vital when you want to stop your motor very fast and possibly obtain a particular position. 
    With coasting, this would not be possible, so be aware that selecting slow decay or fast decay 
    with DC motors is not a trivial endeavor.
    
    I like to point out, when I discuss slow and fast decay mode, that the names “slow” and “fast” 
    are pertinent to current, not to DC motor speed. They imply a direct relationship with how fast 
    the current decays through the winding. However, when it comes to how fast the DC motor speed decays, 
    it is the total opposite. Kind of annoying, but I guess one thing leads to the other. 
    So be careful not to think that fast decay will stop the motor very fast, because it is actually the opposite.
    
    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • If I now understand this correctly then at a sufficiently high PWM frequency (depending on the inductivity of the motor)

    we could simulate the coast / fast decay behaviour with the L9110 by
    e.g. if the two signal inputs are 10 for forward then in the PWM pause we need to switch to 01 and not 00 or 11.
    So we kind of need the PWM and the inverted PWM for the other input signal pin.

    I don't have the equipment to test this out,
    but those with the rattling motor should easily be able to hear the difference.

    Important is that the PWM low is sufficiently short to not go to reverse current and start to drive the motor backward.
    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • Duane DegnDuane Degn Posts: 9,984
    edited September 2015 Vote Up0Vote Down
    MJB wrote: »
    . . . we could simulate the coast / fast decay behaviour with . . .

    I'm pretty sure coast is not the same as fast decay. When a h-bridge switches to a high-Z state (coast), I think you end up with a circuit like this:

    CaseC.PNG

    While a motor is coasting, neither end of the motor is connected to power or ground.

    I think the only reference to the coast state the page makes is the mention that you can't brake with a coast state.
    Braking is vital when you want to stop your motor very fast and possibly obtain a particular position.
    With coasting, this would not be possible, so be aware that selecting slow decay or fast decay
    with DC motors is not a trivial endeavor.

    I don't think the above mean fast decay is the same as coast. I believe slow decay and fast decay are the two braking options being explored in the article.

    The fast decay example given shows the current being fed back to the battery. I believe this is also known as regenerative braking (I'm not sure about this). I think this is an alternate way of stopping (braking) a motor rather than shorting the motor leads together (the slow decay circuit connects both leads to ground thus shorting the leads together).

    I still think the article excludes the topic of allowing a motor to coast to a stop other than mentioning one can't brake while coasting.

    I attempted to find another source on fast decay and slow decay but the reference which came up disagreed with this article. The book Intermediate Robot Building appear to get this all wrong. The author calls "slow decay", "fast decay" and calls "coasting", "slow decay". "Coasting" is neither "fast decay" or "slow decay".

    Of some help was this pdf by Microchip which states (on page 4) all four switches (FETs) need to be off in order for the motor to coast.

    I still don't think there is a way to set the inputs of a L9110 in a way which will result in the motor coasting.
    456 x 248 - 33K
  • MJBMJB Posts: 884
    edited September 2015 Vote Up0Vote Down
    Duane Degn wrote: »
    I'm pretty sure coast is not the same as fast decay. When a h-bridge switches to a high-Z state (coast), I think you end up with a circuit like this:

    While a motor is coasting, neither end of the motor is connected to power or ground.

    I don't think the above mean fast decay is the same as coast. I believe slow decay and fast decay are the two braking options being explored in the article.

    The fast decay example given shows the current being fed back to the battery. I believe this is also known as regenerative braking (I'm not sure about this). I think this is an alternate way of stopping (braking) a motor rather than shorting the motor leads together (the slow decay circuit connects both leads to ground thus shorting the leads together).

    I still think the article excludes the topic of allowing a motor to coast to a stop other than mentioning one can't brake while coasting.
    ...
    Of some help was this pdf by Microchip which states (on page 4) all four switches (FETs) need to be off in order for the motor to coast.

    I still don't think there is a way to set the inputs of a L9110 in a way which will result in the motor coasting.
    Duane,
    I agree.
    I see coasting in it's 'normal' sense is for time >> PWM-period.
    This can not be acomplished with the L9110.
    since it required all FETs off.

    The other thing is the rattling you talk about -
    which is the fast vs. slow decay.
    So fast decay during the PWM low would give a kind of 'coast' just during the PWM-low
    if and only if the time constant of the motor inductor/resistances is big enough.
    That is why I assume this mode would reduce the rattling.
    And this seems possible with the L9110.

    hope to try it next week or so ..




    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • ercoerco Posts: 17,854
    Duane Degn wrote: »

    I think you'll want to use a relatively high PWM with the L9110 since it doesn't have a coast state. The driver has to be used with pulse/brake rather than pulse/coast. H-bridges such as the L9110 will cause the motor to brake between high pulses. This can really sound horrible when used with a metal gears and low frequency PWM. I believe the noise from the motors braking between drive pulses can be minimized with a higher PWM frequency but I don't know how high of a frequency is possible with the L9110.

    Pulse/brake type h-bridges will use more power than pulse/coast h-bridges since the motion imparted during the high pulses is partially removed during the braking phase of the PWM cycle.

    I'm pretty sure one wouldn't want to use pulse/brake with a large motor but the technique seems to be pretty common for small motors.

    Just found this searching for L9110 info. Didn't know that L9110 lacked coast. These are the chips on my tiny Hack-a-Bot. I PWMed it 72 hz, the lowest a Picaxe(!) can go, and it appears to work fine. I instinctively go for low PWM frequencies, 'cuz I hate hearing motors squeal and not turn (typical of HF hobby RC car speed controllers). I have a pile of cheap unused L9110 controllers which are planned for small bots (800 mA max) so I guess my stockpile will slowly be consumed as planned.

    "When you make a thing, a thing that is new, it is so complicated making it that it is bound to be ugly. But those that make it after you, they don’t have to worry about making it. And they can make it pretty, and so everybody can like it when others make it after you."

    - Pablo Picasso
Sign In or Register to comment.