Re:Placa de potencia adaptada a CNC, para maquinas de C.C. Optimum/Quantum‏‏‏‏

[Valen]

Estudio Detallado del "Data sheet" del chip ATMEGA328.
Ahora toca lo más trabajoso: Estudiarse a fondo la hoja de datos del microcontrolador ATMega 328 (más de 500 páginas...), para poder ajustar el programa. Hay que revisar todos los registros de cada uno de sus módulos (bus SPI, salida PWM, convertidor ADC, etc), las interrupciones disponibles, sus limitaciones de uso, etc.

También hay que verificar el modo de operación más indicado para generar la señal pwm (normal, fast pwm, pwm con corrección de fase, pwm con corrección de fase y de frecuencia). Ya hablaré más sobre este tema.

Además hay que dilucidar si hay algún sistema que pueda interferir con otros, ya que a veces se comparten entradas o salidas, para diferentes funcionalidades..

En imagen siguiente se ve el osciloscopio, que está presentando la tensión en la puerta del IGBT. La tensión en la carga tiene esa misma forma.
También se ven papeles impresos con varios capítulos de la hoja de datos del chip, y multitud de anotaciones relativas a este proyecto.


Tensión en el motor de fresado.
La tensión continua en el motor es el "valor medio" de los pulsos que se ven en el osciloscopio, en la siguiente imagen.
(En buena ley, la componente continua de la descomposición en series de Fourier de esa onda).





Corriente por el motor de fresado.
En la siguiente imagen se ve la corriente en el motor. Vemos que no es lineal, debido al efecto inductivo del motor. La forma de onda tiene mucho ruido, y por eso el trazo es tan grueso.

Si los pulsos son estrechos (manteniendo el periodo constante), la corriente sube rápidamente cuando se aplica el pulso (i=(U-E)/L *t)y cae más lentamente durante la descarga del motor a través del diodo de libre circulación (i=-E/L*t). O sea, primero más pendiente y luego menos.

A medida que crece la anchura de los pulsos respecto del periodo, se igualan las pendientes de subida y bajada de la corriente, pudiendo llegar a ser de menor pendiente la subida y de mayor la de bajada.
Eso sí, una vez que se supera el régimen discontinuo, la corriente aparece montada sobre una continua (el valor final de cada ciclo ya no es cero).
Y ojo, tiene que ocurrir que el valor instantáneo  de la corriente al principio y al final del ciclo sea el mismo, ya que representa la energía almacenada en la bobina (E=L.i^2), que en régimen permanente no cambia en un ciclo.

 

[Valen]

Programación de los microcontroladores: Compiladores.

Para programar los microcontroladores, hemos de valernos de un software específico para esta tarea, que se suele conocer como "Compilador".
En el caso que nos ocupa, un chip de Atmel, existen diferentes herramientas disponibles. Voy a nombrarlas y a dar una opinión muy personal de sus ventajas o inconvenientes.

Voy a referirme todo el tiempo a sus características de compatibilidad y uso con la placa Arduino Uno, ya que es la que empleo para cargar el software en el chip ATMega328P.

Compilador Ardiuno.
El proyecto de hardware libre denominado Arduino, pone a disposición de todos nosotros un compilador sencillo pero muy bien organizado y muy práctico. Además se ofrecen innumerables librerías de funciones hechas, así como una comunidad de usuarios con foros muy activos, en los que consultar las dudas, etc.



Esto hace que se programe en C, en una capa por encima del hardware, que facilita mucho el trabajo. Claro que si queremos cosas muy específicas, no habrá más remedio que bajar a la capa inferior, con los registros, interrupciones, etc. El compilador te permitirá hacerlo, aunque no ofrece herramientas específicas de depuración.
Otra ventaja es que puedes pinchar el chip de Atmel ATMega328P  en la placa Arduino Uno, y cargar los programas con facilidad, y todo ello sin necesidad de configurar nada manualmente.

Compilador AVR 4.
Es la opción más equilibrada para quienes quieran desarrollar código avanzado para estos chips. El compilador está basado en el software de Microsoft Visual C++, que es una herramienta magnífica. Este compilador AVR es también una herramienta muy estable y madura.




En la página 21 del documento indicado a continuación, se explica -en español- cómo adaptar AVR 4 a la programación del chip Atmel ATMega328P  aprovechando las librerías del entorno Arduino, y los que es más importante, pudiendo cargar directamente los programas en la placa Arduino Uno:

http://download.lpmagazine.org/es/2010/Linux_06_2010_ES.pdf
 

