Buenas prácticas de programación en S7

Siempre que comenzamos a programar, tenemos la incertidumbre de si la forma en la que trabajamos es la más adecuada o no. En la entrada que recupero del ostracismo (y que añado alguna cosa nueva) te voy a contar unas pequeñas pautas que puedes seguir, aunque estas buenas prácticas de programación en S7 no  son palabra de Dios, y por supuesto, pueden ser discutibles y/o matizables.

Son unas recomendaciones que te doy, y puede que a lo mejor te encajen en tu forma de estructurar un proyecto o al menos que te sirva para reflexionar sobre cómo has de afrontar los primeros proyectos que desarrolles.

Tengo una hoja en blanco ¿Por dónde empiezo para realizar buenas prácticas de programación en S7?

Lo primero que tienes que hacer cuando comienzas un proyecto es respirar hondo y no agobiarte. Te puede pasar que si miras el proyecto en su conjunto pueda ser un tanto mareante al principio… y lo es. Supongo que todos hemos pasado por ello.

Lo bueno que tiene la automatización seguramente junto con otro tipo de programas y software es que es muy modulable ya que la instalación está siempre dividida en máquinas, y estas a su vez en sub-máquinas y estas finalmente en un conjunto de señales y actuadores. Por tanto, podemos abstraernos a la hora de programar del resto de la máquina y centrarnos en muchos casos solamente en una pequeña parte de la máquina.

Pero ojo, no estoy diciendo que comiences a programar con una pequeña porción de la máquina sin pensar en el resto. Estoy diciendo que el problema global que es que la dichosa instalación funcione, la vas a poder cortar en cachitos y que cada cachito por separado no es tan fiero.

Por tanto lo primero que tienes que pensar es en qué máquinas se divide tu instalación y cómo interactuan entre ellas. Lo que deberías hacer en un primer estadio del proyecto es:

• Comprender muy bien la instalación. Qué debe hacer (y qué no).
• Hacer un listado con las posibles divisiones de la instalación o máquina, como máquinas( o submáquinas) independientes.
• De cada máquina y submáquina qué detectores vas a necesitar y qué actuadores.

Una vez comprendas que es lo que debe hacer, podrás dividir la instalación (o máquina) en trozos más pequeños e independientes. Esto nos va a ser útil a la hora de definir los bloques en los que se va a dividir nuestro proyecto.

Por otro lado, la enumeración parcial de cada señal y cada actuador, nos va a dar una idea global del volumen de entradas y salidas del proyecto. Esto te va a ayudar a su vez a valorar entre otras cosas si merece la pena centralizar todo en el armario eléctrico, o si va a ser mejor colocar por la instalación diferentes armarios remotos, por ejemplo.[divider]

Vale, ya tengo más o menos claro qué hace y qué necesito… ¿y ahora?

Ya tienes el qué, vayamos ahora en el cómo:

• Estructura tus bloques
• Asigna rangos de I/O
• Da nombres a las cosas
• Un buen listado de alarmas
• Bocetos de las pantallas del HMI

Cuando digo que estructures los bloques quiero decir que des rangos a tus FC, FB y DB. Imaginate que tienes 3 zonas bien diferenciadas de la máquina, pues una forma de estructurar tus bloques podría ser:

• Del 0 al 99 para bloques genéricos
• Del 100 al 199 a la zona 1
• Del 200 al 299 a la zona 2
• Del 300 al 399 a la zona 3

Así, por poner un ejemplo: imagina que dentro de las zona 1 tienes un transportador. Pues puedes hacer:

• FC110 «Transportador 1» para la lógica booleana que maneje todo lo que haya sobre ese transportador, sus marchas y paros, manual, automático etc.
• FB110 «Motor Transportador 1» Para el manejo del variador de dicho transportador, la gestión de las consignas que puede que le mandes por profibus, alarmas etc.
• DB110 «DB Motor Transportador 1», pues como DB de instancia del FB110

Esto como digo es un ejemplo. La idea que quiero que pienses es que todo lo referente al transportador 1, estará asociado con el concepto numérico «110» como cosa global.

Si tienes un segundo transportador, dentro de la zona 1, pues le asignas el 120.

¿Por qué no el 111?

Dependerá de cada proyecto, pero siempre que puedas, y para mi gusto, separa los bloques. Imagina que encima del transportador 1 tienes un par actuadores neumático que hacen algo, lo que sea. Yo le daría en ese caso:

