La puesta en marcha tiene un olor. Gabinetes eléctricos calientes, polvo de cartón, café frío a las 2 a.m. Y tiene un sonido que he aprendido a temer: silencio en una línea de transportadores que debería estar moviéndose.
La semana pasada estuve en un arranque en el Inland Empire — un 3PL de 80,000 pies cuadrados que maneja devoluciones de ropa, con un nuevo WCS conectándose a un sistema de control de transportadores ya existente. Una tarima quedó muerta en un desvío. El monitor del WCS decía, en letras verdes brillantes, "RELEASED". El ingeniero de control junto al gabinete del PLC miraba sus luces de E/S y dijo: "Nunca recibimos la liberación".
Perdimos dos días por esa tarima. La causa raíz era casi vergonzosa: el programador del WCS trabajaba con la revisión 7 de la tabla de señales. El PLC en campo corría la revisión 9. En el camino, el equipo de sitio había vuelto a cablear dos veces y agregado dos fotoeléctricos, y nadie actualizó la tabla. La solicitud de liberación cayó en una dirección libre que no significaba nada para el programa del PLC. Nadie escuchaba en ese canal.
En veinte años he visto esta película una docena de veces. El hardware está bien. Ambos paquetes de software están bien. Lo que mata la integración es el documento intermedio — la tabla de señales de E/S. Así construyo una que no vuelve para atormentarme.
Clasifique cada señal en tres cubetas antes de abrir Excel
El error de principiante es abrir una hoja de cálculo y escribir fila tras fila hasta tener cien señales sin idea de qué hace la mitad. Yo clasifico primero, luego listo.
Cubeta uno: comandos, del WCS al PLC. Arranque, paro, liberación, reset, cambio de modo. Un comando que no necesita respuesta es un comando que elimino — si el PLC no tiene que responder, no tiene nada con qué diagnosticar cuando algo sale mal a la medianoche.
Cubeta dos: estados, del PLC al WCS. En posición, en marcha, en falla, paro de emergencia, modo manual/automático. Los estados son de solo lectura. El WCS mira; nunca escribe. Muchos proyectos mueren aquí mismo, cuando un programador de WCS toma un atajo y escribe directamente en un bit de estado que pertenece al PLC. Dos escritores, un bit, señales parpadeando en la puesta en marcha, y el error resulta ser fuego amigo.
Cubeta tres: latido (heartbeat). El WCS conmuta un bit cada uno o dos segundos; el PLC conmuta uno de vuelta. Cada lado vigila el pulso del otro y dispara una alarma cuando se detiene. Este es el seguro más barato de toda la tabla, y el que más a menudo se recorta por ahorro. El argumento siempre es el mismo: "el switch de red alarmará si se cae el enlace". Una alarma del switch le dice que el cable está caído. Un latido le dice si la máquina del otro extremo está viva, muerta o muerta en vida con su programa colgado. Son hechos diferentes, y a las 2 a.m. la diferencia importa.
Tome "liberar una tarima" como ejemplo. Necesita exactamente cuatro señales: solicitud de liberación (WCS a PLC), solicitud recibida (PLC a WCS), liberación completada (PLC a WCS), más el latido. Cuatro señales, un trabajo, propiedad cristalina. Cualquier fila de la tabla que no pueda responder "para qué es esto, quién la escribe, quién la lee" se elimina. Una tabla de señales no es mejor cuando es más larga. Cada señal sin mantenimiento es un sospechoso más cuando la puesta en marcha se tuerce.
El handshake de tres pasos, y por qué dos pasos lo quemarán
Mi diagrama de tiempos tiene tres pasos y en esto no negocio. El WCS activa "solicitud de liberación". El PLC la ve y activa "solicitud recibida". El PLC ejecuta la liberación, la tarima llega, y el PLC activa "liberación completada". El WCS ve "completada" y desactiva "solicitud". El PLC ve que "solicitud" desaparece y desactiva "completada". Círculo completo, de vuelta a un estado de reposo limpio.
¿Por qué tres pasos? Porque personalmente ya pagué por ambos atajos. Atajo uno: el WCS dispara y olvida. La solicitud sale, el PLC la pierde en un rebote de señal, la tarima nunca se libera — pero el WCS cree que sí y despacha la siguiente tarea. Toda la línea se atasca. Atajo dos: el PLC actúa pero nunca informa. La liberación ocurrió, el WCS no lo sabe, se agota el tiempo y reenvía la solicitud, y la misma tarima se libera dos veces. El desvío río abajo se convierte en un derby de demolición.
El sentido del handshake de tres pasos es un lazo cerrado: nada avanza hasta que el paso anterior se confirma, y nada se reinicia hasta que el reinicio se ve. Hay un beneficio del que nadie habla. Si cualquiera de los lados pierde la red o se cuelga, el handshake se congela a mitad de paso — de forma visible, ruidosa, con una alarma. Congelado está bien. Lo que lo mata es la falla silenciosa, la que descubre tres tarimas después cuando el daño ya está hecho.
La lista de verificación previa a la puesta en marcha que corro en cada sitio
Tabla lista, código escrito — no pase aún a la integración de línea completa. Corra primero estas pruebas de un solo elemento. Ahorran aproximadamente la mitad de las lágrimas en la noche de la puesta en marcha.
Anti-rebote primero. Los fotoeléctricos y los interruptores de proximidad rebotan en el borde mecánico. Unas pocas decenas de milisegundos de anti-rebote de entrada en el programa del PLC son la apuesta mínima. Y el lado del WCS tampoco debería confiar en una sola lectura — exija dos lecturas consecutivas antes de aceptar un cambio de estado. El rebote es invisible en las pruebas y aparece exactamente cuando el volumen pica.
Audite las direcciones. Tome la tabla y verifique cada señal contra la dirección real en el programa del PLC, una por una. El recableado en campo y las adiciones de último minuto ocurren en cada proyecto; la revisión de la tabla y la del programa deben coincidir. Mi regla ahora: la tabla lleva un número de revisión, y ese número aparece tanto en los comentarios del programa del PLC como en la configuración del WCS. El desastre de revisión-7-contra-9 de mi historia inicial es exactamente lo que esto evita.
Jale el cable. Desconecte un cable de red y cronometre cuánto tarda el WCS en notar que el PLC se fue — esa es su prueba de latido. Accione el paro de emergencia y verifique que el estado de "paro de emergencia" que ve el WCS coincida con lo que la máquina realmente hizo. Un principio aquí: el circuito de paro de emergencia en sí corre sobre relés de seguridad cableados. El "estado de paro de emergencia" enviado al WCS es solo un espejo. Nunca cuelgue una función de seguridad de una señal de software.
Pruebe la señal de modo. Cuando el PLC pasa a manual, el WCS debe saberlo — y debe dejar de despachar tareas. Una vez vi a un WCS seguir enviando liberaciones mientras un técnico movía el transportador a mano. Una tarima fue empujada por un comando de liberación que nadie esperaba. Nadie salió herido, pero fue suerte, no diseño. El modo es un tema de seguridad, no una opción.
Luego déjelo remojar. Dos horas de operación continua, con un paro de emergencia aleatorio, una caída de red aleatoria y una intervención manual aleatoria en el camino. El tiempo de puesta en marcha es el tiempo más caro del proyecto. Ensayar las fallas es mejor que interpretarlas frente al cliente.
Si mañana entra a un sitio de puesta en marcha, lleve una cosa: una tabla de señales impresa, firmada por ambos lados, con el número de revisión igual al del código. Solo eso bloquea la mitad de los modos de falla. La lista de arriba maneja el resto, un elemento a la vez.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