Compilador AVR 5.
Basado en el entorno Visual Studio 2010 de Microsoft, es una herramienta muy potente, y con un entorno visual claramente más avanzado que su versión anterior AVR 4.
Sin embargo, es bastante difícil de poner en marcha con el entorno Arduino y la placa Arduino Uno. A partir del artículo indicado en el apartado anterior, y de este otro:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=110776

es posible lograrlo, con un poco de tenacidad.....



En mi opinión, al compilador AVR 5 le faltan todavía algunos "service packs" para ser una versión realmente definitiva.


Integración de placa Arduino en compiladores AVR.
Esta imagen es para mostrar que con un poco de trabajo por nuestra parte, podemos llegar a crear un botón en el menú, con el que la carga del software en el chip de la placa Arduino, se haga de forma totalmente automatizada:





Compatibilidad entre progarmas desarrollados en los diferentes entornos.
En principio, todo aquello que esté desarrollado en lenguaje C habría de ser compilado en cualquiera de los tres compiladores, sin obtener diferencias. Sin embargo, no siempre es así, ya que, por ejemplo, el compilador de Arduino es mucho más tolerante ante pequeños incumplimientos de las reglas que impone el lenguje C, lo que provoca que un código fuente que compila perfectamente en el entorno Arduino, pueda generar un gran número de errores al compilarlo en un entorno AVR.

Por ej. en el entorno Arduino, una variable global, definida en un determinado fichero de C, puede ser empleada sin problemas en otro fichero de C, del mismo proyecto.
Sin embargo, esto provoca un error en un compilador AVR, ya que al ser más estrictos, se exige que esa variable sea declarada como "extern" en el otro fichero donde la queremos emplear.


Mis reflexiones sobre este tema.
A pesar de haber empleado ampliamente las herramientas Visual C++ y Visual Studio durante una fase ya pasada de mi vida profesional, el entorno AVR5 me ha resultado bastante complicado de poner en funcionamiento con mi placa Arduino Uno. Esto no ha ocurrido con el compilador AVR4, que está mucho más maduro.

Quiero resaltar aquí que las capacidades de depuración que ofrecen los entornos AVR se vuelven prácticamente inútiles cuando tenemos que depurar un software que interactúa con una placa como la nuestra, que es la que le va dando los valores de entrada, etc.

Por ello, la característica que más valoro de los entornos AVR es su editor de código, que te ayuda a cosas como buscar dónde aparece una determinada variable, o a ver dónde está definida, etc. también lo bien que identifica con colores cada tipo de dato, etc.

El compilador Arduino me parece incomparablemente brillante en su sencillez. Ya hemos comentado algunas de sus limitaciones, pero si no vamos a hacer cosas muy complicadas, es una opción muy buena.

En este momento, el código fuente de un chip lo tengo compilado en entorno Arduino, y el del otro chip, en los entornos AVR.

[Valen]

Velocidades muy bajas, con la fuente conmutada.

Este vídeo es simplemente para mostrar el grado de regulación que se logra con la fuente conmutada, que genera una tensión de alimentación PWM a 8KHz:

VelocidadesMuybajas.wmv

[iguana600]

Viendo esto me enfadare mucho cuando alguien "diga esto es España", este hombre como muchos otros saben lo que se traen entre manos y viene a confirmar que en esta España lo difícil es promocionarse, enhorabuena por tus estudios y por compartirlos, saludos.

[Valen]

Generación de tensión PWM para el motor y medición de corriente.

Después de estudiar a fondo los capítulos de la hoja de datos que afectan a este proyecto, ya he definido la forma definitiva de generar la señal PWM y de emplear el ADC para tomar muestras de corriente.

El fabricante define varias formas de generar la señal PWM valiéndose del hardware específico incluido en el chip: Normal, fast PWM, PWM con correción de fase, PWM con correción de fase y de frecuencia.
Los dos primeros son más indicados para otros usos que requieren frecuencias muy elevadas. Los dos últimos están especialmente indicados para el control de motores, al generar una señal PWM de periodo constante.


Generar la tensión de alimentación para el motor de fresado.
He optado por el modelo más completo, es decir, el "PWM con correción de fase y de frecuencia".
En la gráfica que se incluye a continuación se indica cómo se genera. La gráfica superior nos indica cómo el hardware y el software que he programado en el chip, nos genera una salida PWM.

Configurando los registros internos, he seleccionado que se genere una señal PWM invertida (en vez de normal), ya que antes de llegar a la puerta del IGBT pasa por el optoacoplador, que la invierte, dejándola "normal".

En las dos gráficas inferiores vemos cómo es la tensión en el motor de fresado, y la corriente eléctrica que circula por él.


