Sie sind auf Seite 1von 15

Contenido

Aclaración

3

Introducción

3

Paso 1. Conocer bien el alcance del

4

Paso 2. Estructura los bloques

6

¿Por qué no el 111?

6

¿Qué nos va a permitir esto?

7

Paso 3. Asigna rangos a las I/O

8

¿Qué ganamos con ello?

8

Paso 4. Pasa las entradas y salidas a marcas

9

Paso 4. Asigna nombres a las cosas

11

Paso 5. Adelántate al futuro

12

Asigna una marca de ciclo al principio del proyecto

12

Crear un Always_On y un Always_Off

12

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

12

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

13

Paso 6. Crea un buen listado de alarmas

14

Paso 7. Crea unas buenas pantallas del HMI

15

¿Qué quiero decir con esto?

15

Aclaración

Este pequeño ebook es un extracto del libro-curso Cómo programar Step 7 sin morir en el intento.

Se trata de un curso completo para aprender a programar en Step 7, conocer cómo funciona un PLC y sacarle chispas a la programación en AWL.

En el podrás encontrar teoría mezclada con ejercicios expuestos mediante vídeos.

Puedes encontrar más información sobre este curso en:

Introducción

Siempre que comenzamos a programar, tenemos la incertidumbre de si la forma en la que trabajamos es la más adecuada o no. En esta guía te voy a contar unas pequeñas pautas que puedes seguir para estructurar correctamente tus proyectos. Bien es cierto, que estas 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.

Porque realizando estos pasos cuando comienzas el proyecto, harán que, durante el proceso de creación del programa, depuración, puesta en marcha y posterior mantenimiento ahorres muchas horas y vayas mucho más rápido, quedando todo de una forma mucho más profesional.

Paso 1. Conocer bien el alcance del proyecto.

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 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.

Podemos abstraernos por tanto a la hora de programar del resto de la máquina y centrarnos en muchos casos solamente en una pequeña parte de esta.

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 interactúan 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 sub-máquinas) independientes.

De cada máquina y sub-máquina qué detectores vas a necesitar y qué actuadores.

Para comprender bien la instalación tienes que conocer bien el pliego de condiciones. Estúdialo y no dejes nada a la interpretación. Si no tienes claro cómo ha de actuar una parte de la máquina, pregunta a quien te pueda sacar de dudas sobre cómo tiene que funcionar (clientes o compañeros).

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.

Dibuja, haz bocetos de cómo tiene que actuar cada parte y qué elementos van a intervenir en cada parte. Aplica lo que dijo Einstein en su momento:

“Si no puedo dibujarlo, es que no lo entiendo.”

No se trata de que sea una obra de arte ya que cuatro trazos pueden ser suficientes si para ti significan algo. Pero entiende cómo han de actuar los diferentes elementos de la máquina.

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.

Hacer un listado te va a obligar a pensar sobre qué necesitarás y es más fácil que no te dejes nada (o casi nada). Sacarás por tanto un número global de entradas y salidas que seguramente se acerquen mucho a lo que necesitarás finalmente (que normalmente

serás algunas más de las que habías pensado originalmente porque aparecerán “yaques” por el camino.

Además, este listado 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, o cajas de conexión, por ejemplo.

Paso 2. Estructura los bloques

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. Imagínate 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 la 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 quedará extraño y desorganizado.

Además de eso, en nuestro ejemplo, puede que unos transportadores lleven unos

actuadores tipo A, otros transportadores no lleven, otros sean tipo B

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.

Además, puedes completar la identificación con el uso de mayúsculas y minúsculas cuando asignas los nombres a los bloques.

Así, por ejemplo, asignando nombres en mayúscula puedes indicar que son bloques principales y los que estén en minúsculas, bloques auxiliares del bloque principal.

Por ejemplo:

etc.

FC100 CINEMATICA GENERAL

FC101 Transmisión 1

FC102 Transmisión 2

FC103 Transmisión 3

FC110 COMUNICACIONES

FC111 PLC1 <>PLC2

FC112 PLC1 <> PC

De esta forma es mucho más rápido localizar las zonas lógicas del programa e identificar qué depende de cada zona y cuáles son los bloques principales.

Paso 3. 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?

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 solamente 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

Si es la última zona no pasará nada porque será consecutiva, pero si es la zona 1 quedará horrible, ¿no crees?

¿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 transportador 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 que sea coherente.

Con el paso de los proyectos lo irás depurando y mejorando. No te agobies con ello. Simplemente dedícale un poco de tiempo a pensar y a distribuir las marcas y

temporizadores de tal forma que el simple número de marca o temporizador te dé una idea de a qué zona pertenece más allá del comentario que tenga asociado.

Paso 4. Pasa las entradas y salidas a marcas

Muchos programadores realizan un pequeño truco que es volcar todas las entradas a marcas y las salidas son previamente marcas que finalmente se igualan a las salidas.

Esto va a permitir cosas interesantes:

Podrás filtrar entradas antes de usar la señal. Solo manipularás en un sitio dicha señal.

Podrás cambiar fácilmente la entrada o salida física sin tener que buscar y sustituir a lo largo y ancho del proyecto. Sólo lo cambiarás en un sitio.

Si replicas máquinas para diferentes proyectos, no dependerá de las entradas o salidas físicas en cada proyecto ya que lo podrás adaptar de forma fácil a tener las I/O localizadas

Para realizar estas asignaciones lo mejor es crear dos FC: uno para las entradas y otro para las salidas que serán llamados al principio y final del OB1. El FC de las entradas al principio y el FC de las salidas al final.

Como ejemplo para que se entienda sería hacer un bloque FC de entradas de este estilo:

FC200 Entradas

U E0.0

= M100.0

UE0.1

= M100.1

U E 3.6

=M100.6

U

E100.7

=

M103.7

Y

así sucesivamente hasta terminar.

Análogamente las salidas serán simplemente de este estilo:

FC250 Salidas digitales

U

M200.0

=

A100.0

U

M200.1

=

A100.1

U

M203.7

=

A100.7

¿Podría hacer esto volcando palabras o dobles palabras?

Poder, puedes. Pero no debes.

Es decir, podrías hacer:

L

MW200

T

AW100

Y

así volcar toda la información de las marcas a las salidas.

Yo no lo haría ya que pierdes parte del objeto de esta maniobra, que es la claridad y poder asignar a posteriori las salidas o entradas de forma diferente, hacer filtros, etc.

Es más práctico, aunque más laborioso, ver cada entrada y cada salida a qué se ha igualado.

Paso 4. Asigna nombres a las cosas

FC,

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

marcas,

Y donde

digo

cosas,

me

refiero

a

FB,

DB,

Entradas,

salidas,

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 descripción de la variable.

Las marcas relevantes, pues le das un nombre lo más descriptivo posible de lo que hace.

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.

Paso 5. Adelántate al futuro.

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 para que el programa sea mucho más fácil de mantener a lo largo del proyecto, puesta en marcha y en un futuro más o menos lejano.

Asigna una marca de ciclo al principio del proyecto

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

O

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.

Mb0

M1.0

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.

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.

Paso 6. Crea un buen listado de 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 fácilmente 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 está programado el PLC. Sé todo lo user friendly que puedas.

Paso 7. Crea unas buenas 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

navegación entre pantallas.

y completa, pero no excesiva navegación entre pantallas. Fácil de entender la • Estéticamente agradable a

Fácil

de

entender

la

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, 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 especialmente 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.