Subrutinas

Una metodología que suele pasar desapercibida cuando recién nos adentramos a la programación de autómatas programables es el uso de subrutinas, las cuales son muy útiles al realizar la puesta en marcha de un proceso muy complejo pues una de sus cualidades es la segmentación del programa principal en programas más sencillos que resultan más fáciles de interpretar y de verificar ante posibles errores. Si bien nuestra ignorancia sobre esta metodología puede deberse a lo simple que resultan los sistemas que encontramos a lo largo de nuestra formación, trataré de demostrar con un ejemplo sencillo que no es necesario tener un código sumamente extenso para poder realizar una correcta segmentación del mismo. Empecemos con un poco de teoría pues hay diversas propiedades que debemos mencionar.

¿Qué es una subrutina?

En la teoría general de programación, una subrutina (o subprograma) es una parte del código que realiza una operación en concreto, la cual suele tener cierta periodicidad. Éstas son utilizadas con fines como ahorrar memoria en el controlador, reducir el estrés del procesador o bien, para hacer que la estructura principal del programa sea más comprensible para el usuario. Una subrutina se debe ejecutar siempre llamándola con una instrucción tipo CALL y al final de ella debe aparecer, siempre, una instrucción del tipo RETURN para volver al código principal.

Fig. 1: Estructura general de rutinas y subrutinas.

Existen distintas formas de realizar el llamado de subrutinas, las cuales son:

• Llamado a subrutinas desde el programa principal: Llamados directos a una o varias subrutinas
• Subrutinas anidadas: Permiten el llamado de una subrutina dentro de otra subrutina.
• Subrutinas de llamado múltiple: Es posible la existencia de más de una condición para el llamado de subrutinas.

Fig. 2: Tipos de subrutinas.

Consideraciones

Un programa puede tener hasta 64 subrutinas.

Se pueden programar hasta 8 subrutinas anidadas.

Se pueden tener hasta 16 parámetros de entrada/salida en cada subrutina, si se excede este número habrá error al compilar.

Es posible que una subrutina sea recursiva (se llame a sí misma al final de su estructura) pero se debe ser cuidadoso para evitar condiciones de “loop infinito”.

Crear una subrutina en Studio 5000

Al igual que cualquier otra instrucción, las referentes a subrutinas las encontramos en la barra de instrucciones dentro del “Program Control” y, tomando la nomenclatura de Rockwell Automation, observamos que las instrucciones de llamada (o CALL) reciben el nombre JSR (Jump to Subroutine o Saltar a Subrutina) mientras que las instrucciones de regreso aparecen como RET.

Fig. 3: Barra de instrucciones de Studio 5000.

Además de las instrucciones mencionadas, en este apartado encontraremos las relacionadas a etiquetas que corresponden a una segmentación del programa principal, pero sin la utilización de diagramas Ladder alternos, es decir, son interrupciones en el programa principal.

Para crear una subrutina solo basta con ir a la capeta de tareas (o “Tasks”) dentro de nuestro árbol de proyecto y desglosar hasta la carpeta de programa principal (o “MainProgram”), haciendo un click derecho aparecerá la opción “add” donde su primera opción es agregar una nueva rutina.

Fig. 4: Creación de una subrutina.

Al realizar lo anterior aparecerá la siguiente ventana emergente, donde, además de nombrar a la nueva subrutina, también podremos elegir el tipo de programación que realizaremos (Ladder, SFC, FBD o ST), el programa bajo el cual estará subordinado (esto en caso de tener más de una tarea principal) y, opcionalmente, podremos agregar una descripción a la subrutina creada.

Fig. 5: Ventana emergente para la configuración de nuevas rutinas.

Esto nos generará un nuevo diagrama Ladder (en caso de haber seleccionado ese tipo de programación) donde podremos desarrollar la subrutina que necesitemos y, como podemos observar en la imagen siguiente, estará anidada en el programa principal.

Fig. 6: Nueva rutina creada.

Programar una subrutina

Una vez creada nuestra nueva rutina es momento de darle el carácter de subrutina y si bien esta propiedad se adquiere al ser creada después de la rutina principal (o “MainRoutine”), es necesario usar las instrucciones mencionadas anteriormente para su correcto funcionamiento. En este caso desarrollaremos una pequeña aplicación que solo haga el salto a la subrutina, realice cambios en variables internas del programa y active una salida.

