Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Recomendaciones para programar PLC, Cheat Sheet of Programming Languages

Guía de pasos recomendados para estructurar un programa en un controlador lógico

Typology: Cheat Sheet

2019/2020

Uploaded on 07/08/2025

melvis-ortega
melvis-ortega 🇺🇸

1 document

1 / 15

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
http://programacionsiemens.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download Recomendaciones para programar PLC and more Cheat Sheet Programming Languages in PDF only on Docsity!

Contenido

  • Aclaración
  • Introducción
  • Paso 1. Conocer bien el alcance del proyecto.
  • Paso 2. Estructura los bloques
    • ¿Por qué no el 111?
    • ¿Qué nos va a permitir esto?
  • Paso 3. Asigna rangos a las I/O
    • ¿Qué ganamos con ello?
  • Paso 4. Pasa las entradas y salidas a marcas
  • Paso 4. Asigna nombres a las cosas
  • Paso 5. Adelántate al futuro.
    • Asigna una marca de ciclo al principio del proyecto
    • Crear un Always_On y un Always_Off
    • Deja espacio, sé generoso con el que venga detrás…
    • No seas un talibán de ningún lenguaje. Usa todos a tu antojo, pero con orden.
  • Paso 6. Crea un buen listado de alarmas
  • Paso 7. Crea unas buenas pantallas del HMI
    • ¿Qué quiero decir con esto?

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.

¿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... 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. 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:
  • FC100 CINEMATICA GENERAL
  • FC101 Transmisión 1
  • FC102 Transmisión 2
  • FC103 Transmisión 3
  • FC110 COMUNICACIONES
  • FC111 PLC1 <>PLC
  • 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 – 1 19.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

Análogamente las salidas serán simplemente de este estilo: FC250 Salidas digitales U M200. = A100. U M200. = A100. … U M203. = A100.

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

Poder, puedes. Pero no debes. Es decir, podrías hacer: L MW T AW 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

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

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.