5 Errores comunes y frecuentes cuando Programas un PLC (y cómo evitarlos)

Errores PLC

Ya sea el resultado de la presión del cliente, la falta de café en la mañana o simplemente la distracción en el momento equivocado, vamos a cometer errores al programar un PLCs, veamos cuales son

1. No tener una arquitectura o estructura organizada

Cuando iniciamos la programación de un PLCs, desde el inicio todo el programa debe estar bien organizado, en secciones, subsecciones, etc generalmente basado en el sistema o equipo que vamos a controlador y mantenerlo bien ordenado. Mantener cada parte del programa por separado permite a la persona que trabaja con el programa visualizar fácilmente la ejecución general del programa.

También ayuda a depurar el programa si algo sale mal, ya que cada fragmento de programa se encapsula en su propia estructura. Finalmente, se ve mejor, porque no se ve el desorden de un programa completo en la pantalla al mismo tiempo.

Desafortunadamente, a medida que desarrolladores y los mantenedores posteriores a la implementación trabajan en el programa, a veces el programa comienzan incluir líneas fuera de cada sección y las enlazan a otras funciones supuestamente aisladas a su alrededor. Esto lleva a confusión cuando las etiquetas saltan de una hoja a la siguiente, o las salidas se escriben dos veces durante la ejecución.

Finalmente, esto puede ser peligroso, ya que pequeños ajustes en el PLC general pueden causar pequeños problemas en el programa hasta que se corrompe. El mantenimiento de la organización del programa y la encapsulación es fundamental para la longevidad de un programa de PLC.

2. No documentar el programa

Documentar el programa como está escrito (asbuilt) y, además, la forma como esta programación se mantiene es fundamental para mantener un PLC y su programa en funcionamiento durante los largos períodos de tiempo entre las actualizaciones y los ajustes. Unas pocas frases rápidas en cada parte importante pueden ahorrar mucho tiempo y dolores de cabeza más adelante. También puede ayudar al programador a poner sus pensamientos en un papel, lo que puede ser útil para determinar el siguiente paso.

A pesar de que el programa puede tener sentido en el momento en que se codifica, cinco minutos dedicados a explicar detalladamente por qué se usó una técnica en particular pueden ahorrar horas cuando, meses más tarde, un usuario debe descifrar lo que está sucediendo. Con demasiada frecuencia, el programa originalmente instalado en un sistema cambiará debido a correcciones, actualizaciones y adiciones de características. Si la documentación no se actualiza con el programa, esto puede generar confusión y una programación mal interpretada.

Esto incluso es muy problematico, si se cambia de persona que mantiene el PLC y la nueva persona tiene el “desafio” de entender el programa. Provecho!!

3. Creación de etiquetas y variables redundantes

A medida que se escriben las declaraciones lógicas y lineas en ladder, a menudo un programa puede tener múltiples ramas de lógica que eventualmente conducen a una etiqueta que funciona como una especie de «bandera» o “tag”. Esta bandera usualmente terminará activando otras partes de la lógica en el programa. A veces, estas partes de lógica se excluyen mutuamente, como una variable booleana, que requiere que el programa envíe un mensaje a una estación remota u otra, según el estado de ciertas entradas.

Si un programador no está prestando atención, se le puede poner en la situación de crear un «flag_1» y un «flag_2», con ambas etiquetas cumpliendo el mismo deber. Ahora, ambas variables necesitan ser probadas, lo que lleva a una mayor complejidad del programa y una mayor utilización de la memoria. Estos dos resultados no solo son una mala práctica de programación, sino que el uso repetitivo de etiquetas y variables redundantes requerirá que un programa utilice un procesador más potente (y por lo tanto costoso) que el requerido para la aplicacion.

4. No reutilizar el programa existente

Además de la facilidad de mantenimiento, depuración y legibilidad, la razón por la que es tan importante encapsular y aislar un programa de PLC, es que el programa encapsulado dentro de un bloque de funciones se puede reutilizar una y otra vez a lo largo del programa. Esto elimina el requisito de volver a escribir el programa que ya existe dentro de un bloque de funciones. Por lo tanto, el programador puede generar un bloque de funciones estándar de uso múltiple que se puede depurar y modificar una vez, y tener ese cambio reflejado en todo el programa.

