El autómata programable, un universo de posibilidades en constante evolución

Fue Dick Morly, actualmente conocido como el padre de los PLCs, quien estuvo involucrado en el desarrollo de este primer PLC para GE, conocido como Modicon (MOdular DIgital CONtroller). El objetivo y diseño de un PLC no dista tanto del de un PC convencional. Ambos están formados principalmente por entradas, salidas, memoria y una CPU. Y de la misma manera, su objetivo elemental es, ante la conmutación en una o varias de sus entradas, realizar cálculos lógicos y, como resultado, activar o desactivar una o varias salidas. Sin embargo, hay un aspecto fundamental donde un PLC difiere de los ordenadores ofimáticos: la robustez. Este fue, precisamente, uno de los aspectos fundamentales que GE buscaba para sus desarrollos: un dispositivo muy fiable, capaz de operar en las complicadas condiciones industriales, con rangos de temperatura, humedad y alimentación extendidos, con una alta resistencia a las vibraciones y a los impactos y, por supuesto, con una alta inmunidad al ruido electromagnético. Otra diferencia sustancial es el número de E/S (entradas y/o salidas) que es capaz de manejar un PLC. A diferencia de un PC convencional, cualquier PLC actual parte de cientos de E/S hasta llegar a los miles que puede gestionar un PLC actual de gama alta.

Durante estos más de 40 años, los PLCs han evolucionado en muchísimos aspectos y, si en sus inicios su misión fundamental era sustituir a la lógica cableada, hoy en día, con los avances tecnológicos y la gran reducción de costes, su objetivo llega mucho más allá que el de hacer cálculos lógicos.

Así, además del control de la lógica discreta, el control de procesos continuos con señales analógicas o de sondas de temperatura fue una de las primeras incorporaciones al mundo del PLC.

Pero ha sido a partir del año 2000 cuando el mundo del PLC ha sufrido un mayor avance. Con la reducción de costes en los equipos electrónicos más complejos y en la electrónica de potencia, surgieron los controladores específicos para visión artificial, para ‘Motion Control’, seguridad, etc.

Con todos esos controladores, aparte del PLC, surgió la necesidad imperiosa de la integración: con diferentes redes de comunicación, diferente software de configuración, diferentes lenguajes de programación, etc.

Hoy en día, en el afán de simplificar la integración de todos estos sistemas, surge el concepto de MAC (Machine Automation Controller) o PAC (Programmable Automation Controller), donde el PLC evoluciona para soportar muchas de las disciplinas antes comentadas. De manera que desde un único software, con un leguaje e interface común y sin ningún problema de interconexión, un único controlador pueda hacerse cargo de la automatización de una máquina o una línea de producción entera.

Uno de los problemas que apareció con la evolución y comercialización de los diferentes modelos de PLC, es la fragmentación en los lenguajes de programación usados en cada uno de los equipos, acentuado además por lenguajes propios de las diferentes marcas.

El lenguaje con el que comenzó todo fue el ‘ladder’. Este lenguaje, se inventó para representar de una manera clara la lógica realizada con relés, y cuyo diagrama, con las diferentes conexiones y contactos, recuerda al de una escalera (‘ladder’ en inglés) con sus diferentes peldaños (‘rungs’).

Sin embargo, con la inclusión de nueva funcionalidad en los PLCs fueron apareciendo nuevos lenguajes, más adecuados para realizar otras tareas, como cálculos aritméticos complejos, sentencias condicionales o que permitían una mayor reutilización del código.

Así, a finales de 1993, la IEC publicó la primera revisión del estándar 61131, que en su apartado tercero define los lenguajes de programación estándar de un PLC. Actualmente son los siguientes:

• Ladder Diagram (LD, diafragma de escalera)
• Function Block Diagram (FBD, diagrama de bloques de función)
• Structured Text (ST, texto estructurado)
• Instruction List (IL, lista de instrucciones)
• Sequential Function Chart (SFC, gráfico de funciones secuenciales)

Esto proporciona un abanico muy importante de posibilidades en la programación de los controladores actuales. Incluso, algunos fabricantes permiten mezclar varios de ellos en un mismo programa, haciendo que la tarea de desarrollo sea muchísimo más sencilla.

Por otro lado, la norma IEC anterior, no sólo se limita a definir los lenguajes de programación, sino también los tipos de datos y algunos aspectos propios del funcionamiento del propio controlador: gestión de datos usando variables, uso de tareas, etc.

Esta estandarización, junto a otras, hace que de una manera muy sencilla, se puedan utilizar diversos controladores sin tener que aprender ningún nuevo lenguaje o forma de programar.

Si echamos un vistazo a los controladores actuales (los MAC o PAC) que comentábamos antes, podemos observar como la arquitectura ha pasado de utilizar CPUs propias, de tipo ASIC a microprocesadores estándares de mercado; habitualmente AMD o Intel.

Esto trae consigo importantes avances en las posibilidades y velocidad de los controladores, lo que a su vez ha posibilitado la integración de más disciplinas en un único equipo.