Lanzar el ADC.
También se indica el momento en el que el conversor analógico digital ADC toma la muestra de la corriente. Esta toma de muestra se realiza de forma automática:

El hardware ha sido configurado mediante los correspondientes registros para que cuando la onda triangular llegue a cero (es un contador interno), se lance una interrupción que dispara el funcionamiento del ADC. Éste toma una muestra de la corriente e inicia su conversión a valor numérico. El proceso dura 125 micro segundos. También vemos que en ese momento la tensión lleva tiempo siendo aplicada al motor, y por ello la medida que obtenemos de la intensidad es bastante limpia.

También quiero resaltar que el regulador PI, al ser un sistema de regulación de primer orden, actúa como filtro, en el sentido de que no atiende a las altas frecuencias, es decir, a la pequeña variabilidad que de manera constante se produce en las medidas de corriente que toma el sensor hall.


Siguiente paso: Regulación PI.
Al terminar, el propio ADC lanza una interrupción que carga el resultado en la variable con la que realizaremos los cálculos que necesitemos.
Entre esos cálculos está el regulador PI, que es bastante lento. Si además incluimos dos PI (uno para la velocidad y otro para el par), entonces queda claro que la interrupción tardará bastante tiempo en ejecutarse. Esto ha de tenerse en cuenta, para decidir cuando vas a poder muestrear otra vez la corriente, de forma que el ADC esté ya libre.

Podría pensarse que es claramente mejor incluir el código de los PI en el bucle principal del programa, y descargar así a la interrupción de atención a la finalización de la conversión del ADC. Sin embargo, esto no tiene por qué ser así: Al ser un sistema monotarea, el procesador solo ejecuta una cosa en cada momento, así que, o está ejecutando la interrupción, o está ejecutando el bucle principal de programa. Y al final se consume el mismo tiempo. En fin, todo tiene sus pros y sus contras, y es un punto a decidir, en función de lo se vaya viendo durante las pruebas.




En la imagen el ADC tarda poco tiempo en ejecutarse, pero en nuestro caso se necesita bastante más tiempo.

[Valen]

Reguladores PI de par motor y velocidad.

Ya he terminado la implementación de los dos bucles de regulación PI que hacen que nuestra fuente conmutada sea más inteligente:

El bucle más externo determina el par motor que necesita en cada momento el motor, para seguir girando con la misma velocidad (cuando por ej. el torno se pone a cortar metal, y sube el par resistente) o para ajustarse a la nueva velocidad que le marquemos al actuar sobre el potenciómetro.
El bucle más interno recibe esta información y regula el par en el motor de fresado.  Para ello controla la corriente por la máquina, ya que son variables dependientes.

Como existe una relación directa entre la variación de la velocidad de la máquina y el par motor, el doble bucle PI te garantiza un control total sobre la velocidad y la forma en la que ésta se alcanza.

Ajuste automático del par, en el motor de fresado.
Como vemos en el vídeo a continuación, cuando el eje del motor se traba, o cuando sube el par resistente (por ejemplo, cuando la máquina herramienta pasa de girar en vacío a mecanizar el metal), el sistema detecta la nueva situación y regula la tensión de alimentación para que la máquina recupere la velocidad de giro.
Todo esto se hace de forma automática, de la manera más eficiente posible.


RegulacionPar_0001.wmv

[Valen]

Estimación de la velocidad.
Nuestra fuente conmutada cada día es más lista: Ya es capaz de inferir la velocidad de nuestro motor de fresado, sin usar ningún tacómetro. El procedimiento seguido se basa en la medida de corriente que la fuente envía al motor, y de la modelización matemática de éste.

Efectivamente, sabemos que la velocidad de la máquina es proporcional a su fuerza electromotriz. Y esta a su vez se puede calcular como la tensión de alimentación al motor, menos la tensión que cae en el devanado, debido a su resistencia óhmica y menos la caída de tensión en las delgas-colector, que es constante y entorno a 1v:

Velocidad = K * (U – R*I - 1)

Y a partir de esto, podemos conocer la velocidad del motor en cada momento, con bastante precisión.

Veamos cómo se utiliza esto:

En el vídeo propuesto a continuación, se presentan en pantalla dos velocidades:

Velocidad Mando: Es la que marca el potenciómetro. Es por tanto, la velocidad que queremos conseguir. (Técnicamente se la llama "velocidad de consigna").
Velocidad estimada: Es la velocidad a la que en realidad está girando la máquina, calculada por el micro-controlador a partir de la corriente consumida, la resistencia del devanado del motor, etc.
En condiciones estables, ambas coinciden, como es lógico.

