Evolución del software de programación para Motion Control

Fecha de publicación
Cateogría del artículo Motion Control
Visualizaciones del artículo Leído  2964  veces

En este artículo, Pere Garriga pretende dar una visión general de la evolución de los sistemas de programación para Motion Control (en adelante MC), desde los de hace tres décadas, hasta la actualidad

Evolución del software de programación para Motion Control

EL artículo también se pretende aclarar que un entorno de programación estándar no significa que se pueda hacer lo mismo y de la misma forma con cualquier PAC (Programmable Automation Controller) que lo incorpore.

Nota: El orden cronológico puede que no sea del todo exacto

Los primeros lenguajes de programación para MC.

Eran sistemas de programación mediante comandos mnemónicos, tipo MOVD (mover a una distancia), con estructuras de control tipo IF THEN, DO WHILE, llamadas a subrutinas y en general las funciones necesarias para estructurar el programa.
El más antiguo que recuerdo es el de un posicionador del fabricante ELAU (ahora Schneider Electric), que se programaba desde su propio terminal, no existian los PC portátiles en aquellos tiempos.

En el programa que muestra la imagen, se asigna el valor de 134.8 a la variable V1 y se realiza un posicionado absoluto a su valor, si al terminar el posicionado la entrada 1 está desactivada se ejecuta las subrrutina U12, de lo contrario el programa continua en la linea 40, donde se fija la velocidad al 80% de su valor máximo.

En este caso se trataba de equipos de un eje, por lo que solo se podían realizar los movimientos más básicos. Si avanzamos unos años, cuando poder disponer de un PC portátil ya era una realidad, ya empezaron a aparecer softwares de programación más “capaces”. Aunque todavía no disponen de programación simbólica. La cantidad de variables y tipos de datos está en función del mapeado del equipo de control. P.ej.: De V1 a V64 son variables enteras de 16 bits no retentivas, de la G1 a la G64 son retentivas y a nivel booleano, de B1 a B64 como no retentivas y de F1 a F64 retentivas. Según el nivel del equipo se disponía de más o menos variables y más o menos tipos de datos.

El programa de ejemplo de la imagen corresponde a un equipo de ElectroCraft (firma adquirida por Allen Bradley), denominado IQ, que para su época no estaba nada mal y que seguro que todavía encontraríamos máquinas en los que están funcionando.

La velocidad de ejecución no era muy elevada por el hecho de que son lenguajes interpretados, la CPU va cargando comando a comando del programa, lo interpreta y lo ejecuta. Además, se trataba de CPUs de máximo 16 bits. Con un valor típico de dos milisegundos por instrucción.
También podíamos encontrar algún simple posicionador programable en códigos G, cosa que resultaba muy sencilla para usuarios con unos conocimientos muy básicos, pero claro, el control también estaba muy limitado en prestaciones.

El gráfico muestra un sencillo programa, a modo de ejemplo, en el que los comentarios hablan por sí mismos.

Lenguajes de programación gráficos para MC.

Los fabricantes investigaban la forma de acercar la tecnología de control de movimiento de propósito general, o GMC (General Motion Control) a los usuarios, se buscaba la forma de programación más amigable posible. Y en lo referente a “User Friendly” Allen Bradley siempre suele ir unos pasos por delante

Creó un sistema de programación gráfico, denominado GML (Graphical Motion Language) donde los comandos están representados por iconos y en los que solo hay que introducir unos valores, como la aceleración, velocidad, posición, etc. E ir uniéndolos para establecer su secuencia de ejecución. Hay que decir que ya en aquellas épocas GML permitía programar interpolaciones y movimientos sincronizados de hasta cuatro ejes.

Estos sistemas gráficos resultan algo engañosos porque pueden confundir al usuario, que puede pensar que como esto es tan fácil, ya domina la tecnología de MC. Por otra parte, pueden resultar ideales cuando se trata de aplicaciones muy, muy sencillas que deban realizar técnicos con pocos conocimientos de esta tecnología, pero cuando se trata de aplicaciones de una cierta relevancia, hay que realizar partes del programa en script; cosa que por suerte el sistema ya prevé.

Estos lenguajes de programación gráficos han ido quedando en desuso dado que no encajan con las necesidades actuales de las máquinas 4.0

Otro ejemplo similar, aunque en este caso va más allá, es el Visual Motion de Bosch Rexroth, en el sentido de que está más ligado a la aplicación, podríamos decir que los iconos son de más alto nivel.