Empezamos condicionando el salto a la subrutina, pues, de otra forma ésta se ejecutaría de forma constante. Para eso nos valemos de una entrada de tipo digital que, al ser activada, realizará un salto automático a la subrutina (que en este caso llamamos “Sub1”).

Fig. 7: Rutina principal.

Después de que la subrutina se ejecute, enviará un indicador a la rutina principal que permitirá la activación de una salida de tipo digital.

Ahora, el primer paso de la subrutina es usar la instrucción SBR y si bien esta no es estrictamente necesaria, considero que es de gran utilidad para tener un código bien comentado y que sea de fácil interpretación por cualquier operario que tenga acceso a éste, sin embargo, dicha instrucción nos permite importar parámetros desde la rutina superior (ya sea la principal o alguna bajo la que estemos anidados), la importancia de esto resulta cuando el parámetro importado es de carácter decimal pues uno de tipo digital puede ser fácilmente colocado en una variable de control.

El timer que aparece en el renglón cero será activado en el mismo instante en que se hace el salto a la subrutina pues no está condicionado al valor de otra variable.

Fig. 8: Subrutina Ladder.

Al finalizar la cuenta de 2.5 segundos, se activan las salidas del reglón uno, donde, además del indicador llamado “Activ”, aparece la instrucción “RET” que nos permite regresar a la rutina principal y, aunque no se utilizó en este caso, tiene un funcionamiento similar a la instrucción “SBR”, permitiéndonos exportar parámetros a alguna rutina superior.

Y como mencioné anteriormente, al final de este proceso se activará la salida llamada “Salida1”.

Otro tipo de programación

Una de las características que más me gustan de Studio 5000 es que nos permite el uso de diferentes lenguajes de programación, esto facilita el desarrollo de soluciones ante las interrogantes del sector industrial pues hay ocasiones en las que un diagrama Ladder (siendo el referente principal en cuanto a programación de autómatas industriales se refiere) puede resultar muy “enredado” en comparación con otros tipos de lenguajes, tal es el caso de un código secuenciado donde resulta más sencillo desarrollar en lenguaje SFC que en cualquier otro.

Entonces, para ejemplificar lo anterior desarrollé el siguiente código que realiza las mismas acciones de la subrutina anterior, pero, en un lenguaje distinto.

Fig. 9: Subrutina en lenguaje SFC.

El programa se vale de la rutina principal mostrada anteriormente, el único cambio realizado es que la instrucción “JSR” salta a esta nueva subrutina llamada “Sub2” donde la llamada “Step_002” es la etapa inicial que contiene al timer de 2.5 segundos dentro de sus propiedades.

Fig. 10: Propiedades de las etapas de un código SFC.

Mientras se esté en dicha etapa, la propiedad “Timer” estará realizando un conteo y, en el momento en que se iguale el valor del “Preset”, se procederá a la siguiente etapa (denominada “Step_003”) donde el indicador llamado “Activ” toma  el valor de 1 lógico y se desactiva la entrada que permite el salto a la subrutina, esto evita un ciclo infinito donde solo se ejecute la subrutina.

Conclusiones

A lo largo de esta explicación aprendimos cómo desarrollar subrutinas en la plataforma Studio 5000 de Rockwell Automation, sin embargo, aún más importante que esto es que aprendimos que una correcta segmentación de nuestros programas llevará a una solución más efectiva del problema en cuestión pues serán más evidentes y fáciles de identificar las distintas etapas que componen a nuestro programa.

Estoy consciente de que habrá casos donde la presencia de una subrutina solo hará que nuestro programa ocupe más espacio de memoria, entonces, no siempre serán necesarias, pero son una herramienta más de la cual disponemos al enfrentarnos con las innumerables interrogantes del entorno industrial. Además, la posibilidad de desarrollar código en los distintos lenguajes normalizados bajo el estándar IEC 61131, permite un sinfín de soluciones que dependen únicamente del programador en turno, de su familiarización con uno o varios lenguajes y de la tarea en cuestión.

-AHN