Construyendo un conmutador de voltaje para un puente H usando transistores bipolares

Estoy tratando de construir un puente H con transistores bipolares y me está costando mucho descubrir cómo armar la lógica de entrada. Estoy usando un Intel Galileo para manejar el control de pwm. El circuito funciona con entradas fijas, pero el verdadero problema aquí es cambiar entre dos voltajes (27 V y 0 V) ​​según la salida digital del galileo (5 V/0 V). Aquí está el boceto: bosquejoel lado derecho del puente está fijo en 27 V y estoy tratando de establecer 0 V como voltaje en el otro lado con ese transistor. He intentado muchas formas diferentes de cablear esto y hasta ahora no he tenido suerte.

Utilizo cuatro pines de controlador para impulsar un puente, controlando los cuatro cuadrantes de forma independiente.

Respuestas (1)

Tienes múltiples problemas.

Q21 es al revés para controlar Q1, suponiendo que el control de 5v del Gallileo
Q21 no debería controlar Q2, necesita otro transistor o
Q21/R34 es la configuración incorrecta para apagar Q2, R34 será 'superado' por R28.

Lo que está tratando de hacer es más difícil de lo que parece, razón por la cual existen tantas soluciones de puente H preempaquetadas.

¿Está...
a) tratando de aprender a construir puentes H o
b) tratando de hacer que algo funcione para impulsar una carga de su Gallileo

Si (b), entonces le recomiendo encarecidamente que compre un controlador de puente H o un par de controladores de medio puente. Su intento hasta ahora muestra un profundo malentendido de lo que se requiere.

Si (a), entonces hay varias formas de hacerlo.

Puede usar BJT, pero los FET son algo más fáciles de manejar.

Considere lo siguiente para el lado izquierdo de su circuito. Tenga en cuenta que este es un boceto para el que al menos la lógica funciona y los niveles son plausibles. Los valores de resistencia podrían necesitar algún ajuste, especialmente una vez que se han definido la carga y los tipos de transistores. Sería adecuado para el control estático de potencia bidireccional a una carga. No me he fijado en el tiempo, casi seguro que los disparos serán un problema.

Como tiene la intención de PWM, cualquier disparo excesivo causará grandes pérdidas y debe corregirse. Los transistores de conmutación principales funcionan en saturación y será necesario apagarlos para controlar la sincronización. Es posible que deba agregar condensadores y diodos de aceleración, así como ajustar los valores de resistencia para obtener un buen resultado. Si no sabe de lo que estoy hablando aquí, y/o no tiene un osciloscopio para ver qué sucede, entonces esto realmente significa que debe comprar en lugar de construir, al menos para algo tan complicado. Tal vez una mejor manera de controlar el disparo es duplicar Q21 como mencioné en 'lo que no funciona' y controlar cada dispositivo de salida de forma independiente. Luego, puede implementar la temporización en el nivel de la unidad lógica para superponer la conducción del dispositivo de potencia.

No olvide ningún diodo de captura de carga, si su carga es inductiva como un motor. Vienen gratis si usas FET por cierto.

esquemático

simular este circuito : esquema creado con CircuitLab

He usado los mismos designadores de referencia cuando corresponde, y los he escrito como 1xx donde están relacionados con xx.

Las resistencias R128 y R129 ahora reducen el impulso base a los transistores de salida, lo que significa que pueden apagarse por completo.

Q121 refuerza la salida de corriente +ve de R34, lo que significa que puede apagar Q2 por completo, incluso cuando está cargado por R28. D1 es necesario para permitir que R34 encienda Q121. Esta es una disposición bastante estándar para obtener una unidad de baja impedancia en ambas direcciones.

Usted preguntó: "¿Si tiene la intención de PWM?" Y el OP definitivamente planea hacer eso. Escribió: "Estoy usando un Intel Galileo para manejar el control de pwm".
@jonk bien visto, arreglado.
Un detalle más que puede resultar interesante. ¡Los pines de E/S de Intel Galileo son MUY LENTOS! Ver: drdobbs.com/embedded-systems/… donde habla de un procesador de 400 MHz que solo administra tasas de E/S de 250 Hz sin hacer nada más que alternar pines. Dado eso, es posible que no tengas que preocuparte tanto por las aceleraciones. ;)
@jonk Apuesto a que sus pines son rápidos, si los programa en el metal desnudo. Si empuja una emulación de Arduino a través de un sistema operativo que no es en tiempo real antes de que llegue a los pines, entonces no tendré problemas para creer en 250Hz en absoluto.
No. Olvidé la razón exacta, pero en realidad es una limitación de HARDWARE. Creo que usaron una ruta de datos en serie que funcionaba lentamente entre el procesador de 400 MHz y los pines IO. Algo así, según recuerdo. Recuerdo que no se podía hacer nada al respecto. No son cosas del sistema operativo, según recuerdo el problema. Una cosa realmente estúpida de hacer.
Lo encontré. "Los GPIO en Galileo se enrutan a través del chip Cypress CY8C9540A, lo que ralentiza drásticamente el rendimiento de estos pines". Sin embargo, hay dos pines de E/S que escapan a esta limitación. La "gen 2" es mejor. Tal vez el OP esté usando eso.
Probablemente agregaría cuatro diodos a los rieles, a través del V C mi de cada BJT. El motor es un inductor. (Y me gustaría un control independiente de cada BJT. Pero esa es una historia diferente).
@jonk Una vez tuve una computadora TI99/4 por mis pecados. IIRC, todo era RAM de video y controlador de video de hardware, y el programa robó parte, a través de un enlace serial lento, por lo que los sprites se moverían en tiempo real, y se necesitaron 2 ms para agregar un par de números enteros. Extraño.
Creo que todavía puedo tener uno de esos en una caja aquí. Resulta que tengo dos de los sistemas Intel Galileo aquí, por lo que tuve una reacción. Estoy usando el Odroid, que es una placa de cuatro núcleos de 1,5 GHz, con gigabit Ethernet y 4k hdmi integrados por la mitad del precio de un nuevo Galileo gen 2. El primer Intel Galileo me ha dejado un mal sabor de boca.