P.ej.: Para el control de un Desbobinador ya existe un icono que incluye todo lo necesario para controlar el servomotor, basta con configurarlo, indicando si hay medidor de diámetro, si es control por par, por bailarín, etc...

Y a finales del milenio llegaron los PAC.

Con este tipo de controladores se da un gran paso hacia adelante, en primer lugar, a nivel de arquitectura. Por tratarse de un control multidisciplinar ya no se necesita un PLC más un GMC, sino que el propio PAC ya tiene la capacidad de MC y por tanto todo se unifica en un mismo programa.

En segundo lugar, a nivel de programa, ya se dispone de programación simbólica con todos los tipos de datos posibles de 32 bits, los límites son la cantidad de memoria disponible. Pero lo más importante es el hecho de tenerlo todo integrado en un mismo control.

Para verlo mejor, la siguiente figura muestra un ejemplo de cómo sería realizar un movimiento con un PLC y un GMC externo.

Básicamente, puesto que el PLC no tiene capacidad de mover un eje, lo que hace es activar una salida que indica al GMC que movimiento realizar y una vez el eje alcanza su posición, el GMC activa una salida indicativa de ello al PLC. En el ejemplo el PLC activa la salida PLC_GMC_GoPlace, que va a la I2 del GMC y el GMC activa la salida O2 que va a la entrada GMC_PLC_InPlace. Este handshake y el tener que realizar dos programas resultaba engorroso.

En el PAC, gracias a la integración de la disciplina de PLC con la de GMC, la aplicación se simplifica considerablemente, el programa quedaría como el que se muestra en la imagen.

El ejemplo muestra el programa en ladder, pero los PAC cumplen con el estándar de programación IEC-61131-3, por lo que se dispone de todos los lenguajes de programación, a gusto del usuario.

Lenguajes de programación Estándar en los PAC

Dentro de las plataformas basadas en el estándar de Codesys y en todas las que cumplan con el estándar IEC-61131-3, el lenguaje de programación puede ser ST (Structured Text), FB (Function Block), SFC (GRAFCET), CFC (Continuous Function Chart), IL (Instruction List) y como no el LD (Ladder Logic).

Lo interesante de disponer de todos estos lenguajes, es el combinarlos según la funcionalidad de cada parte del programa, si se trata de un cálculo -más o menos complejo - probablemente el ST será el más adecuado, para el “director de orquesta” o secuencia principal, quizás lo mejor sea el SFC, también dependerá de los gustos de cada programador.
Lo cierto es que las máquinas cada vez son más complejas y ello hace que la programación cada vez requiera de técnicas más próximas al mundo IT, ya es habitual que se realicen muchos programas en OOP (Object Oriented Programing) y de aquí a no muchos años será impensable encontrar partes del programa realizadas en Ladder.

Diversidad de opciones

Hay fabricantes que han optado por construir su entorno de programación sobre un sistema estándar, mayoritariamente, Codesys y otros han desarrollado su propio ámbito de programación para sus plataformas.

Los principales son: Studio 5000, TwinCAT, Sysmac Studio, Automation Studio, EcoStruxure Machine Expert, PLC Designer y TIA Portal. En algunos casos el hardware trabaja con sistemas operativos estándar, como VxWorks o Windows y en otros con sistemas propietarios. La mayoría están basados en Codesys y lo que se descarga en el PAC es un código compilado. Lo que implica que sin el programa fuente no se puede hacer nada, aunque siempre existe la opción de descargar también el código fuente en la memoria del PAC, es la única forma de recuperar el programa desde el controlador. En estos casos hay que tener un buen control del programa fuente y sus versiones en un servidor y realizando copias de seguridad.

En el caso del Studio 5000 o del TIA Portal, se envía un código, muy optimizado, para que el PAC lo interprete. Esto tiene la ventaja de que facilita la edición On-Line y de que el programa se puede recuperar desde el PAC, la desventaja es que su ejecución no es tan, tan rápida.

La diferencia está en las librerías.

Cuando hablamos de MC en CodeSys lo ponemos todo en el mismo saco y no es así. CodeSys es el entorno de programación, pero cada fabricante ofrece sus librerías para MC, en la mayoría de casos las conocidísimas PLCopen motion.

Pero estándar no es sinónimo de igual, un mismo FB tendrá más o menos opciones, según sean las posibilidades del equipo empleado, que dependerán del fabricante elegido.