• FC 111 «Actuador #1 Transp. 1»
• FC 112 «Actuador #2 Transp. 1»

Todo esto suponiendo que tengan suficiente entidad como para que tengan su propio FC y no puedan ser agrupados en un único FC 111 «Actuadores Trans. 1». Espero que cojas el concepto.

¿Qué nos va a permitir esto?

Pues básicamente, un poco de orden. Porque como te acostumbres a poner todos los bloques seguidos, va a ser un caos. Por el simple hecho es que la vida del proyecto es larga, y seguro que vas a tener que insertar nuevos actuadores sobre partes de las máquinas. Como hayas puesto:

• FC 110 Transportador 1
• FC 111 Transportador 2
• FC 112 Transportador 3
• FC 113 Transportador 4

Ahora imagina que los actuadores de los que hablamos, no estaban contemplados en el proyecto inicialmente, y ahora hay que añadirlos… tú lo has dicho, vaya mierd..

Además de eso, en nuestro ejemplo, puede que unos transportadores lleven unos actuadores tipo A, otros transportadores no lleven, otros sean tipo B.. etc.

En cambio, si divides a espaciado fijo, sabes que todo lo que hay en los FC 11x pertenecen a la misma parte de la máquina, el transportador 1 en nuestro caso. Creo que la idea queda suficientemente clara.[divider]

 Asigna rangos a las I/O

Al igual que has hecho con los bloques, la idea sería la misma para las entradas y salidas. Intenta dar rangos a las zonas de las máquinas. De tal forma y siguiendo con nuestro ejemplo, imagina que has decidido poner 3 remotas, una por cada zona de tu instalación.

Asigna rangos a las I/O:

• EB100 – EB199 para la zona 1
• EB200 -EB299 para la zona 2
• EB300 – EB399 para la zona 3

 ¿Qué ganamos con ello?

Como antes, claridad y orden. Pero algo más… orden de cara a futuro.

Si vas a montar 3 periferias remotas y asignas las direcciones de I/O según te las asigna Step7 de forma automática, vas a tener todas las entradas y salidas seguidas como un paso doble Hasta ahí no habría mucho problema más allá de que como digo, queda más limpio saber que si te digo E 212.0 automáticamente sabes que te estoy hablando de una entrada de la zona 2 sin mirar absolutamente nada.

Pero no solamente eso. En un futuro, puede que tengas que ampliar una de las periferias con una nueva tarjeta… pues como no hayas pensado en espaciarlas, no sólamente no tendrás coherencia entre la numeración entre zonas, sino que dentro del mismo rack tendrás numeraciones altas y bajas ya que al añadir una nueva tarjeta, tendrás forzosamente que asignar un número más alto que el último que Step7 le asignó a la zona 3… que si es esta zona, no pasa nada, pero si es la zona 1 queda horrible.

 ¿Pero habría algún problema por ello?

Ninguno, pero hombre, ya que estamos, además de que funcione, que parezca que le hemos dedicado 10 minutos a pensar cómo asignar las entradas y salidas ¿no?

¿Qué pasa con las marcas, temporizadores etc?

Análogamente, asigna rangos para el resto de elementos. Por ejemplo: Si estas en el tranportador 1, que es el FC 110, pues asigna las marcas 110.0 – 119.7 para dicho transportador, si con ello te va a ser suficiente.

Puedes dar un rango de marcas para las palabras, otro para las dobles palabras… etc. Dale al coco y haz tu propio esquema.

Asigna nombres a las cosas

Y donde digo cosas, me refiero a FC, FB, DB, Entradas, salidas, marcas, temporizadores…

Si no pones nombre a las marcas e I/O va a ser muy complicado el  mantener el programa, por no decir imposible. Es una locura encontrarte programas que no están comentados… pero nada comentados. Es para echarse a llorar cuando el programa es complejo. No hay forma de seguirlo muchas veces con comentarios, como para seguirlo sin una triste indicación de qué hace qué.

Lleva mucho tiempo, y no siempre es fácil mantener la tensión de comentar todo, pero hay que intentar que todo esté razonablemente comentado.

Una forma que yo suelo usar ( y aquí cada maestrillo tiene su librillo) es la siguiente:

