Diagnóstico Profinet — cuando el ciclo cae y el error no está en el PLC

El cliente manda screenshot del Diagnostics buffer de SIMATIC: «PROFINET IO: communication error 16#80B1, slot 3 module 2». El PLC recupera la comunicación en 200 ms, el ciclo pasa de milagro, pero los prediction-time empeoraron y el OEE cayó un 4 % respecto al mes pasado. Pregunta: ¿qué falla?

La respuesta que recibe de la mayoría de integradores: «revisar firmware PLC, posiblemente cambiar el módulo IO». Esa es la estrategia para perder 3 semanas y 4 000 € en horas de servicio sin encontrar la causa. El diagnóstico Profinet de verdad no se hace en TIA Portal — se hace en Wireshark, en topology view (LLDP) y en gestión de switches. Este artículo es el playbook para llegar a la causa en 2–4 horas en vez de 2–3 semanas.

Cuatro capas donde puede ocultarse el error

En problemas Profinet RT el 95 % de los errores está en alguna de estas capas:

1. 1.Capa física — cable, conector, shield, EMC interference, longitud del segmento
2. 2.Switch / topology layer — QoS, prioridades, configuración de puerto, conformance class
3. 3.Device layer — módulo IO, versión de firmware, device name, configuración IP
4. 4.Protocol layer — RT class (1 / 2 / 3), update time, watchdog, GSDML mismatch

El cliente mira solo a 3 y 4 — TIA Portal le dice qué ve el PLC. El diagnóstico real arranca en 1 y 2.

Paso 1 — Wireshark capture en el segmento Profinet

Sin Wireshark capture no tiene sentido adivinar. Setup:

• TAP (Test Access Point) entre PLC y switch (Profitap ProfiShark 1G, Allegro Network NA10G, Garland Tech P1GMS) — tap pasivo, nunca use mirror port en switch productivo, el jitter se distorsiona
• Segunda opción: si no tiene TAP, port mirror en switch managed (Cisco IE-4000, Hirschmann RSP, Siemens SCALANCE XR-528) — sirve para análisis de contenido de paquetes, no sirve para análisis preciso de jitter
• Wireshark 4.4+ con dissector Profinet (built-in desde la versión 3.0)
• Capture filter: vlan and eth.type == 0x8892 (Profinet EtherType) o full capture y dissect post-hoc

Qué medir en Wireshark:

A) Cycle time consistency

Profinet IO RT habitualmente tiene update time 4 ms (default), 8 ms o 16 ms. Capture 60 segundos de comunicación entre PLC y el dispositivo problemático. En Wireshark: Statistics → I/O Graphs, filter pn_rt && ip.src == <PLC IP> && ip.dst == <device IP>. Intervalo esperado entre paquetes = update time ± 100 μs jitter.

Ejemplo real de la línea 2026-03 (cliente en SR — automotive Tier 1): - Update time configurado: 4 ms - Medido: 4 ms ± 200 μs base, pero cada 12-18 segundos un spike de 18-32 ms durante 1 paquete - Watchdog: 3 × 4 ms = 12 ms → el spike supera el watchdog → IO error 16#80B1

B) Frame loss

Profinet RT es UDP-like (sin acknowledgement). Pérdida de 1 frame = salto inmediato del cycle counter. El dissector Wireshark muestra cycle_counter en cada RT frame. Salto en counter de más de 1 = frame perdido.

Tasa aceptable: < 1 lost frame por millón (1e-6). Problema real: > 1 / 100 000 (1e-5) — eso lo ve el operario como «a veces cae la comunicación».

C) Alarm frames

Profinet tiene canal de alarmas separado (acyclic, low-priority). En Wireshark el filter pn_io.alarm_type muestra alarmas generadas por dispositivo: temperature warnings, module diagnostics, diagnostic alarms. Muchos clientes las ignoran porque «el PLC todavía no se ha quejado» — pero contienen advertencias que preceden la caída en horas.

Paso 2 — SIEMENS PRONETA Basic (free tool que nadie usa)

PRONETA Basic está disponible libremente (Siemens Support Portal, ID 67460624) y hace el 80 % de lo que hace el SINEC NMS de pago — gratis. Tres funciones clave:

• Topology scan vía LLDP — construye el topology graph real de la red actual y lo compara con la topología planificada del proyecto TIA Portal. Cable miscount, wrong port assignment, unknown device (por ejemplo el portátil olvidado de un técnico o un switch no autorizado) salen al instante.
• IO Test — se conecta como Profinet IO controller (emula al PLC) y hace test read/write directamente al módulo IO sin el PLC en medio. Si el IO test funciona y el PLC no, el problema está en la config del PLC o en la ruta de comunicación PLC → device. Si el IO test no funciona, el problema está en el device o el cable hacia él.
• Diagnostic readout — lee versiones de firmware, configuración IP, device name y alarm history de todos los dispositivos accesibles a la vez. El 30 % de los problemas Profinet «no deterministas» son duplicados de device name — escanee y verá dos módulos con el mismo nombre en la red.

Paso 3 — Jitter measurement (LLDP y TSN ready check)

Para Profinet IRT (motion, sub-ms) el requisito es jitter < 1 μs. Para Profinet RT (1–8 ms cycle) es aceptable jitter < 100 μs. Medición:

• PROFITap ProfiShark 1G con precise timestamp (sub-microsecond)
• Synesis InterMatch o Allegro Network Multimeter (NTM industrial dedicado)
• Ligero: caja Linux con NIC PTP-aware (Intel I210, I225) y tcpdump -i eth0 -j adapter_unsynced — timestamps del HW NIC clock

