Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.





Pages: [1]
Author Topic: BLDC motor control
Mr.What
Administrator
Posts: 154
Permalink
Post BLDC motor control
on: August 7, 2012, 07:32
Quote

Building a BLDC controller for Arduino. Plans are to accept a speed control input by clocked bits input through digital I/O, for faster, less intrusive commanding.

It will also try a novel commutation concept where the driving pulse will be controlled duration and timing, instead of PWM over the whole commutation cycle.

I started "blogging" on this under the Arduino project, but now that I am actually trying to build it, I'm giving it its own project thread.

An initial circuit was built, but it seems to have some unexplained current in the non-driven motor leg that I do not understand.

Here is a video of the circuit running, open loop, with diagnostic LEDs.
http://www.youtube.com/watch?v=z_LWduSsThI

Derivation of frequency response for Low-Pass filtered voltage divider sensor for un-driven leg of motor is described at
http://boim.com/misc/LPFVoltageDivider.html

Mr.What
Administrator
Posts: 154
Permalink
Post Re: BLDC motor control
on: August 13, 2012, 14:53
Quote

I want to be able to set up an Arduino interrupt where the ISR sets the time for the next interrupt. The period is changing (according to the BLDC control logic). At each interrupt, I want to re-compute the time for the next interrupt and set it.

Any advice on how to go about setting up this kind of variable-period timer interrupt?

Mr.What
Administrator
Posts: 154
Permalink
Post Timer Interrupts
on: August 14, 2012, 12:39
Quote

This article http://www.uchobby.com/index.php/2007/11/24/arduino-interrupts/ seems to re-set the timer interrupt counter inside the ISR. I will want to do something like this to frob the commutation cycle change timer from inside the commutation step itself. Problem is that if I dedicate Timer2 to do my commutation, I will need to re-wire the circuit to use only 1 pin for the PWM output. (AND it with the high-side enable pin outs). To do this I'll need some logic gates.

The second? example in the article frobs the timer to adjust for interrupt response latency. I think I could do something like this to set the "sleep" time to when I want to wake up and move to the next commutation cycle.

Mr.What
Administrator
Posts: 154
Permalink
Post Grey decode logic
on: August 14, 2012, 14:00
Quote

I should go to a grey code for the decommutation sequence. It will save 2 pins (and a timer), and it is safer since a node would be logically unable to be connected to V+ and ground simultaneously.

For three grey code bits, g2, g1, g0,

    comm      grey
    phase     code
      0        000
      1        001
      2        011
      3        111
      4        110
      5        100

I get the transistor "on" signals:

   Al = ~(g2 v  g1)
   Bl =   g1 ^  g0
   Cl =   g2 ^ ~g0
   Ah =   g2 ^  g1
   Bh = ~(g1 v  g0)
   Ch =  ~g2 ^  g0

I would want to add an extra enable signal for all the high transistor switches. That is 3 more AND gates for the en pin on the Xh signals.

How should I do this logic? Is a couple of LSI DIP chips still the way to go... or is there something more compact available these days? A small programmable gate array... or some sort of ROM?

Mr.What
Administrator
Posts: 154
Permalink
Post moving to grey code output
on: August 20, 2012, 15:52
Quote

Moving to a grey code output for commutation step, which is then
decoded into the 6 transistor enable switches.

Things got tricky for breadboard, so I started moving more mature parts of the circuit to perfboard.

Shown here, I have the final AND gate on the perfboard, with the single PWM signal AND'd to the high-side transistor enable signals.

http://www.youtube.com/embed/Yr7v2TazmPY

The grey code decode logic is still on the two chips on the extra breadboard. I started on the main board, but had bugs... by the time I found them, I had moved most of the circuit to the extra breadboard. The large breadboard is doing little more than holding the Arduino nano at this time.

I switched to a simple const-acceleration startup sequence, and it is working better. For some reason, things just seem to run smoother from grey code. I don't know if this is a real effect of grey code, or smoother PWM from 1 pin instead of on and off from 3.

The main reason to switch to a single PWM enable pin was to save an AVR timer. We can use the fancy 16-bit timer to send enable pulses, instead of splitting the work between two different pieces of timer hardware. This should make the timed-pulse mode easier to manage in the future. I am also concerned that if I go to phase and frequency correct PWM, with programmable period/width I am best off using the PWM register for pin 9 to control the timer. This may kill PWM capability for pin 9. It appears that I will be able to set up interrupts for various phases of the timing cycle by taking over a timer to control all PWM. A better way to go in the long run, but it diverges from the arduino analogWrite() functionality, and I have to program the timers myself.

Mr.What
Administrator
Posts: 154
Permalink
Post 3-Phase control on perfboard
on: August 22, 2012, 12:00
Quote

Switched control logic to grey code.
Have decoders on perfboard:
http://www.youtube.com/watch?feature=player_embedded&v=hlBAAj8dntY

I don't know that this was the best decision of how to divide up circuit boards. For the production version, perhaps I should just have 11 wires to the motor unit. 6 transistor enables, 3 sensors, +5vDC, GND.

Digital (TTL) logic signals and power for the 6 transistor enables. Leave the driver transistors for the high side P-channels on the motor control board so that only TTL (and analog sensor measurement) signals go on and off the power board.

It may be of interest to Arduino people to do a shield similar to this perfboard, where everything can be placed on an Arduino Uno.
For many applications, it may be desirable to get the high-power parts of the circuit away from the low power control logic.

Mr.What
Administrator
Posts: 154
Permalink
Post Letting the smoke out
on: September 12, 2012, 07:53
Quote

fried my driver hardware. Plugged in motor power before arduino. I thought that since I was driving the transistors from 74xx logic, where no INPUT combination could cause a short I was safe. That was incorrect. Somehow, during boot-up both sides of a half-bridge got enabled... and SMOKE!

Need to look into safer ways to enable exactly 1 leg of an h-bridge at a time. I'm open to suggestions for half-bridge driver IC's, or circuit suggestions which guarantee only one transistor of a half-bridge can be enabled at any one time.

I have seen some examples using opto-couplers. These seem promising. I'm thinking of enabling the optocoupler from TTL logic output. This way, both the logic hi and logic low need to be powered to get the LED to light up. I can put both sides of a half-bridge on the same hi/lo logic lines (in reverse) so only one can enable at a time.

Is this a good idea? Are there other tried-and-true ways to make sure both sides of a half-bridge cannot be enabled at once? (double-throw relays are not an option for the switching speeds in BLDC)

Here's some circuits I like:

This one uses opto-isolators. Enable LED's need separate FWD/REV lines to both be powered and NEQ for the high-side LED to enable.
http://www.mcmanis.com/chuck/robotics/tutorial/h-bridge/bjt-circuit.html

This one is very simple. Pull-up for high-side also enables ground.
http://www.bristolwatch.com/ele/h_bridge.htm
I worry that if I PWM the enable switch, grounding both sides would brake the motor, collapsing the e-field when PWM is off.

Having trouble understanding half bridge driver chips. Some only seem to provide tri-state buffers which shift from logic level to motor voltages. I'd want one with outputs tied together such that when one is enabled, the other is disables/high-impedence

Pages: [1]
Mingle Forum by cartpauj
Version: 1.0.34 ; Page loaded in: 0.031 seconds.

 

Comments are closed.