Integración y configuración en TIA Portal
Sesión 4 · U3.1 Integración y configuración
ING. JAVIER APAZA MARTÍNEZ
Miércoles 4 de noviembre de 2026 · 19:00 – 22:00
Plan de la sesión
Seis formas de conectar equipos en TIA Portal
| Forma | Con quién | Qué se programa | Puerto o medio |
|---|---|---|---|
| Modbus TCP | Cualquier marca con Ethernet | MB_CLIENT en uno, MB_SERVER en el otro | TCP 502 |
| Modbus RTU | Variadores, medidores, balanzas | Modbus_Comm_Load + Modbus_Master | RS-485 |
| S7 PUT/GET | Otro PLC Siemens | Solo en el que pide | TCP 102 |
| TSEND_C / TRCV_C | PLC, PC, robot, lector | En los dos lados | TCP, ISO-on-TCP o UDP |
| PROFINET IO | E/S remotas, variadores, válvulas | Nada: se configura y aparece en %I / %Q | Ethernet (RT) |
| Conexión HMI | Paneles y SCADA | Nada: se vinculan variables | Protocolo S7 |
¿Qué se puede simular, y qué no?
PLCSIM
Simula el S7-1200 y su comunicación entre instancias simuladas en la misma PC, y la HMI en runtime. No sale a la red real.
PLCSIM Advanced
Sí sale a la red real (Wireshark, simuladores externos), pero no simula el S7-1200: solo S7-1500 y ET 200SP.
Simulador Modbus en la PC
Un servidor o esclavo Modbus de prueba para el PLC real, o un cliente para leer al PLC. Enlaces en el LMS.
Lo que se configura mal en simulación también falla en planta. Hoy aprendemos a configurarlo bien y a reconocer cada falla.
Modbus TCP en el S7-1200
MB_SERVER, MB_CLIENT y el TCON_IP_v4
Uno espera, el otro llama
llama a 192.168.0.10:502
escucha en el puerto 502
1 · Conexión
El cliente abre la conexión TCP. Si nadie la abre (los dos pasivos), nunca pasa nada.
2 · Petición
El cliente pide “lee 10 registros desde el 40001” o “escribe este valor”.
3 · Respuesta
El servidor contesta con los datos de su DB, o con una excepción.
El TCON_IP_v4: la tarjeta de visita de la conexión
| Parámetro | En el cliente | En el servidor | Para qué |
|---|---|---|---|
| InterfaceId | Identificador de hardware de la interfaz PROFINET (suele ser 64) | Por qué puerto sale | |
| ID | Un número único por conexión dentro de cada PLC | Distinguir conexiones | |
| ConnectionType | 11 = TCP | Tipo de conexión | |
| ActiveEstablished | TRUE | FALSE | Quién la abre |
| RemoteAddress | IP del servidor | 0.0.0.0 = cualquiera | Con quién |
| RemotePort | 502 | 0 | A qué puerto llama |
| LocalPort | 0 | 502 | En qué puerto escucha |
MB_SERVER y MB_CLIENT, parámetro por parámetro
MB_SERVER (PLC_1)
| MB_HOLD_REG | Un Array of Word en un DB: el [0] es el 40001 para el cliente |
| CONNECT | El TCON_IP_v4 del servidor |
| NDR · DR | Llegó un dato nuevo · alguien leyó |
| STATUS | Código de error (ayuda F1) |
Se llama en cada ciclo. Coils, entradas discretas e input registers van por defecto a %Q, %I y %IW.
MB_CLIENT (PLC_2)
| REQ | Flanco o nivel: hace la petición |
| MB_MODE | 0 = leer · 1 = escribir |
| MB_DATA_ADDR | 40001 = holding desde la dirección 0 |
| MB_DATA_LEN | Cuántos registros |
| MB_DATA_PTR | Dónde guarda o de dónde toma los datos |
| DONE · BUSY · ERROR | Cómo va la petición |
Un MB_CLIENT por servidor, cada uno con su DB de instancia y su ID.
Demostración en TIA Portal
- Dos S7-1200 en la vista de redes, misma subred (192.168.0.10 y .20 /24).
- PLC_1: un DB “Datos” con un Array[0..9] of Word (con versiones antiguas del bloque, el DB debía ser de acceso estándar).
- PLC_1: MB_SERVER en el OB1, con su TCON_IP_v4 en pasivo.
- PLC_2: MB_CLIENT con un pulso de reloj en REQ, leyendo 40001, 10 registros.
- Tabla de observación: cambio un valor en PLC_1 y lo veo llegar a PLC_2.
- Rompo algo a propósito y miro STATUS.
Modbus RTU en el S7-1200
Un puerto serie, un maestro y una pregunta por vez
Lo que necesitas
- Hardware: placa CB 1241 RS-485 o módulo CM 1241 RS-422/485. La CPU no trae puerto serie.
- Modbus_Comm_Load: configura el puerto (BAUD, PARITY, …). Una vez al arrancar o al cambiar algo. Su parámetro MB_DB apunta al DB de instancia del Modbus_Master.
- Modbus_Master: cada petición. MB_ADDR = dirección del esclavo; DATA_ADDR = registro; MODE = 0 leer, 1 escribir.
Una pregunta por vez
Con varios esclavos o varios registros, las peticiones se encadenan: cuando una termina (DONE o ERROR), empieza la siguiente.
Una pequeña máquina de estados con un CASE en SCL lo resuelve.
El caso ATV12, bien hecho
En el variador
- Dirección Modbus (Add), velocidad (tbr) y formato (tFO).
- Canal de mando y de consigna en Modbus: si no, ignora lo que llega.
En el PLC
- La misma velocidad y paridad: de fábrica, 19 200 y 8E1.
- Palabra de mando CMd (8501 → DATA_ADDR 48502): escribir 6, después 7, después 15.
- Consigna LFr (8502 → DATA_ADDR 48503).
Lo que estaba mal en la 1ª versión
- El PLC a 38 400 sin paridad, y el variador de fábrica a 19 200 8E1.
- Faltaban el canal de mando y la secuencia de arranque.
- El sensor de temperatura y el servo mostraban la misma captura del ATV12: cada equipo tiene sus propios registros.
Gateway Modbus TCP ↔ RTU
cliente TCP
maestro RTU
dirección 1
La clave: Unit ID
En la petición TCP va la Unit ID = dirección del esclavo RTU. En el MB_CLIENT es MB_UNIT_ID (en el DB de instancia en varias versiones).
Quién es quién
El servidor es el gateway, no el servo. El servo es esclavo RTU: no tiene ActiveEstablished ni puerto.
10 min
Volvemos con S7, HMI y PROFINET
Comunicación S7 y HMI
Entre equipos Siemens
PUT/GET: leer o escribir otro PLC sin programarlo
En el PLC que se lee (servidor)
- Propiedades › Protección y seguridad › Mecanismos de conexión › “Permitir acceso vía comunicación PUT/GET”.
- El DB que se lee: acceso no optimizado (direcciones absolutas).
En el PLC que pide (cliente)
- Bloque GET o PUT, con su conexión S7 (la crea el asistente del bloque).
- ADDR_1 = P#DB10.DBX0.0 WORD 10 · RD_1 o SD_1 = área local.
Ojo con la seguridad
Con PUT/GET habilitado, cualquiera que llegue a la red puede leer y escribir esa CPU. Viene desactivado por algo. Se usa solo donde hace falta, y en una red segmentada (S5).
¿PUT/GET, TSEND_C/TRCV_C o Modbus TCP?
| PUT/GET | TSEND_C / TRCV_C | Modbus TCP | |
|---|---|---|---|
| Se programa | Solo el que pide | Los dos lados | Cliente y servidor |
| Con quién | Solo Siemens | Cualquier equipo con TCP o UDP | Cualquier marca |
| Datos | Áreas de memoria | Un bloque de bytes que defines tú | Registros de 16 bits y bits |
| Requisito | Permiso PUT/GET y DB no optimizado | Acordar la estructura en los dos lados | Acordar el mapa de registros |
| Cuándo | Leer otro S7 rápido, sin tocarlo | Robots, lectores, PC con aplicación propia | Equipos de otras marcas, SCADA |
La HMI KTP700: conexión HMI, no PROFINET IO
- HMI y PLC en la misma subred.
- En la vista de redes: conexión HMI entre los dos.
- Las variables de la HMI apuntan a las del PLC (sin direcciones a mano).
- Para probar sin hardware: PLCSIM + simulación del runtime.
“####” en todos los campos = la HMI no ve al PLC.
Por qué no es PROFINET IO
La HMI usa el protocolo S7 por la interfaz Ethernet del PLC. PROFINET IO es otra cosa: el intercambio cíclico entre el controlador y sus E/S.
Los dos viajan por el mismo cable, pero son protocolos distintos.
PROFINET IO
E/S remotas que aparecen en %I y %Q sin programar nada
Agregar una Turck BL20 o una Festo CPX
El nombre manda
El controlador busca al equipo por su nombre y después le da la IP (DCP). Nombre distinto = equipo en rojo.
Módulos iguales
Los módulos del proyecto deben coincidir con los montados, en el mismo orden.
Sin programar
Las entradas y salidas aparecen como %I y %Q del PLC. Se usan como si fueran locales.
Cuando un equipo PROFINET no arranca
LED BF encendido o parpadeando
No hay intercambio con el controlador: nombre sin asignar o distinto, IP en conflicto, cable.
LED SF o DIA
Hay comunicación, pero hay un error: módulo distinto al configurado, falta tensión de carga, cortocircuito en una salida.
En TIA
Online y diagnóstico y el búfer de diagnóstico de la CPU dicen qué equipo y qué módulo.
Reaccionar a la caída
Si una estación cae, la CPU llama al OB86 (fallo de rack o estación): ahí se avisa o se lleva la máquina a un estado seguro.
Configuración en TIA Portal
Modbus TCP y RTU, PUT/GET, HMI y PROFINET.
¿Por qué no comunica?
Diagnóstico por capas, de abajo hacia arriba
Un método que no falla: subir por las capas
Si responde con una excepción, la red está bien: el problema está arriba.
Wireshark: ver lo que viaja de verdad
| Filtro | Qué muestra |
|---|---|
| mbtcp | Modbus TCP (o tcp.port == 502) |
| s7comm | Comunicación S7: TIA, HMI, PUT/GET |
| pn_dcp | Bautizo y búsqueda PROFINET |
| pn_io | Datos cíclicos PROFINET RT |
| arp | Quién tiene esta IP (y duplicados) |
Para capturar en un switch
Wireshark en tu PC solo ve tu propio tráfico. Para ver lo que pasa entre dos PLC hace falta un switch gestionable con puerto espejo, o un TAP.
Wireshark trae ejemplos de capturas S7comm y Modbus para practicar sin hardware.
¿Por qué no comunica?
Síntomas reales de planta. Encuentra la causa más probable.
Avance 2 y trabajo final
Empiezan hoy
Protocolos en TIA Portal
- A · Modbus TCP entre dos S7-1200 (o PLC y simulador de PC).
- B · Modbus RTU: el programa del ATV12 con su secuencia de arranque.
- C · S7: PUT/GET o HMI KTP700, probado en PLCSIM.
- D · Diagnóstico: dos fallas provocadas a propósito, con síntoma, causa y solución.
Cómo cuenta
Son ejercicios guiados, sin nota propia. Eliges la parte que sea un enlace de tu diseño y la sumas al trabajo final (parte 2.3: 7,5 % de la nota), con una falla provocada y el proyecto archivado.
Guía y lista de cotejo: /practicas/p2.html
Trabajo final · La red de una planta, completa
- Individual, con la planta que elegiste antes de la S3.
- Una planta (de la lista o la de tu trabajo): arquitectura, topología, plan IP, protocolo justificado en cada enlace, un enlace configurado en TIA, zonas de seguridad y salida de datos por OPC UA o MQTT.
- Defensa de 3 minutos + 2 de preguntas en la S6, lunes 9 de noviembre. El documento final se entrega después: miércoles 11, 23:59.
Usa lo que ya tienes
El avance 1 es la base de la red; el avance 2, de la configuración en TIA. La S5 agrega la seguridad y la S6, OPC UA.
Guía y rúbrica: /practicas/final.html
Lo que vimos hoy
- Modbus TCP: el cliente abre la conexión (activo), el servidor escucha en 502; un ID y un DB de instancia por conexión.
- Modbus RTU: maestro y esclavo con la misma configuración serie; una petición por vez; el +1 de la notación 4xxxx.
- Gateway: el servidor es el gateway y la Unit ID elige el esclavo RTU.
- PUT/GET necesita permiso y DB no optimizado; la HMI usa conexión S7; PROFINET IO se configura por nombre.
- Diagnóstico: de la capa física hacia arriba.
S5 · Seguridad en las comunicaciones e IoT industrial
Veremos
- Un ataque Modbus en vivo, y cómo se detiene
- Defensa en profundidad, zonas y conductos (IEC 62443)
- Casos reales: Stuxnet, Unitronics, FrostyGoop
- MQTT: publicar, suscribirse y QoS
Para llevar
- Avance 2: un enlace de tu planta configurado en TIA, para mostrarlo en la defensa
- El diagrama de red del avance 1 a mano: le vamos a agregar zonas de seguridad
Ticket de salida
Gracias
El simulador del MB_CLIENT y MB_SERVER queda en el aula