Así, en alguno de los equipos más potentes del mercado, podemos encontrar, por ejemplo, microprocesadores Intel Atom, a 1,6 GHz, que proporcionan una velocidad de proceso nunca antes vista en controladores industriales.

Esta velocidad también depende en gran medida del software que tenga que soportar esa CPU. Así, es habitual encontrar controladores que ejecutan Windows CE o Windows Embedded que, de forma habitual, necesitan más recursos para funcionar que otros Sistemas Operativos, llamados ‘Hard Real Time OS’, orientados al control industrial y que garantizan una repetitividad y fiabilidad tan alta que son los elegidos para el control en otros sectores, como el aeroespacial, el de defensa, en medicina, etc.

Ejemplos de este tipo de ‘Hard Real Time OS’ son QNX o el Microware OS-9.

Sobre el sistema operativo, los controladores MAC o PAC ejecutan el software ‘runtime’ del propio fabricante. Este software ‘runtime’ suele ser modular y es el encargado de ejecutar las secuencias lógicas (módulo PLC), del control de movimiento (módulo de ‘Motion Control’), del control de robots (‘kinematics’), CNC, etc.

Normalmente existe un módulo principal que suele ser el de PLC, que se encarga de la lógica y realiza las llamadas oportunas al resto de módulos cuando en programa de usuario requiere de esos módulos.

Imaginemos un programa sencillo de una máquina de corte al vuelo, encargada de cortar cada uno de los envases que pasarán a la siguiente etapa dentro de la línea de producción y donde el punto exacto de corte vendrá dado por una marca en el propio envase.

En la cinta transportadora, por donde se desplaza el film (tira continua de envases, aún sin cortar), se colocará una fotocélula, a una distancia determinada de la cuchilla. Esta fotocélula será la encargada de detectar las marcas presentes en el film para que la cuchilla llegue a moverse a la velocidad adecuada y llegue al punto de corte a la misma velocidad exactamente de la cinta transportadora.

En este ejemplo, si el módulo de PLC es el principal, se encargará de iniciar la ejecución de programa y en cada uno de los movimientos, hará una solicitud al módulo de ‘Motion Control’. Estos movimientos están muy bien definidos, pues actualmente casi todos los fabricantes utilizan el estándar PLCopen (a su vez, basado en el IEC 61131-3) para el control de movimiento y cada una de las instrucciones que hacen uso de este módulo comienzan por MC. Por ejemplo:

• Inicializar los ejes y que los ‘drives’ entreguen potencia a los motores
• Realizar la búsqueda de origen en el eje de la cuchilla
• Comenzar el movimiento de la cinta, lineal y sin fin en el eje de la cinta
• Y una vez detectada la marca, establecer la sincronización necesaria entre los dos ejes para que la cuchilla rotatoria alcance la marca en el momento justo
• Vuelta al origen del eje de la cuchilla

Adicionalmente, el módulo principal, en este caso el de PLC, también suele estar encargado de otras tareas, como es el refresco de las E/S y la atención a periféricos (atención a puertos USB, Ethernet, acceso a tarjetas de memoria, etc.).

Comentábamos unas líneas antes que IEC 61131-3 definía no solo los lenguajes de programación, sino que llegaba a especificar la arquitectura de funcionamiento de los controladores.

De este modo, los controladores basados en este estándar tienen todos algo en común: un modelo de ejecución por tareas.

Existen dos modelos de ejecución de tareas:

• Non-Yielding (improductivo)
• Yielding (productivo)

En el primero de ellos, una tarea tiene que esperar a que otra termine para poder ejecutarse. En el segundo, se establece un sistema de prioridades, de manera que una tarea con una mayor prioridad puede interrumpir a otra y comenzar su ejecución. La tarea interrumpida reanudará su ejecución cuando termine la ejecución de las tareas de mayor prioridad.

Este último sistema ofrece un rendimiento mayor, a la par que permite garantizar el determinismo del sistema; es decir, que una misma secuencia de una determinada prioridad se ejecute siempre en el mismo tiempo, independientemente de la carga (número de secuencias en ejecución en ese momento) del sistema. Sin embargo, este último sistema de gestión de tareas también es más complejo y requiere de un Sistema Operativo de tiempo real, por lo que no puede estar presente en todos los controladores actuales.

En este sistema productivo existen tareas de diversa prioridad, como decíamos, aunque también pueden existir tareas de eventos, de atención a periféricos o, simplemente, de procesos internos.

Nos interesan aquellas tareas a las que se les pueden asignar programas de usuario. Este modelo, definido por la norma IEC, permite asignar múltiples programas a cada una de las tareas de diferente prioridad.

Esto conlleva que los programas asignados a una tarea de mayor prioridad siempre se ejecutarán antes que los asignados a una tarea de prioridad inferior. Y dentro de este modelo, los programas asignados a una misma tarea se ejecutarán cíclicamente, uno a continuación de otro. Este orden habitualmente se puede establecer en el software de programación.

