Reparación o sustitución de un PLC: qué pruebas ayudan a decidir

La máquina está parada, alguien pide un presupuesto para reparar o sustituir un PLC (autómata programable industrial), y la tentación es describir la avería de memoria. Resístela. Escribe qué hizo la máquina antes de pararse: qué LED estaban activos en la CPU, qué códigos de error aparecieron y si la avería se repite tras un rearranque controlado. Un síntoma sin fecha ni fuente es un relato, y una valoración de reparación construida sobre relatos produce presupuestos para la avería equivocada.

Esquema del sistema ampliado

×

Tres observaciones hacen usable un síntoma. La fecha es lo que permite siquiera comparar dos incidentes.

Anota qué se ha probado ya y qué cambió como resultado. Un ciclo de alimentación que despejó la avería durante dos horas, un sensor sustituido que no tuvo efecto, un cable reconectado antes del paro: son datos que orientan un diagnóstico. Sin ese historial, un taller de reparación repite los mismos pasos y factura el privilegio, mientras que una decisión de sustitución se toma con información incompleta.

Las fotografías de los estados de los LED en el momento del fallo cuentan como observación y sobreviven mejor que las descripciones. Una marca de tiempo en la nota es lo que la hace comparable después, porque dos incidentes descritos igual pueden ser averías distintas cuando se comparan fechas y condiciones. Una foto hecha en el primer minuto del paro sobrevive a todo recuerdo de ella.

Una precaución acompaña a la recogida de síntomas. Las observaciones que vienen de operar la máquina, como ver qué LED están activos en el momento del fallo, son seguras de registrar. Las intervenciones que cambian el estado de la máquina, como un rearranque o una reconexión, pertenecen al procedimiento propio de la planta y a su condición segura. Registra qué se hizo y cuándo, y deja el hacer a las personas y al proceso responsables.

Mantén el registro de síntomas factual y libre de conclusiones. Una nota que dice LED de alimentación apagado, SF activo, ocurrido dos veces esta semana tras el arranque de línea es prueba utilizable. Una nota que dice la CPU probablemente está muerta es una conclusión, y puede cerrar una ruta más barata antes de que nadie haya mirado la unidad.

Esquema del sistema ampliado

×

Dos clases de contenido llegan al registro. Solo la parte observada tiene peso hasta que alguien la verifica.

La disciplina es la misma que mantiene honesta cualquier prueba: separa lo que viste de lo que crees que significa. La observación pertenece al registro. La interpretación pertenece a una nota claramente marcada, si pertenece a algún sitio, porque un revisor necesita saber qué parte le piden verificar.

La misma separación decide cómo se usa el registro después. Un registro factual se puede entregar a un tasador de reparación, citar en una revisión de sustitución y reutilizar para la siguiente avería. Un registro de conclusiones solo se puede discutir. Mantenlo factual, y el registro trabaja durante años.

Una CPU lleva el programa, la identidad de red y el ajuste fino de la máquina, y el trabajo de recuperación difiere por completo según ese contenido esté respaldado o no. Si existe una copia de seguridad del proyecto verificada, una sustitución se convierte en una tarea de restauración: cargar el proyecto, restaurar el nombre de dispositivo y el direccionamiento, y verificar los dispositivos conectados. Si no existe copia, una sustitución significa reconstruir el programa desde la documentación o desde la unidad averiada.

Esquema del sistema ampliado

×

Un dato, copia verificada o no, cambia el coste de toda la ruta. Las flechas muestran los dos caminos de coste.

Son proyectos distintos en escala y en coste, y la distancia se mide en semanas de tiempo de ingeniería, no en el precio de la unidad. El precio de la unidad rara vez es donde vive el coste real. Un presupuesto que parece caro junto a una sustitución barata puede ser la ruta más barata una vez contada la reconstrucción, y solo el estado de copia registrado lo expone. Una copia que se abre es un dato; una copia que se asume que se abre es el riesgo que el registro existe para retirar.

Verifica la copia en lugar de fiarte de su existencia. Un archivo que se abre en el software de ingeniería y coincide con la versión de programa de la CPU en marcha es una copia verificada. Un archivo de edad desconocida en un disco compartido no lo es. El paso de verificación es rápido mientras la máquina funciona, y decide qué ruta es realista mucho antes de que alguien pida un presupuesto.

