SEMAIQ · Automatización y PLC · Querétaro
Programacion de PLC en TIA Portal: estructura OB, FB y FC
1. Arquitectura del programa: OB, FB, FC, DB y UDT
Un programa de TIA Portal es una colección de bloques que el sistema operativo de la CPU llama en un orden definido. Decidir qué tipo de bloque corresponde a cada tarea antes de escribir la primera red es lo que permite probar, reutilizar y corregir el programa dos años después sin volver a leerlo completo.
- Bloques de código: OB (bloque de organización), FB (bloque de función) y FC (función).
- Bloques de datos: DB, que conservan valores entre ciclos de scan.
- Tipos de datos de usuario (UDT): estructuras que reutilizan varios FB y DB.
La duda inicial se resuelve con una pregunta: ¿esta lógica necesita recordar algo entre una llamada y la siguiente? Si la respuesta es sí —un temporizador, un contador, un modo de operación, el paso de una secuencia— va en un FB. Si la salida se calcula por completo con las entradas actuales, va en un FC. Y si lo que quieres definir es cuándo corre la lógica, va en un OB. El error más caro no es elegir mal un bloque, es no elegir ninguno y programar todo en el ciclo principal.
2. OB: el punto de entrada del programa
La CPU no ejecuta tus FB cuando puede: ejecuta un OB cuando ocurre el evento que tiene asignado. Por eso los OB son la capa de planificación del proyecto, no el lugar donde se programa la máquina.
- OB1, ciclo de programa: corre de forma continua en RUN. Debe leerse como un índice de llamadas a FB y FC.
- OB de arranque (OB100): corre una sola vez en la transición de STOP a RUN; inicializa estados, carga recetas y valida condiciones antes de habilitar el automático.
- Alarmas cíclicas o de tiempo (familia OB3x): se ejecutan a intervalos equidistantes con prioridad propia, independientes del escaneo normal. Es el lugar correcto para un lazo de control o un muestreo determinista.
- Alarmas horarias y de retardo: disparan tareas a una hora o fecha definida; útiles para arranques y paros de servicios auxiliares o conteos por turno.
- Alarmas de hardware y de proceso (familia OB4x): reaccionan a eventos de la periferia, como un flanco en una entrada rápida o el fin de carrera de un módulo de posicionamiento.
- Alarmas de diagnóstico y de error (familia OB8x, más los OB de error de programación y de acceso a periferia): detectan un módulo que se pierde o una dirección mal escrita sin que la CPU se vaya a STOP, y convierten una falla misteriosa en un mensaje con nombre y número de slot.
Regla práctica: dentro de un OB van llamadas, transferencia de datos y unas cuantas condiciones. Si se llena de lógica de válvulas o secuencias, esa lógica pertenece a un FB.
3. FB: lógica con memoria de instancia y multiinstancia
Un FB es un bloque reutilizable con memoria propia: el bloque de datos de instancia. Cada llamada lleva asociado un DB donde viven sus variables estáticas —temporizadores, contadores, detección de flancos, pasos de secuencia— y esos valores sobreviven de un ciclo al siguiente. Esa es la diferencia esencial con el FC y la razón por la que un mismo FB controla tres motores distintos sin mezclar estados: cada motor tiene su instancia y su propio juego de temporizadores.
Cuando un FB necesita llamar a otro FB hay dos caminos: crear un DB de instancia aparte para el bloque interno, o declararlo como variable estática del tipo del FB interno, lo que se conoce como multiinstancia. En ese caso la memoria del bloque hijo vive dentro de la instancia del padre y deja de aparecer como DB suelto en el árbol del proyecto: un FB de estación que contiene los FB de cada mecanismo. La estructura de la instancia se deriva de la interfaz del FB y no se edita a mano.
4. FC: lógica sin memoria
Un FC no tiene DB de instancia y su área temporal existe solo mientras el bloque se ejecuta, así que una variable Temp no sirve como memoria del ciclo anterior. El FC es la herramienta correcta para lógica sin estado: escalar una entrada analógica a unidades de ingeniería, convertir unidades, calcular eficiencia o producción, evaluar una condición de permiso que depende solo del estado actual, formatear un grupo de datos. Un FC sin dependencias se copia de un proyecto a otro sin arrastrar nada.
Un FC sí puede escribir en un DB global y a veces es lo correcto —dejar un resultado que lee el HMI—, pero usarlo como puente permanente a memoria global reduce su portabilidad. El programador que mete temporizadores dentro de un FC termina inventando variables globales para esconder el problema: si la lógica necesita recordar, es un FB.
5. DB de datos globales y UDT: adiós a M0.0 y a DB1.DBW12
Las variables globales deben vivir en DB, no en memoria de marcas %M ni en direcciones absolutas tipo DB1.DBW12. En las CPU S7-1200 y S7-1500 el acceso optimizado al bloque es el ajuste por defecto: el sistema ordena y alinea los datos, el programador ya no calcula desplazamientos y agregar una variable nueva no rompe las direcciones del resto del bloque. Con direccionamiento absoluto, insertar un campo en medio de la estructura desplaza todos los offsets y obliga a revisar el HMI y cualquier bloque que lea por byte.
Sobre esa base, el UDT evita repetir estructuras: define una vez un tipo —por ejemplo un tipo accionamiento con orden de marcha, realimentación, falla, tiempo de operación y contador de ciclos— y úsalo en la interfaz de tus FB y en los DB globales. Si aparece un campo nuevo, lo agregas al UDT y se propaga a todas las instancias que lo usan: la diferencia entre un cambio y treinta cambios.
6. Comparativa: OB, FB, FC y DB en la práctica
| Criterio | OB | FB | FC | DB global / UDT |
|---|---|---|---|---|
| Memoria propia | No: es el evento de ejecución | Sí: DB de instancia | No: las Temp se pierden | DB conserva datos; UDT define estructura |
| Recuerda estado entre ciclos | No aplica | Sí | No | Sí |
| Para qué se usa | Definir cuándo corre el programa | Mecanismos, secuencias, lazos cerrados | Cálculos, conversiones, permisos | Datos compartidos, recetas, estructuras |
| Ejemplos típicos | OB1, arranque, alarma cíclica, diagnóstico | Control de motor, estación, dosificación | Escalado analógico, conversión de unidades | Setpoints, conteos de producción, tipo de motor |
| Reutilización | Baja: es específico de la máquina | Alta: misma lógica, distinta instancia | Alta si no depende de memoria global | Alta si está documentado |
| Efecto en el tiempo de ciclo | La prioridad alta interrumpe al OB1 | Cada llamada suma; el acceso optimizado ayuda | Bajo: pocas operaciones | El acceso optimizado es más rápido |
Si la duda persiste entre FB y FC, la prueba es simple: pregúntate si el bloque daría el mismo resultado llamándolo dos veces seguidas con las mismas entradas. Si la segunda llamada cambia porque memorizó algo, es un FB declarado como FC.
7. Buenas prácticas de estructura y nomenclatura
Un FB por mecanismo o subestación
Un FB debe cubrir una unidad funcional completa: un motor con sus permisos, alarmas y tiempos; una estación de una celda; un sistema de dosificación. Si mezcla dos mecanismos, cualquier cambio obliga a probar los dos; si es demasiado pequeño, el OB1 se llena de decenas de llamadas sin jerarquía.
Nombres simbólicos, títulos y REGION
Nada de M0.0, DB1.DBW12 ni aux1: un nombre debe decir qué es y de dónde viene, como Est1_transfer_marcha. Cada bloque lleva título y comentario de encabezado, y el cuerpo se agrupa con REGION (permisos, comandos, salidas, alarmas, diagnóstico) comentando lo no obvio: por qué existe un retardo, qué sensor se filtra, qué enclavamiento es de proceso y no de seguridad.
Separar la lógica de seguridad del control estándar
Las funciones de seguridad van en bloques F certificados, dentro de su propio grupo de ejecución (F-runtime group en TIA Portal con Safety Advanced) y con contraseña. El programa estándar puede leer estados para señalizar en el HMI, pero no ejecutar la función de protección; el detalle está en PLC de seguridad y seguridad funcional en maquinaria industrial.
Librerías reutilizables y versionado
Los bloques que ya funcionaron —motor, válvula, PID, handshake con robot— se guardan en una biblioteca maestra con número de versión que sube cada vez que cambia la interfaz, y se exportan a texto para respaldo o repositorio. Sin versionado, la única forma de saber qué cambió es preguntar quién tocó la máquina.
Checklist antes de entregar un proyecto en TIA Portal:
- OB1 es una lista de llamadas legible, sin lógica de mecanismos suelta.
- Cada mecanismo tiene su FB con interfaz documentada y su DB de instancia.
- Los cálculos y conversiones están en FC sin dependencia de memoria global.
- Los datos compartidos viven en DB optimizados con nombres simbólicos y sin direcciones M.
- Las estructuras repetidas están definidas como UDT y reutilizadas.
- La lógica de seguridad está en sus bloques F, separada y con contraseña.
- Hay bloques de diagnóstico y alarmas con texto para el HMI.
- Los bloques reutilizables están en la biblioteca maestra, con versión y respaldo.
8. Cómo afecta la estructura al tiempo de ciclo
El tiempo de ciclo de scan es la suma del tiempo de ejecución del programa de usuario más el del sistema operativo y la comunicación. La estructura del programa determina la primera parte: cada llamada cuesta, cada operación cuenta y los OB de mayor prioridad interrumpen al OB1 alargando su ciclo, como documenta Siemens para las CPU S7-1500. Tres consecuencias prácticas:
- Un OB1 con miles de redes monolíticas hace imposible medir y repartir el costo. Fragmentado en FB y FC puedes cronometrar por bloque y atacar el que consume.
- Los lazos de control van en una alarma cíclica con intervalo fijo y prioridad propia, no colgados del ciclo normal, porque el tiempo del OB1 varía con las condiciones de la máquina.
- Para medir, no busques el antiguo OB1_Prev_Cycle de la S7-300: en S7-1200 y S7-1500 se usa la instrucción RT_INFO de la biblioteca, que entrega tiempos de ciclo y de ejecución.
Otro vicio heredado: volver al direccionamiento absoluto para reutilizar código de S7-300 no solo pierde velocidad, también reintroduce offsets frágiles. Si tu proyecto viene de una plataforma anterior, aprovecha la migración de PLC Siemens S7-300 a S7-1500 para replantear bloques, nombres y diagnóstico en lugar de portar el mismo programa monolítico a un hardware nuevo.
9. Caso práctico: de un OB1 monolítico a bloques reutilizables en tres estaciones iguales
Situación (caso representativo): una celda de ensamble automotriz del Bajío con tres estaciones idénticas —carga, prensado de bujes y verificación— operaba con un solo OB1 de aproximadamente 1,400 redes, direcciones absolutas y la lógica de cada estación copiada tres veces con pequeñas variantes. Cada ajuste de secuencia se hacía tres veces y las diferencias entre copias provocaban fallas intermitentes difíciles de rastrear; no había diagnóstico de módulos.
Solución: se reestructuró el programa sin cambiar la lógica de proceso. Se definió un UDT tipoEstacion con comandos, estados, alarmas y contadores; sobre ese tipo se escribió un FB de estación instanciado tres veces con su propio DB, más FB de mecanismo para el transfer, el prensado y el enclavamiento, llamados como multiinstancia desde el FB de estación. Los cálculos y el escalado de analógicas se movieron a FC, los datos del HMI a DB globales optimizados, el lazo de fuerza del prensado a una alarma cíclica y el estado de las tarjetas a un FB de diagnóstico. El FB de estación quedó en la biblioteca maestra con número de versión.
Resultados obtenidos:
- El OB1 quedó reducido a poco más de 60 redes de llamadas: se lee como un índice de la máquina.
- Un cambio de secuencia se aplica una sola vez y queda en las tres estaciones.
- La puesta en marcha se hizo estación por estación, habilitando una instancia a la vez.
- El HMI dejó de depender de direcciones absolutas y el FB expone estado y paso actual.
Es el pan de cada día en proyectos de programación de PLC en la industria automotriz del Bajío, donde una celda suele replicarse y el costo de mantenimiento se define en la estructura del programa, no en el hardware. Cuando el programa nace ordenado, el trabajo de programación de PLC en Querétaro se concentra en la lógica de proceso en lugar de la arqueología de bloques.
Preguntas frecuentes
¿Cuál es la diferencia entre un FB y un FC en TIA Portal?
El FB tiene memoria propia: cada llamada usa un DB de instancia con variables estáticas, así que recuerda temporizadores, contadores, flancos y pasos de secuencia entre ciclos. El FC no tiene DB de instancia: sus temporales se pierden al terminar y solo sirve para lógica que depende por completo de las entradas actuales.
¿Qué debe ir en el OB1 y qué no?
En el OB1 van llamadas a FB y FC en un orden lógico claro, transferencia de datos entre bloques y unas cuantas condiciones de habilitación. La lógica de mecanismos, secuencias y lazos cerrados no se programa dentro del OB1: se encapsula en FB reutilizables y se instancia desde el ciclo.
¿Qué es la multiinstancia y cuándo conviene usarla?
La multiinstancia consiste en declarar la llamada a un FB hijo como variable estática dentro de otro FB: la memoria del bloque interno vive en la instancia del padre. Conviene cuando un bloque reutilizable llama a otros bloques, porque evita la proliferación de DB de instancia sueltos.
¿Mejor un DB global o direcciones absolutas tipo DB1.DBW12?
Un DB global optimizado con nombres simbólicos. En las CPU S7-1200 y S7-1500 el acceso optimizado es el ajuste por defecto: el sistema ordena y alinea los datos y el programador ya no calcula desplazamientos. Con direcciones absolutas, insertar una variable desplaza todos los offsets y el HMI sigue leyendo direcciones frágiles.
¿La estructura del programa afecta el tiempo de ciclo del PLC?
Sí. El ciclo suma el tiempo de ejecución del programa, el del sistema operativo y el de la comunicación. Cada llamada cuesta y los OB de mayor prioridad interrumpen al OB1 alargando su ciclo. La solución es encapsular, mover los lazos de control a alarmas cíclicas con intervalo fijo y medir con la instrucción RT_INFO.
¿Necesitas reestructurar o programar tu PLC en TIA Portal?
SEMAIQ programa, reestructura y migra PLC Siemens en Querétaro, Guanajuato, Aguascalientes, San Luis Potosí y todo el Bajío, con estructura de bloques reutilizables, nomenclatura simbólica, diagnóstico integrado y librerías versionadas. Si tu programa creció sin orden o vas a migrar de plataforma, lo revisamos contigo.


