H-Bridge control and shoot through protection

jpearman · August 25, 2013, 6:10pm

I wanted to explain in a little more detail why I was concerned about motor control using the initial release of the PROS firmware and the possible remedies. First lets quickly recap how an H-Bridge works.

[ATTACH]7592[/ATTACH]

The H-Bridge consists of four switches, they are shown above in pictorial form. The implementation in the cortex uses MOSFETs, two P channel on the high side (shown as A and C here) and two N channel on the low side ( B and D ).

[ATTACH]7593[/ATTACH]

To turn the motor forwards (which way is forwards is subjective and not important here), switches B and C are closed. This creates an electrical circuit through the motor as shown on the diagram above.

To turn the motor backwards, switches A and D are closed. This creates an electrical circuit where the polarity across the motor is now reversed.

Closing either switches A and B or C and D at the same time will connect positive voltage source to ground as shown in the third diagram above. This is something you do not want to do, it has the potential to seriously damage the H-Bridge components.

[ATTACH]7594[/ATTACH]

This shows in more details how the H-Bridge in the cortex is connected. Switches A and C are connected to two control lines I’m calling enables. These will either be on or off depending on the required motor direction. To allow variable speed control of the motor, the other two MOSFETs are connected to control signals that can be pulse width modulated, that is, toggled very fast between on and off. The speed that the pwm signals are toggled is determined by the cortex firmware but is typically about 1000Hz to 1200Hz.

[ATTACH]7595[/ATTACH]

(This explanation is for illustrative purposes and not quite how things work, it’s close enough however).

This is an incredibly over simplified (and not entirely accurate) diagram showing how the pwm pulses are generated. A counter is counting from a pre-determined value down to zero, when it reaches zero the initial values is loaded again from the auto reload register. Another register called the compare register contains a second value that is constantly compared to the counter, if that value is less than the counter value the output digital value is high, if the value is greater than the counter then the output value is low. Lets say the auto reload register has the value 128 and the compare register has the value 64, the pwm output will be high for half the count time and low for the rest.

When a new compare value is needed, the user firmware must load a new value into a holding register called the compare preload register. This new value is only transferred to the compare register when the counter reaches zero. What this means is that when the user firmware wants to change the pwm duration it may not happen for some time as the current pwm cycle has to finish first.

The timer channels in the cortex each have four compare registers, their outputs are connected to separate pins on the cortex. A different compare register is used for the forward motor pwm signal to the backward motor pwm signal.

In the next post I will show what is currently happening with the PROS firmware and a better way of control.

jpearman · August 25, 2013, 6:32pm

So first lets look at the control signals that PROS is currently generating for the H-Bridge. I know they are currently working on improving this but I wanted to show the details and make an argument that I’m not actually paranoid.

[ATTACH]7596[/ATTACH]

This is a rather complex composite scope capture showing the four control signals going to an H-Bridge when changing direction from backwards to forwards.

The Pink trace was generated by a digital output when the software asked for the new motor value. The yellow trace labeled A shows the enable signal for backward is turned off (reverse logic, high is off here). 350uS later the blue trace labeled as C turns on the enable for the forwards motion, however, the pwm control line for backwards D is still turned on as the timer controlling pwm is running asynchronously to the software. This causes the undesired shoot through situation where the battery is shorted to ground. Traces A and B both take some time to recover due to the power supply used for this experiment being in current limit mode to save my cortex from making magic smoke. As the PWM frequency here is about 1KHz, the maximum time that shoot through could occur for is 650uS if motor values of +/- 127 were being used.

[ATTACH]7597[/ATTACH]

Here are the control signals coming from firmware with a different method of control (yes ConVEX). In this software the enable signals are made synchronous with the pwm signals. This is achieved by using an interrupt generated from the pwm timer to run the software controlling the motors. A change of direction first causes MOSFET A to be turned off for one entire pwm cycle before MOSFET C is turned on. In addition to this pwm values are commanded to be zero for one pwm cycle. Due to the nature of the compare preload register’s operation, a one cycle delay occurs before both pwm signals are essentially disabled. Motor power is restored after one more cycle. What this means is that when the motor changes direction it is disabled for two pwm cycles before resuming operation. The pwm in this example runs at 1200Hz so the delay is negligible in normal operation and only occurs when changing motor direction.

Anyway, this is my suggested way of H-Bridge control that avoids any possible chance of shoot through. A simpler, but in my opinion less effective means, is to increase the delay between disabling and re-enable the enable control lines to more than one pwm cycle. In the case of PROS this would mean increasing the delay from 350uS to perhaps 1.1mS.

jpk_7682 · August 26, 2013, 4:29am

Nice explanation and most definitely a serious problem which you mention they’re working on. Here’s some info about the real world of motor control for VEX students to mull over.

Some years back I worked on variable speed AC motor drives up to 100’s of kW output. This kind of issue would result in immediate destruction of the output stage which in larger drives consisted of 6x 300A 1200V IGBT’s in parallel per switch and 6 of these for the 3 phase H bridge (total 36x 300A devices costing $100’s each). Add to that around 100,000uF of capacitors at 600Vdc and very little inductance between them and the switches there was just no way shoot through was permissible.

So in power electronics gate drive circuitry has what’s call de-saturation detection. When you turn the switch on the voltage across it is monitored and if it’s not below a certain threshold within a short period of time (microseconds) the gate is switched off and a fault condition fed to the controller. Loads of fun testing this stuff, short circuit the output and then start the drive running (wearing safety glasses and ear protectors). In tests it was possible to generate around 18kA through the switches before de-sat protection hopefully kicked in. Want to volunteer your oscilloscope to measure 18kA @ nearly 1kV?

Eric_J · August 26, 2013, 4:54am

If there is the chance of a shoot through why did Vex include them in the Cortex? They could have had a regular PWM port, or an internal PWW converter to 2 wire insted of an H-Bridge.

jpk_7682 · August 26, 2013, 5:08am

This level of motor controller is often limited by cost. Ideally an external circuit would prevent this from happening regardless of drive signals however 1 more chip on the board probably wasn’t desirable in a cost constrained product. Design choices, just like building your VEX robot.

jpearman · August 29, 2013, 9:36pm

I wanted to conclude this thread by showing the improvement the PROS team has made with the firmware released on Aug 26 (2b04). Here is another capture under the same conditions as post #1.

[ATTACH]7608[/ATTACH]

Their approach was to disable all four control signals to the H-Bridge when motor direction changes and also disable the pwm until the beginning of the next pwm cycle.

All H-Bridge shoot through is now eliminated