Mantener el orden, segmentar los problemas grandes en problemas más pequeños, separar el código en bloques, añadir comentarios y gestionar versiones no son técnicas obligatorias de trabajo, pero hacen la diferencia como el día y la noche, especialmente cuando estamos frente a un tablero a contrarreloj. Son técnicas clave para llevar nuestro trabajo a término y ser excelentes profesionales.

Parece obvio, pero más de una vez estuvimos tentados en dejar ese "VAR0001" o "Tag_1" (ver figura 1). Darle nombre descriptivo a una variable o equipo nos ayudará a identificar problemas mucho más rápido. Esos veinte segundos adicionales que "perdemos" agregando comentarios o describiendo las variables serán mínimo media hora que nuestro yo del futuro se ahorrará rascándose la nuca mientras trata de encontrar un problema en el código. Y nuestro yo del futuro nos lo agradecerá inmensamente.

Es muy común usar una variable siempre en 1 (‘AlwaysTrue’) o siempre en 0 (‘AlwaysFalse’) para forzar situaciones mientras estamos haciendo pruebas, ya sea para hacer bypass de un sensor o activar algo en cuestión.
El gran problema surge porque esos AlwaysTrue o AlwaysFalse también se usan para "ordenar" segmentos, y que el código pueda compilarse correctamente (ver figura 3).
Antes de retirarnos, hay que borrar todos los valores forzados para no interferir con el programa. Pero no todos, solamente aquellos que "saltean" segmentos, o dejamos solo para pruebas.
¿A qué me refiero con “interferir con el programa”? A que tendremos un gran problema si dejamos el bypass en las condiciones de seguridad, o dejamos algo permanentemente inactivo y nos retiramos a casa, a cientos de kilómetros del lugar donde programamos. ¡Nos iremos más rápido a casa y con la conciencia limpia si buscamos todas las referencias a una variable "TEST_BORRAR"!

Siempre que trabajemos en redes basadas en TCP/IP, nos tenemos que asegurar lo siguiente:

En primer lugar, un equipo en una subred distinta no comunicará, así que por más que hagamos ‘ping’ una y otra vez no vamos a tener respuesta alguna (y esto suele ser un verdadero dolor de cabeza).
Y por otro lado, dos equipos con la misma dirección de IP pueden causar fallas en la red. ¿El resultado? Uno o ambos equipos duplicados pueden perder conectividad con la red hasta que se resuelva el conflicto.
Ejemplifiquemos el problema: imagínense que están llegando alegremente a realizar sus tareas del día, una simple modificación en el comportamiento de una lamparita. Sacan la computadora, la encienden, enchufan el inocente cable Ethernet al switch del tablero y, de repente, un motor crítico para el proceso se frena, saltan alarmas por todos lados, la gente corre de acá para allá sin saber qué pasó. Y todo porque nuestra PC tenía la misma dirección de IP que la RTU que comandaba el proceso entero.
¿Moraleja? Por más simple que sea la tarea, o por más apurados que estén, nunca enchufen su PC a un proceso en funcionamiento, sin antes chequear dos veces su IP con todas las direcciones de los equipos instalados.
Y para quienes se lo estén preguntando: no, nunca me pasó ni me volverá a pasar...

A veces, puede suceder que los PLC tengan múltiples tarjetas de entradas y salidas. Algo muy común es que las alimentaciones de los módulos externos nos queden desconectadas o sueltas.
No siempre es intuitivo, y esto causa que tengamos señalizaciones erróneas o lecturas incompletas de los sensores de campo. Y muchas firmas de PLC no lo detectan como una falla porque el bus de comunicaciones con el módulo sí funciona.
Otra cosa con la que debemos tener cuidado es que los sensores analógicos también estén alimentados. Muchas tarjetas de entrada analógica no alimentan el sensor, especialmente si es de dos hilos. Para ello, tenemos algunas técnicas de cableado que nos pueden ayudar a alimentarlo y tener lectura (ver figura 5).
Verificar que todas las tarjetas y equipos están correctamente alimentados nos ahorrará problemas cuando hagamos las pruebas.

Los calibradores de lazo son equipos fantásticos para tener en nuestra caja de herramientas. Nos permiten inyectar señales estándares en las borneras de los tableros o de los PLC, y probar entradas analógicas o verificar las salidas. Vienen en miles de formas y tamaños, la más común es el formato "tester" con sus borneras o cocodrilos.
Antes de montar un tablero en sitio, probá todas las entradas y salidas del PLC inyectando señales digitales y analógicas. Incluso te podés apoyar en las tablas de observación de los equipos, e ir marcando con comentarios si está bien o si hay que revisar algo (ver figura 6).
Nos dejará más tranquilos llevar el tablero al sitio de montaje sabiendo que, de las borneras hacia adentro, llegan todas las señales correctamente. Y en este rubro, la tranquilidad y el alivio que trae eso es impagable.

Trabajar con PLC es una labor ardua, y es una actividad que demanda mucha lógica, como es de esperarse, pero también requiere creatividad y paciencia.
Y también es un trabajo extremadamente gratificante. Estar a pie de un equipo y ver cómo ejecuta las tareas exactamente como lo teníamos previsto es una sensación increíble.
Entender cómo la coreografía de señales que entran y salen del equipo trabajan en conjunto es una de las razones por las que elijo este trabajo una y otra vez. Como todo, lleva práctica y "horas-silla". Cada nuevo trabajo es como resolver un rompecabezas que nos desafía cada vez que empezamos un nuevo proyecto.
Así que, si llegaste hasta acá, ¡te agradezco muchísimo por leer! Espero que estos consejos te hayan servido.