Las colecciones de estos bloques de funciones de uso general se denominan bibliotecas de bloques de funciones, y muchos fabricantes ofrecen bibliotecas de bloques de funciones específicas de la industria para descargar en sus sitios web. Estas bibliotecas de bloques de funciones reducen considerablemente la cantidad de tiempo de desarrollo requerido para una aplicación o proyecto determinado.

A veces, sin darse cuenta, un programador se encuentra a sí mismo escribiendo un programa que ya se ha escrito. Cuando cinco o seis de los mismos equipos necesitan operar de manera similar, es fácil crear un bloque de función que acepte las entradas de los sensores y envíe soluciones para los actuadores. Por otro lado, puede ser más difícil en algoritmos aparentemente únicos encontrar una razón para escribir programa genérico.

El esfuerzo necesario para escribir un bloque de funciones que sea lo suficientemente genérico para ser reutilizado debe compararse con el tiempo empleado en el desarrollo del proyecto. Vale la pena, sin embargo, tener en cuenta que un poco de tiempo extra invertido inmediatamente puede ahorrar mucho tiempo más adelante.

5. No utilizar el control de versiones

Mantener su programa organizado es otra práctica importante que a veces se pierde en la “presion” de tratar de completar un proyecto para la puesta en servicio. Las versiones de sistemas de control pueden ser tan simples como nombrar un proyecto para un PLC particular una vez que se ha implementado, o tan poderosos como una aplicación dedicada utilizada específicamente para rastrear cuáles son los cambios en cada revisión principal.

El uso de dichos esquemas de control de versiones mitiga las situaciones en las que una solución o característica particular que podría haber sido ya implementado en campo o en producción, y el backup PLC que se va a cargar NO tiene el programa con estos cambios.

Los programadores a menudo se olvidan de realizar un seguimiento de los cambios en el programa en el PLC sin una estrategia de versión adecuada. La documentación, un buen esquema de denominación y, posiblemente, un software de control de versión dedicado pueden disminuir estos problemas y aumentar los detalles disponibles para el programador.

El software de control de versiones dedicado también permite que un sistema rastree al usuario que realizó cada cambio, documentado o no. Esto puede ser particularmente útil si varios programadores están trabajando en el mismo programa

Si te gusto COMENTA y COMPARTE!

14 Replies to “5 Errores comunes y frecuentes cuando Programas un PLC (y cómo evitarlos)

  1. Buenas tardes es muy bueno su aporte soy instalador electricista trabaje con la empresa techin como oficial instrumentista x 10 meses término la obra y quede afuera y como toda obra de construcción dura poco pero me gusta estudiar y ver lo nuevo y ahora ago instalaciones de paneles solares

    1. Hola Miguel, gracias por tus comentarios. Es una excelente decision capacitarse y mas en tema de automatizacion industrial. Si necesitas algun tipo de ayuda me avisas (jvillajulca@instrumentacionycontrol.net)
      Saludos

  2. buenas tardes

    favor tengo una inquietud con respecto a los tableros de comunicaciones

    quisiera saber que se refiere tablero de comunicaciones tipo :

    GABINETE DE COMUNICACIONES TIPO 1, I
    GABINETE DE COMUNICACIONES TIPO 2A,
    GABINETE DE COMUNICACIONES TIPO 2B,
    GABINETE DE COMUNICACIONES TIPO 2C
    es para un proyecto que se tiene de tableros de plc

    gracias

  3. Cordial saludo,
    Muchas gracias por sus aporte,realmente me fortalece en este campo estoy terminando los estudios en electrónica y créalo estoy en busca de oportunidades,me apasiona este campo de la automatización y combinarlo con lo de Internet de las cosas,estoy capacitando me al respecto y esta clase de articulo me fortalece mas.
    Muchas gracias
    Saludos

  4. Sr José, soy nuevo en programación de plc, me obliga atender el estudio 5000 por la naturaleza de mi trabajo, agradesco todo lo que hace y le hago seguimiento.
    att. luis gutierrez

  5. Buen dia Ing.: Felicitar por el trabajo que desarrolla y agradecerce por los conocimientos de gran uutilidad, que comparte con los que estamos en esta area de los PLCs. Gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.