El PLC no siempre es el culpable

"¡Debe ser el Programa!": Por Qué el PLC No Siempre es el Culpable (Y Cómo Diagnosticar Averías de Verdad)

Introducción

Hay una ley no escrita en el mundo del mantenimiento industrial: cuando una máquina se para, la primera llamada es siempre para el programador. Se crea un corrillo alrededor del armario eléctrico, todas las miradas se clavan en ti y se oye la frase que todo especialista en automatización conoce demasiado bien: "Debe ser el programa. ¿Has tocado algo?".

Esta situación, aunque común, se basa en una premisa fundamentalmente errónea. El programa del PLC es la parte más estable y predecible de toda la máquina. Es un conjunto de reglas lógicas que no se desgastan, no se sobrecalientan y no se aflojan con la vibración.

En este artículo, vamos a desmitificar el rol del software en las averías. Explicaremos por qué la inmensa mayoría de los fallos son de naturaleza física (mecánica, eléctrica, neumática) y propondremos un método de diagnóstico estructurado que ayudará a todo el equipo de mantenimiento a encontrar la causa raíz más rápido, evitando culpas y fomentando la colaboración.

La Pirámide de las Averías: ¿Dónde Ocurren Realmente los Fallos?

Imagina una pirámide que representa la probabilidad de fallo de los componentes de una máquina. La realidad, basada en la experiencia de campo en un entorno de producción con desgaste físico, se parece mucho a esta representación inversa:

 

• Nivel 1 (La Base del Problema - 70%): Fallos Mecánicos y Neumáticos.
  • Son los componentes que sufren desgaste, fricción y fatiga. Son, con diferencia, la causa más común de paradas en la línea de producción.
  • Ejemplos: Un cilindro neumático que pierde aire y se mueve lento, una correa que patina, un rodamiento gripado, una pieza atascada, una boquilla de soplado obstruida.
• Nivel 2 (La Capa Intermedia - 20%): Fallos Eléctricos y de Sensórica.
  • Aquí entran los componentes que conectan el cerebro (PLC) con los músculos (actuadores). Están expuestos a vibraciones, suciedad y ciclos de trabajo intensos, siendo el punto de fallo más común después del desgaste mecánico.
  • Ejemplos: Un sensor inductivo sucio que no detecta, un cable cortado en una cadena portacables, un contacto de relé o contactor que se ha quedado pegado o no hace buen contacto, una fuente de alimentación que no da la tensión correcta.
• Nivel 3 (La Punta del Iceberg - 10%): Fallos de Software o Hardware del PLC.
  • Esta es la causa menos probable. Un programa no "se olvida" de una instrucción. Los fallos aquí suelen deberse a tres motivos:
    1. Modificación reciente: Se ha introducido un error en un cambio de programa (¡por eso son vitales los backups y las pruebas!).
    2. Fallo de hardware del PLC: La CPU, un módulo de E/S o la fuente de alimentación del autómata se ha dañado. Es raro, pero ocurre.
    3. Caso límite no previsto: La máquina entra en un estado que no se contempló en el diseño original del programa.

La conclusión es clara: 9 de cada 10 veces, el programa solo está haciendo su trabajo: detectar un fallo que ha ocurrido en el mundo físico.

El orden y porcentajes mostrados en este apartado son meramente representativos, el objetivo es mostrar una diferencia entre cada terminología, mostrando así que las averías no son siempre culpa del PLC. Dependiendo de cada escenario, el orden y porcentajes pueden variar considerablemente.

El Diagnóstico Estructurado: "Pregúntale al PLC, Él Sabe Qué Pasa"

En lugar de asumir que el programa es el culpable, debemos usarlo como nuestra principal herramienta de diagnóstico. El HMI y el software del PLC son los "ojos y oídos" de la máquina.

Aquí tienes un método en 3 pasos para que cualquier técnico pueda abordar una avería:

• Paso 1: Lee la Pantalla (HMI) y su Alarma. El primer reflejo no debe ser llamar al programador, sino leer el mensaje de alarma en la pantalla. Un buen programa te dirá exactamente qué está esperando o qué ha fallado.
  • Ejemplo: La alarma dice "Fallo Extensión Cilindro A (Timeout)". El programa te está diciendo: "He ordenado al cilindro A que salga, pero no he recibido la señal de su sensor de 'extendido' en el tiempo que esperaba".
• Paso 2: Verifica la Causa Física. Con la información concisa del HMI, el equipo mecánico o eléctrico ya sabe dónde mirar.
  • Siguiendo el ejemplo:
    • Mecánico/Neumático: ¿Llega aire al cilindro? ¿La electroválvula conmuta (se oye el "clic")? ¿Hay algo que atasque mecánicamente el cilindro?
    • Eléctrico: ¿Le llega tensión a la bobina de la electroválvula cuando el PLC se la ordena? ¿El sensor de "extendido" tiene alimentación? ¿Se ilumina el LED del sensor cuando el cilindro llega al final? ¿La señal del sensor llega correctamente al módulo de entradas del PLC?
• Paso 3: Solo si todo lo físico está bien, llama al Programador. Si después de revisar todos los elementos físicos la avería persiste, entonces y solo entonces es el momento de que el programador entre en acción para analizar la lógica en profundidad. Puede que haya un caso límite no contemplado o un problema de sincronización complejo.

El "Modo Provisional": Un Pacto entre Mantenimiento y Programación

A veces, una avería ocurre y no hay repuesto disponible. Un sensor se ha roto y el más cercano está a dos días de distancia. Aquí es donde la colaboración brilla.

El equipo de mantenimiento y el programador pueden acordar una modificación temporal en el programa para "puentear" esa condición y poder seguir produciendo de forma controlada (y segura). Por ejemplo, anular temporalmente la lectura de ese sensor.

Pero esto viene con un contrato no escrito:

1. Documentación Rigurosa: El programador debe dejar un comentario claro en el código (por ejemplo: // ¡OJO! SENSOR OP333-B4 PUENTEADO TEMPORALMENTE. ESPERANDO REPUESTO. 2025-09-10)
2. Registro de Trabajos: Mantenimiento debe abrir una orden de trabajo (OT) para reemplazar el sensor en cuanto llegue.
3. Compromiso de Restauración: Una vez que la reparación física se ha completado, es OBLIGATORIO avisar al programador para que restaure el programa a su estado original, eliminando el "puenteo".
   Saltarse este último paso es cómo se acumula la "deuda técnica" y se crean futuros problemas mucho más difíciles de diagnosticar.

Conclusión: Colaborar, no Culpar

El software de un PLC no es un ente misterioso y caprichoso. Es una herramienta lógica que, en la mayoría de los casos, nos dice fielmente lo que está mal en el mundo físico.

Fomentar una cultura en la que todo el equipo de mantenimiento aprenda a usar el HMI como primera línea de diagnóstico ahorra tiempo, reduce el estrés y dirige los recursos correctos al problema correcto. Dejemos de decir "debe ser el programa" y empecemos a preguntar "¿qué nos está diciendo el programa?". La respuesta, casi siempre, está ahí.

¿Eres programador y te sientes identificado? ¿Eres técnico de mantenimiento y tienes otra perspectiva? Me encantaría abrir un debate constructivo en los comentarios. ¡Compartamos experiencias para mejorar nuestros métodos de trabajo!