Por otra parte, todas las instrucciones de todos los fabricantes, son bastante parecidas. Para hacer un posicionado los parámetros necesarios son los mismos, es un tema físico, aunque puede que un dispositivo de más opciones que otro. En la siguiente figura de muestran unos ejemplos de los bloques del Studio 5000. En muchos casos la diferencia está en el nombre de FB, pero en otros hay diferencias importantes a nivel de prestaciones

También existen equipos con librerías “Premium” para MC y en este caso es donde se pueden encontrar grandes diferencias en la facilidad de programación y las prestaciones.

P.ej: Supongamos que queremos hacer una cosa “tan simple” como mover un eje rotativo a una velocidad constante, según el valor de la variable rVelFeed y de forma que si su valor cambia, la velocidad del eje también, de forma inmediata, acelerando o decelerando hasta alcanzar el nuevo valor. Supongamos que también es necesario que, al detener el movimiento, el eje quede parado en la posición contenida en la variable rOrientedStoPos. Por otra parte, también se requiere la gestión de posibles fallos en el eje. Tal como se muestra en el gráfico:

Con PLCOpen Motion: De forma muy genérica, hay que instanciar un MC_Power para la habilitación del eje, un MC_MoveVelocity para el movimiento a velocidad constante, hay que detectar si ha habido un cambio en el valor de rVelFeed y si es así generar un nuevo flanco en la entrada i_xExecute del MC_MoveVelocity. Para cuando se quiera detener el eje y que quede parado en la posición contenida en rOrientedStoPos hay que calcular el espacio necesario para detener el movimiento en función de la velocidad y la deceleración actuales, comparar la posición actual del eje y ver si sumando la distancia de frenado necesaria quedaremos parados antes o después de la posición deseada según rOrientedStoPos, si nos hemos pasado hay que esperar a la siguiente vuelta, de lo contrario ya podremos detener el movimiento a velocidad constante y arrancar un posicionado, en modo “blending” para que el eje se detenga en la posición rOrientedStoPos.

Para la gestión de posibles fallos habrá que decidir cuáles son los más probables y/o cuales se quieren detectar y escribir “unas pocas” líneas de código para la consulta de estados y fallos del eje.

Con PacDrive 3: De forma muy genérica, hay que instanciar un único FB_AxisModule, este FB realiza todas las funciones necesarias para cualquier tipo de movimiento de un eje, incluyendo la gestión de posibles errores y un DataLoger de todo lo acontecido en el mismo. Bastará con “conectar” los valores de rVelFeed y rOrientedStoPos a la estructura de parámetros correspondientes, el FB se encarga de realizar el seguimiento del valor de la velocidad de referencia y del paro orientado, sin que haya que escribir ninguna línea de código para tal fin.

En ambos casos la aplicación se habrá realizado en un entorno basado en CodeSys, pero empleando las librerías de PLCOpen Motion habrá sido más costoso que con las librerías del AxisModule. En este caso las librerías de Schneider electric ofrecen mucho más valor que las de PLCOpen Motion.

Resumen / Conclusiones

En tres décadas el MC ha avanzado de forma espectacular, se ha pasado de un hardware con procesadores de 8 y 16 bits con capacidad de memoria de unos pocos KB, ejecutando las instrucciones a intervalos de, entre 2 y 5 mseg. y con capacidad de control de pocos ejes. A procesadores de 64 bits, con memoria “ilimitada” y que ejecutan instrucciones en cuestión de nanosegundos y “pueden” con más de 100 ejes. A nivel de software los avances han ido en paralelo.

En la actualidad la oferta de MC es muy amplia y los diversos sistemas tienen capacidades similares. Por lo que la elección no resulta nada fácil. Hemos visto que estándar no quiere decir igual, hemos visto que en los sistemas compilados sin el programa fuente no hay nada que hacer, pero son más rápidos ejecutando el código. Otros sistemas son interpretados y permiten hacer un Upload del programa del PAC, a cambio de una reducción en la velocidad de ejecución. Cuando se trata de aplicaciones de altas prestaciones, hay equipos que disponen de librerías que facilitan mucho su programación y ofrecen más posibilidades. A nivel de lenguajes de programación se está empleando, cada vez más, la programación orientada a objetos (Métodos, Propiedades, Herencia, etc.) por lo que es aconsejable formarse en este aspecto.

Linkedin Pere Garriga

/blogs-automatizacion/marcas/498-motion-control

Motion Control

Blog dedicado a la introducción en los conceptos de Motion Control (Control de movimiento) en sistemas de automatización




Descargas