El ajuste fino de la máquina es la parte silenciosa de la pregunta de la copia. Más allá del programa, una CPU puede llevar parámetros ajustados durante la puesta en marcha y nunca escritos en ningún otro sitio. Si el estado de la copia es desconocido, la pregunta del ajuste lo es con él, y esa incertidumbre pertenece al registro junto al estado de la copia. Cambia el valor de una unidad recuperada tanto como el programa.

Para una pista de reparación, reúne la referencia completa con su revisión, el historial de averías fechado y fotos nítidas de la unidad incluida su etiqueta. La valoración de reparación vive de los síntomas y del estado de la unidad, así que ese conjunto es el núcleo. Añade si la unidad se abrió o se modificó, porque las intervenciones sin registrar cambian lo que un taller puede concluir de una inspección. Los detalles que parecen menores en el banco a menudo deciden la valoración.

Esquema del sistema ampliado

×

Las dos rutas parten del mismo registro y se ramifican hacia la prueba que cada valoración sopesa de verdad.

Para una sustitución, añade el contexto de red y de proyecto para que un sucesor o una unidad equivalente se pueda comprobar como es debido. El conjunto relevante incluye el nombre de dispositivo, el direccionamiento, la lista de dispositivos conectados y el estado de copia verificado. La ruta de sustitución la deciden las pruebas de configuración más que las de avería. Una unidad equivalente sin su contexto de red sigue siendo una suposición.

Por eso las dos rutas tiran de partes distintas del mismo registro. Construye ambos conjuntos de pruebas desde un registro de síntomas factual y un estado de copia verificado, y cada ruta recibe lo que necesita sin repetir el trabajo. Decir qué intervenciones se registraron y cuáles no es en sí mismo prueba útil para el tasador.

Las intervenciones sin registrar merecen una línea propia en ambos conjuntos de pruebas. Una unidad que se abrió, un módulo que se intercambió entre racks, una borna que se rebornó durante una avería anterior: cada una de estas cosas cambia lo que un tasador puede concluir y lo que una comprobación de sustitución debería verificar. Registrarlas no es admitir una culpa; es la diferencia entre una inspección que parte de datos y una que parte de sorpresas.

La tolerancia al paro también pertenece al paquete. Declara cuánto puede esperar la máquina, si existe una solución provisional temporal y quién posee la decisión. La urgencia es un dato del negocio, y registrarla deja que las pruebas, y no la presión del momento, decidan qué ruta se confirma con las personas responsables de la máquina.

Esquema del sistema ampliado

×

Tres entradas, una comparación. La tolerancia y el responsable mantienen la urgencia dentro del registro en lugar de dentro de la decisión.

Una oferta de intercambio y un presupuesto de reparación responden a preguntas distintas. El intercambio responde a qué velocidad vuelve a funcionar la máquina; la reparación responde a qué le pasó a la unidad y cuánto vale una restaurada. El paquete evita que las dos se comparen solo por precio, porque el precio a solas es a lo que recurre una decisión bajo presión.

El registro hace posible esa comparación meses después. Una decisión tomada bajo presión de paro, con la tolerancia declarada y las pruebas adjuntas, se puede revisar y de la que se puede aprender. Una decisión tomada sin el registro solo se puede lamentar o repetir. La comparación, no la elección, es para lo que sirven las pruebas.

Una solución provisional cambia la aritmética y debe registrarse como dato. Si la línea puede funcionar con una máquina hermana, o en un modo reducido, la tolerancia al paro es otra cifra distinta a la de un paro total, y las rutas se pueden pesar contra el plazo real. Declara la solución provisional, sus límites y cuánto puede aguantar. Las soluciones que se asume que aguantan indefinidamente son donde los planes fallan en silencio.

• Registra síntomas fechados y concretos, y cada intervención previa, antes de pedir cualquier cosa.
• Verifica que la copia de seguridad del proyecto se abre y coincide con la versión del programa en marcha.
• Construye las pruebas de reparación desde los síntomas y las fotos, y las de sustitución desde el contexto de red y de proyecto.
• Declara la tolerancia al paro para que la comparación sea honesta con la urgencia.

• la página de la categoría CPU de PLC
• qué registrar antes de una recuperación fail-safe
• qué enviar con una solicitud de reparación