Cuando hacemos girar el potenciómetro, para que el motor suba de velocidad, esta se refleja inmediatamente en pantalla, en la velocidad de mando. Al fin y al cabo, no es más que la velocidad a la que queremos llegar, y ya veremos si se llega, jajaja.

Debajo de ella vemos como la velocidad estimada sube más lentamente. Lo que está ocurriendo es que el sistema de control de la fuente conmutada ha detectado que la velocidad deseada es mayor que la estimada, y empieza a ejecutar el control PI para aumentar la velocidad de la máquina, hasta lograr que otra vez ambas velocidades coincidan.

En resumen, la velocidad estimada siempre sigue a la velocidad de mando, y este seguimiento lo realiza gracias a los dos bucles PI incorporados al sistema de control de nuestra fuente conmutada.

(la semana del 26-9 estaré fuera, y por tanto no habrá avances.....)

Pantalla_PI_01.wmv

[Valen]

Consecuencias Prácticas de la regulación PI.

A veces, con tanta teoría, se pierde de vista cuál es el objetivo práctico -para el funcionamiento en el día a día- de todo lo que se está tratando de explicar. En este post intentaremos visualizar para qué sirve todo esto de los reguladores PI. Es decir, cuál es su utilidad práctica.

Comparemos las dos situaciones posibles:
Motor sin regulación PI: A velocidades muy bajas, la tensión es muy baja y constante. El par es muy bajo porque la corriente también lo es. Así, es muy fácil parar el eje, aplicando un pequeño par resistente. El motor no es útil en estas condiciones.
Motor con regulación PI de doble lazo: A cualquier velocidad, la velocidad y el el par del motor son constantemente supervisados por el regulador PI. El par se reajusta en tiempo real, de forma que la velocidad se mantenga lo más constante posible, y siempre vigilando el par, que es la variable más importante.


En el vídeo que mostramos a continuación, se ve cómo la fuente conmutada, gracias a la doble regulación PI, es capaz de ajustar el par en el motor de fresado, incluso en condiciones extremas, cuando el motor está girando a velocidades muy bajas.

Demostración en vídeo:
Vemos como al intentar parar el eje, la fuente reacciona incrementando la corriente por el motor (aumentando la tensión de alimentación), de manera que se venza la resistencia que estamos ejerciendo para impedir que siga girando.
Cuando liberamos de golpe el eje, todo ese par que se estaba ejerciendo, queda disponible para acelerar la máquina y se produce una aceleración, la cual es detectada por el sistema de regulación, que actúa para llevar de nuevo la velocidad a su valor inicial.

(El software que estamos empleando en estas demostraciones está configurado para que actúe más lento de lo que lo haría en condiciones normales, para que así podamos apreciar los cambios).

Compensacion_Par_Veloc_Bajas.wmv

[AndresAlgeciras]

La mejora que comentas supone un avance sustancial en el rendimiento del controlador que montan de origen nuestros tornos. Una situación muy frecuente con la que me encuentro, es la de tronzar una pieza en el torno. Siempre lo hago a velocidades muy bajas, pero en cuanto aproximo la cuchilla tronzadora, el torno aumenta su velocidad y en ella se mantiene sin recuperar el regimen inicial que yo había ajustado.
Sigo con mucho interés tus mensajes. Gracias.

Andrés

[Valen]

Sí Andrés, a la hora de tronzar, la mejora es muy significativa.
De todas formas, tengo que terminar de regular el PI, para corregir esa aceleración que se produce cuando suelto el eje, en el vídeo. También ver la posibilidad de incluir una Resistencia en serie con el diodo de libre circulación, para reducir el tiempo de descarga del bobinado del motor, que al ser L/R se puede reducir así, y mejorar ese comportamiento. ya veremos....

Pero en fin, que si no faltasen estos detalles, el proyecto estaría acabado, claro, jajaja Pero no, no lo está, aunque falta poco de lo que es complicado de programar. El resto (interfaz gráfica, limpiar el código, control de errores, etc.) es más sencillo.

[Valen]

Ajuste de los reguladores PI. (Comportamiento a velocidades muy bajas)

He trabajado en ajustar las constantes que definen el comportamiento de los reguladores PI, principalmente para ajustar el arranque, aceleración y el comportamiento a velocidades muy bajas.
Se trata de eliminar el efecto de aceleración que se produce, cuando trabamos el eje, y a continuación lo destrabamos: el motor se acelera debido al exceso de par.
Para corregirlo, en los casos extremos, el IGBT ha de pasar completamente al corte. En casos normales, es suficiente con ajustar el comportamiento del integrador, para que el ajuste sea más rápido.