La causa más frecuente de jitter alto (> 500 μs): switch unmanaged en la ruta Profinet. Un switch D-Link / TP-Link / Netgear corriente no tiene QoS para Profinet EtherType 0x8892 — los RT frames esperan en cola detrás del bulk traffic (firmware download, configuration upload, video feed de cámara).

Historia real — ciclo de 50 ms → 200 ms

Cliente (planta alimentaria, Bratislava, llenadora de líneas presurizadas, setup de 5 líneas). Queja: una línea de cinco tiene cycle time 200 ms en lugar del diseño de 50 ms. PLC: Siemens S7-1517F. IO: ET 200SP con 6 módulos IO + 2 servoaxes vía Profinet IRT.

Primeros 3 días — caminos falsos: - Diagnostics TIA Portal: ningún ERROR, pero warnings IO update time exceeded - Update de firmware PLC + módulos IO: sin avance - Cambio del módulo IO supuestamente «lento»: sin avance

Día 4 — Wireshark + PRONETA:

PRONETA topology scan mostró: - 4 líneas tienen line topology: PLC → IO1 → IO2 → IO3 → IO4 (vía built-in 2-port switches en los módulos IO) - La quinta línea tiene STAR topology vía switch externo SCALANCE X-208 — artefacto histórico de cuando la línea tuvo una workstation adicional

Wireshark capture en la quinta línea: - Update time 50 ms ± 80 ms (!) — jitter masivo - Frame loss: 4 / 10 000 (1e-3.4) — inutilizable para IRT motion - Bulk traffic: 200 Mbps de RTSP video stream desde la HMI camera a través del mismo switch

Causa: el SCALANCE X-208 tenía configuración QoS por defecto (FIFO, sin prioridad para Profinet EtherType). Con la carga de video stream los Profinet RT frames esperaban en cola. El operario habilitó previamente video monitoring «solo de prueba» — 6 meses antes.

Solución: cambio de 30 minutos en el Web Based Management del switch: 1. Habilitar Profinet QoS preset (Configuration → QoS → Profinet) 2. Set EtherType 0x8892 priority class 6 (best effort = 0, voice = 5, Profinet = 6, network control = 7) 3. Apply, commit, save startup config

Resultado: cycle time de vuelta a 50 ms ± 2 ms. Jitter < 80 μs. El OEE de la línea subió del 71 % al 88 % una semana después del fix.

Este problema concreto el update de firmware PLC nunca lo habría resuelto — el fallo estaba en la configuración del switch a 3 hops del PLC. Sin Wireshark capture + PRONETA topology la búsqueda habría durado otras 2–4 semanas y habría perdido otros 40–60 k€ en producción no entregada.

Cinco lugares que nadie revisa

1. 1.Cable fuera de PROFINET Type A/B/C (ISO/IEC 11801). Un CAT-6 de oficina en una nave con variadores de frecuencia se degrada más rápido que el papel. Industrial Type C con double shield cuesta 40–80 € más por enlace — inversión que se devuelve al primer drop.
2. 2.Shield rematado en ambos extremos con potenciales de tierra distintos → ground loop → induced voltage 5–50 V → corrupted frames. El shield Profinet se conecta solo en un extremo.
3. 3.Switch QoS misconfiguration — la QoS por defecto en un switch managed muchas veces NO es correcta para Profinet EtherType 0x8892. Hay que activar explícitamente el preset Profinet QoS, o configurar manualmente VLAN + 802.1p priority class 6.
4. 4.Wrong Conformance Class. Profinet tiene tres clases (CC-A basic, CC-B device replacement + diagnostics, CC-C isochronous IRT). Para IRT motion cada switch en la ruta debe ser CC-C. Un switch CC-B más barato en la ruta IRT = cycle time inconsistente.
5. 5.Device name duplicates. Profinet identifica el dispositivo vía device_name (DNS-like), no MAC. Un módulo IO de repuesto sin nombre subido = duplicado en la red = enrutamiento arbitrario de frames = fallos aleatorios.

Playbook práctico — 4 horas para diagnosticar

Ante problemas Profinet:

1. 1.(30 min) PRONETA Basic topology scan. Compare con el proyecto TIA Portal. Identifique diferencias.
2. 2.(45 min) Wireshark capture 5 minutos en el segmento problemático vía TAP o mirror port. Filter pn_rt. Analice cycle time consistency, frame loss, alarm frames.
3. 3.(30 min) PRONETA IO Test en el device problemático. ¿Funciona? El problema está en la config del PLC. ¿No funciona? El problema está en el device o en la ruta hacia él.
4. 4.(60 min) Switch management — revise QoS, prioridades, conformance class de todos los switches en la ruta. Revise cableado (Type A/B/C), shield termination, entorno EMC.
5. 5.(45 min) Reproduce + verify. Tras identificar la causa probable — cambie, mida de nuevo, compare antes / después.

Esto le lleva al 90 % de los problemas Profinet. Para el 10 % restante (TSN, advanced motion sync, multi-vendor inter-op) hace falta SIEMENS SINEC NMS (paid, 4 000–8 000 € anuales) o vendor support — pero ese 10 % merece tener un experto externo en vez del propio equipo.

---

*Hacemos diagnóstico Profinet, network auditing y migración TSN para líneas productivas en SR/CZ/PL. La primera consulta (90 min) sobre su problema concreto probablemente desvele 1–2 de los cinco lugares mencionados — o al menos dirá cuál de las tres capas (cable / switch / device) merece más investigación.*