Tan importante como una buena asignación de tareas, es la asignación del refresco de E/S, ya que un buen ajuste de las prioridades y las asignaciones permitirá llevar los ciclos de la máquina al mínimo.

Este refresco de las E/S, cuando se trata de unidades de E/S locales no representa ningún problema. Pero sin embargo, cuando se trata de unidades de E/S distribuidas o debemos efectuar un control de movimiento de la máxima precisión, es necesario apoyarse en alguna de las mejores redes de comunicaciones del mercado, en la que conectar esos servo accionamientos, E/S y otra periferia.

En la actualidad existen múltiples redes que permiten integrar E/S, servos y otros muchos dispositivos. Sin embargo, si miramos con detenimiento las especificaciones técnicas, resultados reales y la expansión que está sufriendo en el mercado, podemos hablar de EtherCAT como la red que destaca sobre las demás, a nivel de máquina.

Una característica de EtherCAT es que utiliza cable Ethernet estándar para realizar el cableado entre el controlador y los diferentes nodos de la red. Al mismo tiempo, cada nodo dispone de dos puertos: uno de entrada y otro de salida.

De esta manera, se puede construir una red ‘daisy-chain’ sin ningún hardware adicional y un cable totalmente estándar y económico. Por otro lado, EtherCAT es flexible y, si en un momento se necesita montar otra topología de red, distinta de la de cadena, existen bifurcadores en el mercado que nos permiten crear cualquier estructura en árbol.

Pero la principal característica de esta red no se encuentra en la facilidad de cableado, sino en la rapidez. El funcionamiento, a pesar de utilizar cable Ethernet estándar, dista mucho de ser el de una Ethernet convencional. Y es que en EtherCAT, el maestro lanza una trama de tamaño fijo (determinado por el número de nodos y la información a intercambiar por cada uno de ellos) y llega al primero de los nodos. Éste, lee la información que necesita y escribe otra información en la trama, en su espacio reservado para ello.

A continuación, este nodo envía esa trama modificada al siguiente, y este vuelve a leer y escribir datos en el espacio que tiene reservado para ello. Al llegar al último nodo, éste devuelve la trama, ya con todos los datos, al maestro; siempre trabajando en una red ‘full-duplex’, por lo que el envío y recepción se puede llevar a cabo simultáneamente.

Otro punto a destacar de esta red, es que cada nodo tarda un tiempo virtualmente cero (en la práctica, menor de 1 µs) en leer y escribir en la trama que viaja por la red. De hecho, se dice habitualmente que la trama que pasa por un nodo EtherCAT está saliendo al siguiente nodo antes de que termine de entrar.

En cifras, EtherCAT es tan rápido que podría refrescar 178 ejes, intercambiando cada uno 64 bytes, en 1 ms. Sin embargo, ningún controlador industrial actual es capaz de procesar esa cantidad de información en tan poco tiempo. Y por supuesto, ninguna otra red industrial llega a ese nivel de rendimiento.

Así, en el mercado, los controladores más avanzados serán capaces de controlar (ya no solo intercambiar información con los mismos) unos 32 ejes en 1 ms, con lo que el cuello de botella, que antiguamente se encontraba en los buses de comunicaciones, ahora pasa a los propios controladores, permitiendo que estos evolucionen de aquí a unos años sin tener que preocuparse por el sistema de comunicaciones.

La integración de la parte de PLC, de ‘Motion Control’, de visión, de robótica, de ‘Safety’, de CNC, etc., no sólo trae consigo una homogeneidad a la hora de desarrollar sino que permite una integración total entre cada una de las disciplinas a implementar permitiendo compartir variables, datos y una sincronización y precisión absoluta entre cada uno de los elementos de la máquina.

Al mismo tiempo, el software evoluciona creando verdaderos estudios de desarrollo, desde donde se puede configurar, ya no solo el controlador, si no cada una de las distintas partes de la máquina, desde un interface común.

Y este mismo software deberá ser el encargado de guiarnos durante todo el proceso de desarrollo, asistiéndonos y ayudándonos en cada uno de los aspectos de configuración y programación. Pero más allá de permitirnos programar un dispositivo concreto, será capaz de permitirnos y asistirnos en la creación de una máquina completa.

Un paso aún más allá, será la comprobación y el testeo de nuestro desarrollo. Las mejores herramientas actuales ya permiten realizar una simulación de todas las disciplinas implementadas en la máquina (secuencia, control de movimiento, visualización, etc.) y detectar y corregir errores antes incluso de tener el hardware. Pero no solo eso, sino que el diseño en 3D de la máquina y la integración con otras herramientas de regulación y procesos, como Matlab permitirán desde la herramienta de software diseñar toda la máquina y asegurar, incluso antes de montarla, que funciona.

No cabe duda de que el futuro nos depara controladores más rápidos, potentes, con más memoria, etc., pero al mismo tiempo con funciones útiles, que hagan más fiables las máquinas y que permitan un desarrollo mucho más rápido.