• Para las entradas y salidas, como nombre simbólico suelo poner el nombre del elemento de campo que es, por ejemplo el «25B3» y como comentario qué es con palabras. Puedes poner el IME completo por ejemplo «+ZonaA-25B3»  mientras que te entre en el campo de descripcion de la variable.
• Las marcas/temporizadores etc auxiliares las marco con su propia dirección «M17.5»  y en la descripción pongo «auxiliar». Así indico que la marca es necesaria como un auxiliar pero que no sale de ese bloque y que no está usada de forma global en el programa.

 Buenas prácticas de programación en S7

Ya hemos visto las cosas que tenemos que tener en cuenta a la hora de organizar el programa, pero aún no hemos programado ni un segmento. Ahora van las propiamente dichas de qué hábitos debes adquirir.

Apunta esta, grábala en letras de oro o haz lo que estimes oportuno pero:

[quote]Sólo da valor a una variable/salida en un sitio[/quote]

Hacer un =A1.0 en dos sitios diferentes del programa es de cárcel. Jamás lo hagas. Si tienes que declarar 8 marcas y hacer la lógica que sea, la haces, pero nunca, nunca nunca nunca nunca, asignes dos veces una salida. Y quien dice una salida, dice una marca. ¿Por qué?

Porque siempre tomará el valor de la última vez que le diste valor. Si cambias el orden de ejecución, cambiará la forma de ejecutarse.

Imagina que has puesto en una parte del programa (FC1) un

U M0.0 

S A1.0

Y en otro bloque (FC2)

U M1.0

S A 1.0

Y en otro, pues un reset (FC3)

U M2.0

R A1.0

Vale. ¿Cuánto valdrá A 1.0? Pues mas menos npi. Dependerá de cómo estén las marcas que los hacen un Set o Reset y en qué orden han sido llamados los bloques… y eso, siempre y cuando dentro de un año, no se te ocurra que en el bloque FC2, en vez de un set, es mejor un
U M1.0

= A1.o

Que entonces la fiesta ya es completa.

Si hay varias condiciones que activan y desactivan la A1.0, las asignas una marca, y luego agrupas todas para hacer un set, y por otro lado las que tenga que hacer un reset, o un igual o lo que haya que hacer… pero UNA ÚNICA ASIGNACIÓN ¿Está claro? Repite conmigo:

[quote]Sólo asignaré una salida en un sitio[/quote]

 Asigna una marca de ciclo al principio del proyecto

Como ya te conté anteriormente, es bastante práctico seleccionar la marca de ciclo al principio del proyecto de cara a que si en la puesta en marcha, o con la máquina ya funcionando te hace falta un tren de pulsos, dispongas de una forma sencilla de estos, sin tener que volver a compilar el proyecto y mandárselo al PLC pasando la CPU a stop, cosa que siempre no es posible en el momento que lo quieres hacer.

Crear un Always_On y un Always_Off

Esto más que una buena práctica, es un truquillo: si tienes una marca que esté siempre a cero y otra que esté siempre a uno, te ayudará a la hora de hacer pruebas, y desarrollar el programa en la línea ya que podrás hacer un bypass fácilmente a alguna condición, evitar que un segmento no se ejecute etc.

También puedes coger el byte entero lleno de ceros, que te servirá para borrar datos usando el Sfc21 FILL. Para ello, simplemente tendrás que hacer un

L 0

T Mb0

O M1.0

ON M1.0

= M1.0

De tal forma que el byte 0 contendrás siempre ceros y el bit 1.0 estará siempre a 1. Tonto, pero útil.

 Deja espacio, sé generoso con el que venga detrás…

Que muy probablemente puedas ser tú. Si vas a crear un DB donde almacenar datos para registro o intercambio con otros PLC por ejemplo, deja espacio libre para que en una eventual ampliación no haya que replantear nada ni hacer grandes modificaciones, sino que con tomar parte del espacio que este libre, sea suficiente.

Lo mismo digo a la hora de asignar las entradas y las salidas, deja espacio para posibles nuevos actuadores o señales, de tal forma que una futura ampliación no provoque la ampliación de un bastidor porque en su día las entradas estaban usadas. Todo cuesta dinero, pero es necesario hacer ese esfuerzo porque a la larga, es más barato si luego no hay que echar nuevas mangueras, instalar más tarjetas etc.[divider]

 No seas un talibán de ningún lenguaje. Usa todos a tu antojo, pero con orden.

Una de las entradas que más consultas recibe el blog es la de qué lenguaje elegir a la a hora de programar en Step 7.

Lo que no saben, es que no hay respuesta absoluta para esa pregunta… pues depende.