AjusteDobleLazoPI_0001.wmv


IGBT seleccionados.
Esta foto muestra los dos posibles IGBT que finalmente he seleccionado para esta placa.




Esta es el funcionamiento sobre la gráfica SOA, para uno de los IGBT, y ambos motores: El de Proxxon y el de Optimum/Quantum.
Hemos representado el punto de trabajo más desfavorable: Tensión y corriente máxima en la máquina.

Vemos que el de Proxxon (gráfica verde) podría estar funcionando en régimen permanente, a corriente máxima, durante años, jajaja sin que pasase nada.

La línea inclinada es el limite para un pulso de esa duración (1mSg, 100USg, etc). Por eso es posible mayores valores de corriente y tensión, a medida que el periodo del pulso disminuye.  Y todo esto, sin tener en cuenta que con el disipador, el margen de maniobra será mayor....

[varoniberico]

La verdad es que es un trabajo estupendo el que estas realizando, despues de leerme las 6 paginas de un tirón estoy empezando a contemplar las posibilidades que tiene este trabajo , especialmente sobre la posibilidad de utilizarlo como control de los ejes x,y,z adaptandolo como driver de servomotor, estoy aburrido de buscar por Internet y no encuentro lo que busco. No se si has publicado el esquema de control... No lo he visto pero me gustaría poder verlo para evaluar posibilidades.
enhorabuena por el estudio.

[Valen]

Hola, me alegro que te haya gustado. 

De momento al menos, no tengo previsto publicar el detalle del esquema eléctrico, más allá de las imágenes adjuntas. Pero en cualquier caso, no serviría de gran cosa, porque lo realmente importante son los cientos (quizás miles) de líneas de código fuente, programado en C, que se cargan en los dos micro-controladores, y que son el alma del sistema de control...


Esquemas del Circuito.
Estas imágenes nos muestran el estado actual del prototipo, que ya se aproxima mucho a lo que será la versión definitiva.

[juanpefrutos]

Valen, en primer lugar quiero expresar mi admiración por el magnifico trabajo que estas haciendo, que está al alcance de muy pocos, y sobretodo por compartirlo con nosotros. Queria preguntarte si todo el programa lo estas haciendo con el software de Arduino o solo se puede hacer con AVR 4??. Mi segunda pregunta es , dado que ya has desarrolado el prgrama para el tacometro ¿no te has planteado el añadir una entrada para el captador de revoluciones aunque sea como opción?

Saludos y seguiré tus progresos.

[Valen]

Gracias...
La entrada del tacómetro está incluida (y ya funciona). Es la que está en la esquina inferior izquierda de la placa, con el texto "Tacom". Quizás al estar en vertical, no se aprecia bien.

Efectivamente, es opcional, y su uso "si/no"  se configura en uno de los tres micro-switchs que se ven en el lado derecho de la placa.


Todo el software lo puedes desarrollar indistintamente en cualquiera de los entornos que propuse en un post anterior. Yo, a veces empleo el entono de desarrollo Arduino porque me encanta su sencillez, aunque otras veces empleo el que proporciona el fabricante del chip, Atmel, con el software AVR porque hay que reconocer que tiene de todo.

En el fondo, el "lenguaje de programación" Arduino no es más que lenguaje C al que le han añadido una serie de comandos implementados por el grupo que desarrolla Arduino, y una colección de librerías que te facilitan la vida. Pero al final, todo es lenguaje C.
Por eso puedes programar una placa Arduino con AVR. Solo hay que incluirle las cosas antes comentadas, que proporciona ese entorno.

Proceso de desarrollo del código, en estos momentos.
El desarrollo del software de control de un proyecto como este, tiene muchas partes, muchos componentes, así que durante un tiempo estuve muy centrado en las partes más críticas:

1- Los reguladores PI y su encaje en la arquitectura hardware que he definido. Por eso todo lo que he publicado últimamente se refiere a este tema.
2- PWM y bus SPI, sin interferencias mutuas (provocadas por la atención a sus respectivas interrupciones, tiempos críticos, etc.)


Pero en realidad el tema de dibujar pantallas de datos es otro quebradero de cabeza, al ser ésta un dispositivo muy lento, que puede llegar a afectar al funcionamiento de sistemas que necesitan mucha mayor rapidez de ejecución, como son el bus de datos, el tacómetro, la atención a interrupciones, etc.

A estos otros módulos también les he ido dedicando tiempo, pero en menor medida. Por eso sus avances todavía no han visto la luz...