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. **Capa física** — cable, conector, shield, EMC interference, longitud del segmento 2. **Switch / topology layer** — QoS, prioridades, configuración de puerto, conformance class 3. **Device layer** — módulo IO, versión de firmware, device name, configuración IP 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. **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. **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. **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. **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. **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. **(30 min)** PRONETA Basic topology scan. Compare con el proyecto TIA Portal. Identifique diferencias. 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. **(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. **(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. **(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.*