Buen programador frente a mal programador

Un programa de PLC se escribe una vez y se lee cientos de veces: en la puesta en marcha, en cada avería y en cada modificación, muchas veces de madrugada y con la línea parada. Por eso un buen programa no es solo el que funciona, sino el que cualquier técnico entiende y puede diagnosticar rápido. La diferencia entre un buen programador y uno malo casi nunca está en saber instrucciones raras: está en el orden, los nombres, las alarmas y el respeto por quien vendrá después.

Lo que distingue a uno de otro

Estructura: cada cosa en su sitio

El OB1 debería leerse como un índice: llama a los bloques de cada parte de la máquina en un orden lógico. Una estructura habitual:

• Bloques por estación o por función: quien busca un fallo en la estación de pinzado sabe dónde mirar.
• Un bloque por tipo de equipo: un FB «Motor» con su marcha, su paro, su térmico y sus alarmas, llamado una vez por cada motor. Si se mejora, se mejoran todos.
• Secuencias con etapas: cada paso de la máquina es una etapa numerada, con su condición para avanzar. La etapa actual se muestra en la pantalla y el operario o el técnico ven al momento en qué paso se ha quedado la máquina.

Nombres y comentarios

Un nombre bien puesto ahorra un comentario. Reglas sencillas que funcionan:

• Decir qué es y dónde: Cinta2_Sensor_Entrada mejor que S12.
• Para estados lógicos, un nombre que responda sí o no: Pinza_Cerrada, Puerta_Cerrada.
• Poner las unidades en las magnitudes: Presion_bar, Tiempo_Soplado_ms.
• Ser consistente: el mismo idioma y el mismo estilo en todo el programa.

Los comentarios deben explicar el porqué, no repetir lo que ya se ve. «Activa la salida» no aporta nada; «Se espera 500 ms para que la pinza termine de cerrar antes de subir» sí.

Alarmas que ayudan

La alarma es lo primero que ve el técnico cuando la máquina se para. Una buena alarma dice qué ha pasado, dónde y qué revisar: «Pinza estación 2 no llega a cerrada en 2 s: revisar sensor B23 y presión de aire».

La herramienta clave es la supervisión de movimientos: cada vez que se manda un movimiento, un temporizador comprueba que el sensor de final llega a tiempo. Si no llega, salta una alarma concreta en vez de quedarse la máquina esperando sin explicación:

// La pinza debe cerrar en menos de 2 s
#T_Cierre(IN := "Pinza_Cerrar" AND NOT "Pinza_Cerrada", PT := T#2s);
IF #T_Cierre.Q THEN
    "Alarma_Pinza_No_Cierra" := TRUE;
END_IF;

También ayuda registrar cuál fue la primera alarma: cuando falla algo, suelen saltar otras detrás, y la que importa es la primera.

Parámetros sin números mágicos

Un «3000» en mitad del programa no dice nada: ¿milisegundos?, ¿piezas?, ¿revoluciones? Los tiempos, consignas y límites van en un bloque de datos de parámetros, con nombre, unidades y comentario. Así se ajustan en un solo sitio, incluso desde la pantalla, sin tocar la lógica.

Modos de funcionamiento y arranque

• Modos claros: manual (cada movimiento por separado, con sus condiciones de seguridad lógica) y automático (la secuencia completa). Cambiar de modo debe ser seguro y predecible.
• Posición de inicio: antes de arrancar en automático, la máquina comprueba que está en su posición de reposo, o la lleva a ella con un ciclo de referencia.
• Tras un corte de tensión, la máquina no arranca sola. El arranque es siempre una acción voluntaria del operario.
• La seguridad no depende del programa normal: setas, puertas y barreras se gestionan con circuitos o PLC de seguridad. El programa estándar las vigila para mostrar mensajes y parar de forma ordenada, pero no las sustituye.

Respetar el ciclo de scan

Un buen programador no espera dentro de bucles, no escribe la misma salida en dos sitios, usa flancos donde hacen falta y da a cada temporizador y cada flanco su propia memoria. Son los errores que ya viste en el tema del ciclo de scan, y son los que más tiempo hacen perder en puesta en marcha.

Versiones y cambios

• Guardar una copia del proyecto antes de cada cambio y después, con fecha y una descripción de qué se ha cambiado y por qué.
• Los cambios en línea con la máquina funcionando se hacen con cuidado, se prueban y se apuntan. El «lo dejo así de momento» acaba siendo definitivo.
• Antes de tocar nada, comparar el programa del PLC con el del ordenador: si no coinciden, alguien ha hecho cambios sin guardarlos en el proyecto.

Probar antes de llegar a la máquina

Con un simulador de PLC, como PLCSIM en el caso de Siemens, se puede probar buena parte de la lógica en la oficina: secuencias, alarmas y casos de fallo. Cada error que se encuentra en la oficina es una hora menos de máquina parada en la puesta en marcha.

Errores que delatan a un mal programador

• Variables sin nombre o con nombres que no dicen nada.
• Una sola alarma de «fallo general».
• Movimientos sin supervisión de tiempo: la máquina se queda parada sin decir por qué.
• Código copiado y pegado para cada equipo, con pequeñas diferencias que nadie recuerda.
• Números mágicos repartidos por el programa.
• Seguridades resueltas solo con el programa normal.
• Cambios sin copia ni registro.

Resumen

• Un programa se escribe para que otro lo entienda y lo diagnostique rápido.
• Estructura por funciones y estaciones; bloques reutilizables con una instancia por equipo.
• Nombres que dicen qué es cada cosa, con unidades; comentarios que explican el porqué.
• Alarmas concretas, con supervisión de tiempo de cada movimiento.
• Parámetros con nombre en un bloque de datos, no números sueltos.
• Copias y registro de cada cambio, y pruebas en simulación antes de la puesta en marcha.

Pon a prueba lo que has aprendido

34 preguntas prácticas con su explicación. Sin registro y gratis.

Empezar el test