Cuando un robot industrial se detiene sin razón aparente, el problema está casi siempre en uno de tres lugares: la señal entre robot y PLC, el programa del PLC, o un enclavamiento de seguridad que nadie revisó. Rara vez es el robot. Para saber cuál es, revisa el robot en manual sin el PLC, verifica el estado de las señales de habilitación, y confirma el protocolo de comunicación — PROFINET si el PLC es Siemens, EtherNet/IP si es Allen Bradley. El diagnóstico correcto toma minutos. Adivinar toma el turno completo.
El robot está parado. La luz del HMI dice "esperando". Tú dices una palabra que no vamos a escribir aquí. Y el operador te mira como si tú supieras qué hacer — porque, técnicamente, es tu trabajo saberlo.
Aquí va lo que nadie te dice a tiempo: el robot casi nunca es el culpable. El culpable suele estar en la conversación que el robot y el PLC ya no están teniendo. Y esa conversación cambia según si tu planta usa PLC Siemens o PLC Allen Bradley — no porque uno sea mejor, sino porque cada uno falla distinto.
Esto es lo que te explicaríamos en planta si estuviéramos parados frente a esa celda contigo. Sin teoría de manual. Con el diagnóstico que realmente usamos.
En este artículo:
Hay un momento muy específico en cualquier planta con robots: la línea se detiene, el robot está quieto, y las primeras tres personas que llegan dicen tres cosas distintas. "Es el robot." "Es el PLC." "Seguro alguien tocó algo." Nadie tiene razón todavía, porque nadie ha revisado nada.
(Este es el punto donde todos pensamos "seguro es algo sencillo". A veces lo es. A veces lleva tres horas porque nadie quiso revisar lo obvio primero.)
El robot industrial y el PLC que controla la celda tienen una relación de jerarquía simple: el robot ejecuta movimiento, el PLC decide cuándo puede hacerlo. Si esa comunicación se rompe — por una señal, un cable, un programa mal escrito o una condición de seguridad — el robot se queda exactamente donde está. Funcionando, pero esperando permiso que nunca llega.
La buena noticia: este tipo de falla tiene un patrón. No es magia negra, aunque a las 2 AM del tercer turno lo parezca.
Antes de tocar el programa, antes de llamar al integrador, antes de culpar al técnico del turno anterior — sigue este orden. Resuelve la mayoría de los casos sin abrir una sola línea de código.
(Sí, ya revisaste eso. Pero igual revísalo otra vez. El paro de emergencia que "obviamente está bien" es responsable de una cantidad vergonzosa de horas perdidas en plantas de todo México.)
Si tu planta corre PLC Siemens S7-1500 o equivalente, el protocolo de comunicación con el robot casi siempre es PROFINET. Es el estándar nativo de Siemens y la combinación más común con robots ABB en México, sobre todo en líneas de origen europeo.
Las fallas típicas de esta combinación tienen una firma reconocible:
Lo que ayuda en planta: el diagnóstico de PROFINET integrado en TIA Portal muestra el estado de cada dispositivo de la red en tiempo real. Antes de sospechar del robot, revisa ahí si el dispositivo aparece como "en línea" o como "falla de configuración".
Si tu planta corre PLC Allen Bradley ControlLogix o CompactLogix, el protocolo nativo es EtherNet/IP. Es la combinación más común con robots KUKA y FANUC en líneas de origen norteamericano, y también funciona sin problema con ABB.
Las fallas típicas aquí tienen su propia firma:
Studio 5000 tiene su propio panel de diagnóstico de E/S. Igual que con Siemens: antes de sospechar del robot, confirma que el módulo aparece sin falla de comunicación en el árbol de controlador.
La discusión genérica de "cuál PLC es mejor" ya está en internet por todos lados, y casi siempre habla de hardware, costo y facilidad de uso. Para integración con robots, lo que realmente cambia el diagnóstico y la decisión es esto (ambos protocolos están estandarizados por organismos internacionales — ODVA regula EtherNet/IP, y PROFIBUS & PROFINET International regula PROFINET):
| Factor | PLC Siemens | PLC Allen Bradley |
|---|---|---|
| Protocolo nativo | PROFINET | EtherNet/IP |
| Robot más común en la combinación | ABB | KUKA, FANUC |
| Software de programación | TIA Portal | Studio 5000 |
| Falla típica más común | Dirección IP o Data Block desincronizado | Tag sin mapear o módulo no agregado |
| Región donde domina en planta | Europa, Asia, plantas de origen alemán en México | Norteamérica, plantas de origen estadounidense en México |
| Edición de programa en línea sin detener proceso | Limitada según el caso | Más flexible |
La regla práctica que usamos en planta: el PLC correcto no es el que tiene mejor reputación en un foro. Es el que ya está instalado en tu planta, o el que coincide con el protocolo que tu robot soporta de fábrica sin hardware extra.
Hay un error que aparece una y otra vez en plantas que llevamos años visitando, y casi nadie lo dice en voz alta: nadie documentó la integración cuando se instaló.
El integrador que armó la celda hace tres años ya no trabaja ahí. El técnico que la mantenía se cambió de turno. Y ahora hay un robot y un PLC conversando en un idioma que nadie en la planta entiende completamente, porque el mapa de señales vive únicamente en la cabeza de alguien que ya no contesta el teléfono.
Si reconoces tu planta en este párrafo, el primer paso no es arreglar la falla de hoy. Es mapear las señales reales entre robot y PLC con el software de diagnóstico de cada marca, y dejarlo documentado — aunque sea en una hoja de cálculo simple. Sin ese mapa, cada corrección futura sigue siendo una apuesta.
Para ser honestos: no todo es señal ni programa. Antes de pasar horas revisando PROFINET o EtherNet/IP, descarta lo mecánico y lo eléctrico básico:
El manual dice una cosa. La realidad de planta dice otra: el diagnóstico empieza siempre de lo simple a lo complejo, no al revés.
Lo que acabas de leer es exactamente lo que enseñamos cuando capacitamos a un equipo de mantenimiento o automatización: no solo a programar el robot o configurar el PLC por separado, sino a leer la conversación entre ambos cuando algo se rompe.
En RoboTraining llevamos más de 10 años formando técnicos e ingenieros en programación de robots ABB, KUKA y FANUC, con integración a PLC Siemens y Allen Bradley, directamente en planta — con robots reales, fallas reales, y el mismo tipo de diagnóstico que acabas de leer aquí.
No porque seamos mágicos. Sino porque la metodología correcta — y el robot enfrente, no un simulador — hacen toda la diferencia entre alguien que conoce la teoría y alguien que resuelve la línea detenida en quince minutos.
Si quieres ver el panorama completo antes de entrar al diagnóstico fino, puedes leer nuestra guía de robótica industrial: qué es, tipos y aplicaciones, o conocer a fondo la integración y programación de robots ABB.
Lo diagnosticamos directo en planta. Sin relleno, sin teoría innecesaria — con el mismo proceso que acabas de leer, aplicado a tu celda real.
Llámanos y lo platicamos O llámanos directamente: 55 5668 6079Revisa primero el robot en modo manual, sin el PLC controlando la celda. Si se mueve bien por jog y no marca falla, el robot está sano y el problema vive en la señal, el programa del PLC o la comunicación entre ambos. Si el robot ya marca falla en manual, el problema es del robot o su controlador, no del PLC.
PROFINET es el protocolo nativo de Siemens y el más común en integraciones con robots ABB en México. EtherNet/IP es el protocolo nativo de Allen Bradley y domina en integraciones con KUKA y FANUC en líneas de origen norteamericano. Ambos cumplen la misma función — comunicar señales de E/S entre robot y PLC — pero no son intercambiables sin un gateway o módulo de comunicación adicional.
Sí. El controlador IRC5 de ABB soporta EtherNet/IP de fábrica, igual que soporta PROFINET. La combinación funciona, aunque es menos común que ABB con Siemens. Lo mismo aplica para KUKA o FANUC con Siemens: técnicamente es posible, solo hay que configurar el protocolo correcto desde el lado del robot.
Casi siempre es una señal de habilitación que el PLC no está mandando: falta de start, una puerta de seguridad abierta, un paro de emergencia sin restablecer, o una condición de enclavamiento en el programa del PLC que no se cumple. El robot está listo, pero el PLC no le da permiso de arrancar.
Primero, mapea las señales reales entre robot y PLC con el software de diagnóstico de cada marca antes de tocar el programa. Después, documenta lo que encuentres — direcciones de I/O, protocolo, nombres de señales — aunque sea en una hoja simple. Sin ese mapa, cualquier cambio que hagas es una apuesta, no una corrección.
Funciona técnicamente, pero tiene un costo de mantenimiento real: duplicas licencias de software, duplicas la curva de aprendizaje del equipo de mantenimiento y complicas el inventario de refacciones. Si ya tienes un PLC estandarizado en planta, lo más práctico es elegir el robot que se integre nativamente con ese protocolo.
RoboTraining llega a México para impulsar a estudiantes y profesionales de ingeniería en la Industria 4.0 y 5.0 Podrían surgir...
Al aplicar el uso de los robots en nuestros procesos de producción, buscamos minimizar costos de inversión y mano de...
Automatización y desplazamiento laboral La automatización es una tendencia que está transformando la forma en que trabajamos y vivimos, y...
