SEMAIQ · Automatización y PLC · Querétaro
Diagnosticar un programa de PLC sin documentacion: guia practica
1. Qué significa diagnosticar un programa sin documentación
Es el caso de un controlador con lógica cargada y funcionando donde nadie tiene el proyecto original: ni el archivo de ingeniería actualizado, ni el diagrama eléctrico corregido, ni los nombres de las variables. Ocurre en tres escenarios típicos: la máquina llegó usada de otra planta, el integrador original ya no existe o no entrega el archivo, y el ingeniero que programó se fue sin dejarlo en el servidor del cliente.
El programa es correcto para lo que la máquina hace hoy; el problema aparece cuando falla de forma intermitente o cuando producción pide un cambio de secuencia. En ese momento la única fuente de verdad es el binario del PLC, y por eso el orden importa: respaldo, mapa físico, lógica y captura del evento. Así se evitan los dos desastres clásicos: borrar un valor retentivo que el arranque necesita y entregar la máquina con bits forzados.
2. Antes de tocar nada: respaldo del programa y del proyecto
El primer paso es subir el programa del controlador a una computadora de ingeniería. En TIA Portal se sube la estación completa o el software del dispositivo; en Studio 5000 se hace Upload del controlador y se guarda con la opción de subir también los valores actuales de las etiquetas. La diferencia importa: si guardas sin subir los valores, el proyecto offline queda con los valores iniciales y un download posterior puede reinicializar la máquina.
El segundo movimiento es la comparación online/offline. En TIA Portal se compara por sumas de verificación de los bloques y requiere nivel de acceso de lectura o acceso total al CPU: con solo el nivel de HMI no se muestra el estado de comparación, aunque la conexión se establezca. Si el CPU tiene protección de lectura y no tienes la contraseña, podrás conectarte pero no comparar, y eso cambia toda la estrategia. En Studio 5000 se compara el archivo offline contra el controlador y conviene revisar el orden de tareas, porque una tarea periódica mal configurada explica muchas intermitencias.
Guarda dos copias en medios distintos y registra en la bitácora el modelo y firmware del CPU y de cada módulo, el número de serie, si el programa vive en tarjeta de memoria, la fecha, el responsable, el nivel de acceso obtenido y si hay bloques protegidos con know-how.
3. Ingeniería inversa del mapa de entradas y salidas
El mapa de E/S es el cimiento del diagnóstico y se construye cruzando tres fuentes: la dirección lógica de cada punto en el programa, el diagrama eléctrico aunque esté viejo, y la realidad física en los borneros del tablero. El diagrama suele traer correcciones a mano que nadie actualizó, así que se usa como hipótesis, no como verdad.
El método que funciona en planta es por módulo y por canal. Para cada entrada se documenta la dirección (por ejemplo I0.0), el estado del LED, el dispositivo conectado y la bornera donde llega; para cada salida, lo mismo con electroválvulas, contactores, variadores y señales al HMI. Cuando una entrada no responde se mide en el borne con la máquina en manual: si el sensor conmuta y el PLC no lo ve, el problema está en el cableado, la fuente o el módulo; si el PLC lo ve y la secuencia no avanza, el problema es de lógica.
Aquí también se renombran variables: primero en la copia de trabajo hasta que la secuencia sea legible, luego se valida cada nombre en la máquina y solo al final se cargan cambios. Toda variable que siga sin nombre se marca como pendiente; no se le inventa función.
4. Referencia cruzada: quién escribe y quién lee cada variable
La referencia cruzada es la herramienta más subestimada del diagnóstico. En Studio 5000 se abre con Ctrl+E sobre cualquier etiqueta y se filtra por escritura para ver todos los lugares que la modifican, con salto directo al renglón; en TIA Portal se consulta la información de referencias cruzadas por variable o por bloque, viendo escrituras y lecturas.
Ahí aparecen las causas típicas de una falla que no se reproduce: una misma bobina escrita desde dos rutinas, una rutina de recuperación de fallas que activa un arranque cuando cierta condición se cumple, un temporizador reutilizado en dos pasos, o un bit que el HMI escribe cada vez que refresca pantalla. También aparecen variables que no se usan en ninguna parte: restos de versiones anteriores.
Dos advertencias. Si una variable se escribe por direccionamiento indirecto, del tipo array[indice], la referencia cruzada no la muestra de forma individual: hay que buscar el nombre del arreglo completo. Y si el proyecto se editó mucho después de generarse, conviene reconstruir la base de referencias con la verificación del proyecto antes de confiar en que no hay más escrituras.
5. Tablas de observación y trace: capturar la falla intermitente
Una falla intermitente no se diagnostica mirando la pantalla del HMI: se diagnostica capturando el evento. Hay tres niveles y conviene usarlos en ese orden:
- Tabla de observación o monitorización: agrupa las variables del paso que falla y sigue su estado en tiempo real. Sirve para entender la secuencia, no para ver un pulso de un solo ciclo de scan.
- Trace o trend: graba variables con un tiempo de muestreo menor al ciclo de scan, con disparo por flanco, condición o umbral. Es la única forma de ver un pulso de milisegundos, un rebote de contacto o dos eventos que se cruzan en orden equivocado.
- Búfer de diagnóstico del controlador: registra los eventos con fecha y hora, del más reciente al más antiguo: arranques y paros, transición a STOP, fallas de módulo, errores de comunicación y diagnóstico del sistema.
El búfer de diagnóstico es la bitácora oficial del controlador y contesta lo que nadie en piso puede: ¿se detuvo por una falla del programa o porque el CPU perdió un módulo?, ¿a qué hora exacta fue el último paro?, ¿se repite a la misma hora del turno o después de cierto número de ciclos? En Studio 5000 el equivalente son las fallas mayores y menores del controlador y su registro de eventos. Exporta esa lista y crúzala con el estado de la planta: muchas intermitencias dejan de ser misteriosas.
Si el evento involucra comunicación entre controladores, robots o variadores, revisa también el enlace y la configuración de los protocolos de comunicacion industrial como PROFINET o EtherNet/IP: una pérdida momentánea de paquetes detiene una secuencia sin dejar rastro en el programa.
6. Tabla de diagnóstico: síntoma, herramienta y causa típica
Este es el cruce que más se repite en máquinas sin documentación. Úsalo como punto de partida, no como receta: confirma siempre con medición antes de cambiar lógica.
| Síntoma | Herramienta de diagnóstico | Causa típica |
|---|---|---|
| La máquina arranca sola | Referencia cruzada filtrando por escritura; trace sobre el bit de arranque | Dos rutinas escriben el mismo comando; la rutina de recuperación de fallas activa el arranque |
| Se detiene sin mensaje en el HMI | Búfer de diagnóstico; fallas del controlador | Falla de módulo de E/S, pérdida de comunicación o transición a STOP del CPU |
| Se detiene de forma aleatoria | Trace con disparo por flanco sobre el paso que falla | Rebote de contacto, sensor al límite de su distancia de conmutación o ruido de un variador |
| Un paso nunca avanza | Tabla de observación y referencia cruzada del paso | Temporizador reutilizado, interbloqueo mal ajustado o entrada que el PLC no lee |
| El conteo o la receta se pierde | Revisión de retentivos y del último download | Download completo que reinicializó valores, o variable sin marcar como retentiva |
| Salida activa sin comando visible | Referencia cruzada de la salida; verificar bits forzados | Salida forzada y olvidada, o doble bobina sobre la misma salida |
| Se pierden datos del HMI o del robot | Diagnóstico de red y contadores de error del puerto | IP duplicada, switch saturado o terminación incorrecta |
7. Falla eléctrica o falla lógica: cómo distinguirlas
Mucho del tiempo perdido en un diagnóstico se va buscando en el programa un problema que está en el cable. La regla es seguir la señal desde el dispositivo hasta el programa y de regreso:
- Sospecha eléctrica: el dispositivo conmuta en el borne y el PLC no lo refleja; el LED del módulo no enciende aunque llegue tensión; el valor del sensor fluctúa sin que la máquina se mueva; la falla aparece con la máquina caliente o con humedad.
- Sospecha lógica: el PLC ve la señal en la tabla de observación pero la salida no actúa; el paso avanza solo en cierto modo; la falla depende del orden en que el operador acciona los botones; coincide con un mensaje del HMI.
Cuando es lógica suelen ser cuatro familias: condición de carrera entre tareas o rutinas que se pisan, temporizador ajustado demasiado cerca del tiempo real del movimiento, interbloqueo mal negado en alguna edición previa, y banderas retentivas que quedaron en uno de una ejecución anterior. Cuando es eléctrica, lo habitual es contacto sucio, bornera floja, cable con fibra rota, fuente de 24 V con caída en el arranque, sensor al límite de rango o interferencia de un variador sobre la señal del encoder.
Si la máquina tiene funciones de seguridad, el diagnóstico no se detiene en el PLC estándar: paros de emergencia, guardas y cortinas se ejecutan con elementos certificados y su lógica se revisa aparte. Intervenir la parte estándar sin entender la parte de seguridad es la forma más rápida de dejar una máquina que produce pero no protege.
8. Errores comunes y checklist de trabajo
Antes de cerrar la intervención, verifica esta lista:
- Respaldo subido, fechado y guardado en dos medios.
- Comparación online/offline documentada, con los bloques diferentes.
- Mapa de entradas y salidas por módulo, canal y bornera.
- Nombres y comentarios cargados, con las variables sin identificar marcadas como pendientes.
- Lista de temporizadores, contadores y banderas retentivas con su función real.
- Ningún bit forzado activo al entregar la máquina.
- Diagrama eléctrico corregido y bitácora de eventos con los tiempos medidos.
9. Caso práctico: celda de maquinado con paro aleatorio
Situación (caso representativo): una planta de autopartes del Bajío opera una celda de maquinado con dos estaciones, carga manual y descarga por robot. La máquina se detenía de dos a cinco veces por turno sin mensaje claro en el HMI y el operador reiniciaba la secuencia. El proyecto original nunca se entregó, el diagrama eléctrico tenía correcciones a mano y las variables del programa no tenían nombre.
Diagnóstico: se subió el programa completo y se guardó con los valores actuales de las etiquetas. La comparación online/offline confirmó que el archivo del servidor era de una versión anterior, así que se trabajó sobre el binario del CPU. Al construir la referencia cruzada aparecieron dos rutinas escribiendo el mismo comando de ciclo: la secuencia principal y una rutina de recuperación de fallas que se activaba con un temporizador de vigilancia. El búfer de diagnóstico mostró que los paros coincidían con el tiempo muerto por cambio de pieza, y un trace sobre el paso afectado capturó el cruce de señales.
Solución: se documentó el mapa de E/S, se renombraron las variables del paso y de los sensores involucrados y se corrigió la condición de la rutina de recuperación para que solo interviniera con el ciclo detenido y la guarda cerrada. El cambio se cargó bloque por bloque, en paro programado y conservando los valores retentivos de posiciones y contadores.
- Cero paros aleatorios por cruce de rutinas en las cuatro semanas posteriores.
- Diagnóstico de fallas siguientes en minutos, no horas, porque el mapa de E/S ya existía.
- Más del 90% de las variables del paso crítico con nombre legible.
- Diagrama eléctrico actualizado y firmware registrado para el siguiente mantenimiento.
Recuperar la lógica de una máquina existente es la otra cara de la refurbish y retrofit de maquinaria industrial: antes de modernizar hay que entender qué hace el control actual, y para eso sirve todo lo que se documenta durante el diagnóstico. En celdas con robot ese esfuerzo se repite en el intercambio de señales, así que conviene revisar la integracion de robots industriales con PLC desde el arranque del proyecto.
Preguntas frecuentes
Se puede diagnosticar un programa de PLC sin documentacion sin detener la produccion?
En la mayoria de los casos, si. Subir el programa, comparar online/offline, construir el mapa de entradas y salidas y revisar referencias cruzadas se hace con la maquina en marcha. La intervencion sobre el programa se hace en un respaldo y en paro programado, porque forzar salidas en linea sobre una maquina que produce es un riesgo de seguridad.
Cuanto tarda el diagnostico de un PLC sin documentacion?
Depende del tamano del programa y de cuantas variables esten sin comentario. Un controlador de celda con 300 a 800 variables se mapea en uno o dos dias. Una maquina con varias estaciones, comunicacion entre controladores y logica heredada puede tomar una semana o mas.
Es seguro forzar bits en el PLC para que la maquina arranque?
No como metodo de diagnostico. Forzar una salida puentea interbloqueos y protecciones, y la maquina puede moverse con una guarda abierta o con una persona en la zona. El forzado solo es valido en modo manual, con la maquina en estado seguro, vigilado, por el menor tiempo posible y retirado antes de devolver el equipo a produccion.
Como capturo una falla intermitente que no se reproduce cuando estoy frente a la maquina?
Con captura automatica. Deja activado el bufer de diagnostico del controlador, que registra cada evento con fecha y hora, y configura un trace o trend con disparo por flanco sobre las variables sospechosas y muestreo menor al ciclo de scan. Asi el evento queda grabado aunque sea de madrugada.
Que se debe documentar durante el diagnostico para no volver a empezar?
El binario subido con fecha y firmware, el mapa de entradas y salidas por modulo y bornera, los nombres y comentarios identificados, los temporizadores y banderas retentivas con su funcion, los interbloqueos criticos, el diagrama electrico corregido y la bitacora de eventos.