Acostúmbrate a usar todos los que quieras, cuando quieras. Personalmente no mezclaría en un bloque FUP con KOP, aunque sí cualquiera de ellos con AWL. No los mezclaría porque muchas veces no son traducibles entre sí, y al pasar de uno al otro, puede que el que dejas no sea traducible y se quede en un AWL difícil de digerir así de repente, obligándote a pasar de uno al otro para seguir fácilmente el programa.

Pero por lo demás, cambia cuando quieras, prueba y disfruta de la variedad que ofrece Siemens en ese sentido.[divider]

Alarmas

Una de las cosas más importantes en una buena automatización es la colección de alarmas. Puede parecer trivial, pero para nada lo es. Crear un listado de alarmas relevantes, que aporten facilmente qué es lo que está fallando y sobre todo no dejarte nada en el tintero, es casi imposible.

Pero puedes seguir una serie de pautas:

• Puedes usar marcas o un DB sólo para alarmas. A mi juicio mejor usar un DB con BOOL ya que las verás todas juntas además de poder comentar cada una dando mayor información a simple vista.
• Enumerar los pasos automáticos y coloca timeouts  con los que saber en qué paso se ha parado la línea.
• Lista los finales de carrera de seguridad, presostatos, temperaturas etc y decide qué valores son extremos para que salte una alarma.
• Establece dos grupos: los que pararán la máquina (si las hay) y las que simplemente serán indicativas de un malfuncionamiento. Reserva memoria en el DB para ambos grupos de cara a su ampliación.
• Piensa cada texto que va a acompañar a cada alarma. Intenta pensar que cuando salte, lo va a leer alguien que no tiene  ni idea de cómo esta programado el PLC. Sé todo lo user friendly que puedas.

Pantallas del HMI

Decía Albert Einstein algo así como «si no puedo dibujarlo, es que no lo entiendo».  Además de una cita genial, me da pie a comentarte una cosa fundamental y que por ello lo he dejado para el final.

A ver si me queda lo más claro posible:

• No programas para ti
• Las normas son para cumplirlas
• Intenta tener un poco de gusto
• ¡No programas para ti!

No. No es un error. He puesto que ¡No programas para ti! dos veces. Con esta tres.

¿Qué quiero decir con esto?

Pues eso, que el tipo que va a usar tu máquina probablemente no haya visto un programa en su vida (más que probable) y sinceramente, ni es relevante, ni le importa.

Lo importante es lo que puede ver y hacer desde la pantalla.

• Mandos claros
• Información clara y completa, pero no excesiva
• Fácil de entender la navegación entre pantallas.
• Estéticamente agradable a la vista (dentro de lo que se pueda)

Piensa que la persona que va a manejar la máquina, en general un operario de producción, no le importa ni cuantos motores tiene tu máquina, ni detectores, ni las filigranas que hayas hecho en el código. Hablando groseramente… se la pela.

Lo que le importa, sin duda, es lo que puede hacer desde su pantalla, desde sus mandos y qué información devuelve para que él esté informado.

Por eso es importante que los mandos sean claros, que no haya que leerse mil  páginas de manual para entender cómo funciona la máquina y que sea lo más intuitiva posible.

La navegación entre páginas ha de ser lo más coherente posible: los botones y el comportamiento de estos sean previsibles. Es decir, que si los botones de las páginas están abajo, estén siempre abajo, del mismo tamaño, si son con dibujos sean todos coherentes etc.

Por otra parte, las normas especialemente a los colores y modos de trabajo, han de cumplirse. Es pecado capital poner un botón verde como reset o rojo como cycle start.

Finalmente, un cojo-programa con unas pantallas poco cuidadas parecerá que está cogido con pinzas. Ten un poco de gusto, que tampoco cuesta tanto.[divider]

¿Cuáles son tus buenas prácticas?

Y de momento, creo que son todos los consejos de la abuela que me han pasado por la cabeza.  Puede que en alguna o muchas discrepes o tengas mejores formas de plantearlo. Si quieres compartirlo con el resto, comentalo y con gusto puedo ir actualizando la entrada con nuevas aportaciones.[divider]

¿Estás inmerso en un nuevo proyecto?

Si por otro lado estás planteándote comprar material de Siemens (u otros fabricantes) para tu próximo proyecto, no dejes de usar el botón arriba a la derecha para solicitar un presupuesto del material. Te vas a sorprender de los precios que puedo conseguirte a través de masvoltaje.com. Te invito a que hagas la prueba y luego me cuentas.