En prácticamente cualquier proceso industrial —desde el control de temperatura en un horno hasta la velocidad de un motor o el nivel de un tanque— encontramos la necesidad de mantener una variable dentro de ciertos límites. Para lograrlo de forma automática, se utilizan controladores PID (Proporcional–Integral–Derivativo), una de las herramientas más importantes y versátiles de la ingeniería de control.
¿Qué hace un controlador PID?
El objetivo de un PID es mantener una variable de proceso (por ejemplo, la temperatura, presión o velocidad) lo más cercana posible a un valor deseado o setpoint, corrigiendo los desvíos que se produzcan. Para ello, el controlador compara constantemente el valor real con el valor deseado y calcula una señal de control que actúa sobre el sistema.
Los tres términos del PID
El nombre “PID” proviene de las tres acciones de control que combina:
P (Proporcional): responde al error instantáneo. Cuanto mayor sea la diferencia entre el valor real y el deseado, mayor será la corrección.
I (Integral): acumula el error a lo largo del tiempo y lo corrige, eliminando desvíos persistentes.
D (Derivativo): predice cómo cambiará el error, reaccionando a su velocidad de variación para suavizar la respuesta.
La combinación equilibrada de estos tres efectos permite obtener un sistema estable, preciso y con una buena respuesta dinámica.
Por qué es tan usado
El PID es tan popular porque:
Es simple de entender y fácil de implementar.
Se adapta bien a una amplia variedad de procesos.
Ofrece un buen equilibrio entre rendimiento y estabilidad.
Incluso cuando se utilizan controladores avanzados o técnicas modernas, el PID sigue siendo la base conceptual de casi todos los sistemas de control industrial.
En los PLCs de Siemens
En los PLCs Siemens, el bloque de funciones PID_Compact del entorno TIA Portal permite implementar controladores PID de manera sencilla y estandarizada. Ofrece modos automáticos de ajuste, funciones de auto–tuning y herramientas gráficas para supervisar el comportamiento del lazo de control.
Si trabajas con automatización y usas PLCs Mitsubishi Electric de las series más recientes (MELSEC iQ-F (FX5) o MELSEC iQ-R), hay una función que probablemente te ahorrará horas de programación: la Comunicación Simple de CPU (Simple CPU Communication).
Esta característica es la solución ideal para compartir datos entre controladores a través de Ethernet de manera rápida, eficiente y, lo más importante, casi sin necesidad de escribir código.
¿Qué es y Por Qué es “Simple”?
La Comunicación Simple de CPU es una función integrada en el software de desarrollo (GX Works3) que permite que dos o más módulos CPU se intercambien información de dispositivos (como registros de datos D, bits M, etc.) de forma periódica y automática.
La clave de su simplicidad radica en que no tienes que programar la lógica de comunicación usando instrucciones de escalera (ladder) o bloques de función específicos. En lugar de eso, todo el proceso se gestiona mediante la configuración de parámetros.
La Magia de la Configuración
Olvídate de complejas secuencias de comandos para establecer conexiones, enviar peticiones o gestionar timeouts. Con esta función, solo necesitas hacer ajustes en la ventana de parámetros de tu CPU:
Define la Conexión: Especifica la dirección IP del PLC de destino (el “socio de comunicación”).
Define el Intercambio: Indica los rangos de dispositivos que deseas enviar y los rangos donde deseas recibir los datos. Por ejemplo, puedes configurar que el rango D100−D109 de tu PLC se envíe y se escriba en el rango D200−D209 del PLC remoto.
Listo: El propio módulo CPU de Mitsubishi se encarga de gestionar la conexión Ethernet, empaquetar los datos y realizar el intercambio en el intervalo que tú definas.
¿En Qué Proyectos Puedes Usarla?
La sencillez de la Comunicación Simple de CPU la hace perfecta para varios escenarios comunes en la industria:
Sistemas Modulares y Líneas de Producción: Cuando tienes una línea de producción con varias máquinas independientes, cada una con su propio PLC, puedes usar esta función para compartir datos críticos:
Sincronización: Enviar el estado “Listo para recibir” de una máquina a la siguiente.
Recetas: Transferir parámetros de producción (longitudes, velocidades, tiempos) de un PLC principal a las máquinas.
Monitoreo: Recopilar datos de alarmas o contadores de producción en un PLC centralizado para su visualización en un HMI.
Compatibilidad Multi-Serie: Puedes establecer la comunicación entre CPUs de distintas plataformas de Mitsubishi, como un PLC FX5U con un controlador modular Q03UDEH o entre dos CPUs iQ-R de diferentes estaciones.
Comunicación con Terceros: Aunque su principal fortaleza es la conexión entre PLCs Mitsubishi, esta función a menudo también se puede configurar para interactuar con otros dispositivos o servidores que utilicen protocolos estándar basados en Ethernet.
Un Consejo Vital de Seguridad
Si bien la Comunicación Simple de CPU simplifica la parte de programación, nunca debemos descuidar la seguridad.
Dado que la transferencia de datos ocurre en segundo plano, siempre es fundamental:
Implementar circuitos de seguridad y enclavamiento fuera del programa de comunicación. Esto asegura que, en caso de un fallo de la red Ethernet o de un error de la CPU, tu maquinaria siempre opere en un estado seguro. La comunicación de datos no debe ser el único medio de control crítico de seguridad.
Conclusión
La Comunicación Simple de CPU es una herramienta poderosa que capitaliza la conectividad Ethernet moderna de los PLCs Mitsubishi. Al mover la complejidad del intercambio de datos de la lógica de programación a la configuración de parámetros, te permite concentrarte en lo que realmente importa: el control de tu proceso.
Si utilizas las plataformas iQ-F o iQ-R, ¡te animamos a explorar y aprovechar esta función!
¿Has utilizado ya la Comunicación Simple de CPU en tus proyectos? ¡Comparte tu experiencia en los comentarios!
Cuando trabajamos con PLCs de distintos fabricantes, uno de los principales retos es traducir mentalmente los conceptos. Siemens y Mitsubishi, por ejemplo, ofrecen funciones muy similares, pero las nombran y organizan de manera distinta. Entender estas equivalencias puede ahorrarnos tiempo y dolores de cabeza.
Un buen ejemplo de esto son los System Memory Bits y Clock Memory Bits en Siemens, y los Special Relays en Mitsubishi.
Configuración en Siemens
En Siemes, a diferencia de Mitsubishi donde el area de memoria de los System Relays (SM) está fija y siempre activa, hay que habilitar los System memory bits y los Clock memory bits, además de que es posible también elegir las direcciones de los bytes en los cuales queremos ese comportamiento. Por default, el MB1 se usara para los System memory bits, y el MB0 para los Clock memory bits.
Para activar los bytes y elegir la dirección en memoria M que tendrá el comportamiento definido, ir a las propiedades del CPU e ir a la opción System and clock memory como se muestra en la siguiente imagen.
Configuración de los bytes en la memoria M de los PLCs de Siemens en los cuales quedarán configurados los System memory bits y los Clock memory bits.
Una vez activados los bytes, automáticamente se agregan los tags para cada uno de ellos y para cada uno de los bits, para así poder utilizar direccionamiento simbólico.
Creción automática de tags para cada uno de los System memory bits y Clock memory bits.
Special Relays (SM) en Mitsubishi
En los PLC Mitsubishi, los SM (Special Relays) son relés (bits) internos predefinidos por el fabricante. Su función es indicar condiciones del propio CPU o proveer señales auxiliares ya listas para usar.
En la siguiente imagen encontramos una lista de los equivalentes a los System y Clock memory bits de Siemens.
Lista de algunos Special Relays en Mitsubishi.
Los banderines del sistema
En Siemens, los System Memory Bits (SM bits) son pequeñas banderas internas que nos informan del estado del PLC o de condiciones especiales. Algunos ejemplos típicos son:
Bit de “primer ciclo” (para ejecutar lógica solo una vez al arrancar).
Bit de “Siempre en true (1)”.
Bit de “Siempre en false (0)”.
Bit relacionados con errores del sistema.
En Mitsubishi encontramos algo equivalente en los Special Relays. Por ejemplo:
SM402: encendido durante un ciclo de scan cuando la CPU cambia a RUN.
SM403: apagado durante un ciclo de scan cuando la CPU cambia a RUN.
SM400: siempre en true (1).
SM401: siempre en false (0).
En otras palabras: 👉 SM bits en Siemens ≈ Special Relays en Mitsubishi.
Los pulsos de reloj
Otro caso muy común es la necesidad de generar pulsos periódicos, por ejemplo, para hacer parpadear una lámpara o realizar una acción cada cierto tiempo.
En Siemens podemos configurar un área de memoria como Clock Memory Bits. Ahí tendremos disponibles pulsos de distintas frecuencias (10 Hz, 5 Hz, 2.5 Hz, etc.), y nosotros decidimos en qué dirección de memoria los queremos usar.
En Mitsubishi, estos pulsos ya vienen predefinidos dentro de los Special Relays:
SM409: parpadea con una frecuencia de 100 Hz.
SM410: parpadea con una frecuencia de 10 Hz.
SM411: parpadea con una frecuencia de 5 Hz.
SM412: parpadea con una frecuencia de 1 Hz.
SM413: parpadea con una frecuencia de 0.5 Hz.
Imagen de la pag. 939 del MELSEC iQ-R CPU Module User’s Manual (Application)
Aquí la diferencia clave es que: 👉 En Siemens, el programador elige dónde colocar los pulsos. 👉 En Mitsubishi, el fabricante ya te da direcciones fijas.
Uso en Siemens
Podemos direccionar a uno de los bits directamente usando su dirección o su nombre simbólico.
Ejemplo de uso del bit “Always TRUE” en Siemens.
Uso en Mitsubishi
Necesitamos ingresar la dirección del Special Relay (SM), GX Works3 ya saque que ese bit tiene una función particular y pone su “nombre” como comentario.
Ejemplo de uso del bit “Always ON” en Mitsubishi.
Diferencias de filosofía
Aunque cumplen el mismo propósito, hay una diferencia de enfoque:
Siemens apuesta por la configuración flexible. Tú defines qué memoria se comportará como “pulsante” o qué dirección usarás como indicador de estado.
Mitsubishi se va por lo predefinido y directo. Ya sabes de memoria que SM400 siempre será “always true” y que SM413 parpadea con una frecuencia de 0.5 Hz.
Ambos enfoques tienen ventajas. En Siemens puedes organizar tu proyecto a tu manera; en Mitsubishi no pierdes tiempo configurando nada y basta con recordar los códigos principales.
Conclusión
Tanto Siemens como Mitsubishi ofrecen mecanismos internos para conocer el estado del PLC y generar pulsos de reloj. La diferencia es puramente de filosofía: configurable vs. predefinido.
Saber hacer esta traducción mental es fundamental para cualquier ingeniero que trabaje con más de un fabricante. Y al final, entender que un System Memory Bit de Siemens no es tan distinto de un Special Relay de Mitsubishi nos permite hablar el “idioma común” de la automatización.
Es el simulador de software que emula únicamente la CPU de un PLC S7-1200 o S7-1500 (sin módulos de campo ni acceso a OPC UA ni funciones de red avanzadas). Viene integrado con TIA Portal V19 y permite validar lógicas de programa antes de ir al equipo físico.
Funcionalidades principales
Carga y ejecución de bloques PLC – Emula la CPU del S7-1200/S7-1500 para ejecutar tus bloques (OB, FC, FB, DB). – Soporta stepping, breakpoints y watch tables para depuración.
Validación de lógicas básicas – Observación de variables, flags y temporizadores en tiempo real. – Edición “on-the-fly” (cambios en bloques sin recompilar todo el proyecto).
Simulación de E/S digitales – Emula entradas y salidas digitales (no módulos analógicos ni contadores rápidos de hardware reales). – Permite forzar valores de entrada manualmente.
Interacción con HMI WinCC Runtime – Conecta tu Runtime de WinCC (no Advanced) a la CPU simulada vía PROFINET, para probar pantallas.
Realtime Information Backbone (RIB) es un producto de la familia SIMATIC de Siemens diseñado para intercambiar información en tiempo real entre el PLC y aplicaciones del usuario escritas en C++, que son ejecutadas en el sistema operativo Linux. Está disponible solo en aquellos modelos de PLCs donde el sistema operativo del PLC está gestionado por el Hypervisor de SIMATIC y que además comparten el mismo sistema con una instalación del SO Linux. Aunque en realidad también puede ser usado para intercambiar información entre aplicaciones de Linux, donde ningún PLC interviene, usando exclusivamente POSIX shared memories de Linux.
Real-time concept – imagen obtenida del manual de operación del Software Controller. Esta imagen muestra una Industrial PC, su HW, y como este es asignado al SO y al CPU por el Virtual Machine Manager (VMM/Hypervisor).
Los modelos de PLCs que tienen la opción de usar este software son:
S7‑1500 Software Controller (CPU1505SP, CPU1507S y CPU1508S en sus versiones standard y failsafe) en conjunto con el SO Linux.
El intercambio de información entre el PLC y las aplicaciones de Linux se da a través de memorias compartidas gestionadas por el SIMATIC Hypervisor, directamente accesibles desde Linux y desde el PLC, siendo así el tiempo de lectura/escritura muy corto.
El software RIB consta de una aplicación central (RIB_App) encargada de coordinar a las aplicaciones participantes del ecosistema que intercambian datos entre si, y una librería de soporte (RIB Support Library) que es integrada (linked) a las aplicaciones escritas por el usuario en el lenguaje C++. Esta librería cuenta con clases que se pueden instanciar y métodos de estas clases que se pueden llamar, con el objetivo de hacer una aplicación que se comunique con la RIB_App para obtener o dar información acerca de variables (nombre, tipo, dirección en memoria, etc.), y leer o escribir/actualizar estas variables.
Existe también la posibilidad de usar la RIB Support Library en aplicaciones escritas en Python usando un el paquete cppyy, además de que existe también un wrapper para poder usar esta librería en aplicaciones escritas en C.
El ecosistema RIB consta de una aplicación central (RIB_App) que recibe mensajes de las aplicaciones que integran de alguna forma la RIB Support Library. Estos mensajes son emitidos en diferentes eventos durante el tiempo de ejecución de una aplicación, por ejemplo al iniciar y al terminar, con el objetivo de informar que está pone a disposición datos para que sean leídos por aplicaciones interesadas, y también para avisar que una aplicación requiere de ciertos datos y que espera un mensaje para saber de donde leerlos. La RIB_App almacena en su base de datos las aplicaciones en ejecución y los datos que ofrecen y/o necesitan y avisa a las aplicaciones conforme estos datos están disponibles o dejan de estarlo. No existe intercambio de mensajes entre aplicaciones del usuario. Las aplicaciones unicamente leen directamente de la dirección donde están las variables de interés y escriben en memoria las variables que comparten.
Perspectiva general del sistema – Imagen obtenida del manual de programación del RIB.
¿Qué tipo de aplicaciones tiene?
Las aplicaciones en las cuales el Realtime Information Backbone puede ser de utilidad son bastas, a continuación algunos ejemplos.
El PLC al tener acceso directo a variables del proceso automatizado puede recolectar los valores de estas y compartirlos con una aplicación de Linux que se encargue de acondicionar los datos y meterlos en una base de datos para posteriormente analizarlos usando técnicas de Data Mining. El objetivo de este análisis puede ser hacer más eficiente el proceso, diagnosticar fallas, identificar el momento más adecuado para realizar mantenimientos preventivos, etc.
Al suceder el intercambio de información entre el PLC y el SO Linux en tiempo real, estas variables pueden ser procesadas en una aplicación en Linux, y al PLC se le pueden compartir valores que repercutan directamente en el proceso automatizado.
Los PLCs de diferentes vendedores tienen siempre un limitado número de protocolos de comunicación, al tener las variables disponibles en Linux, estas pueden ser acondicionadas para ser compartidas con sistemas que usen algún protocolo de comunicación común.
Esta opción de TIA Portal está disponible desde hace ya varias versiones (V15) del software para configurar/programar los PLCs de Siemens, y es seleccionable a la hora de realizar la instalación.
El objetivo de esta opción es permitir que varios usuarios puedan contribuir de manera simultanea al desarrollo del software de control que el PLC ejecuta.
Existe desde las épocas de Step 7, antes de que TIA Portal existiera, la posibilidad de que varios usuarios se conecten al mismo PLC de forma simultanea y desarrollaran o hicieran cambios online. Esto, en mi experiencia propia, no es una situación deseada ya que fácilmente se puede llegar a ocasionar caos entre las versiones que cada programador tiene en su PC/PG y la versión central del PLC.
TIA Project-Server tiene como objetivo el permitir el desarrollo de software de control de un PLC de manera grupal y siempre offline, es decir, sin conexión al PLC. La forma más adecuada de ir probando lo que se va desarrollando entonces sería ejecutarla en un PLC aparte, o en el PLC Sim, lo que es económicamente más conveniente.
Algo similar a como se desarrolla software de otra naturaleza, como el firmware de un teléfono móvil, un navegador de internet o un sistema operativo. Estos softwares cuentan con diferentes funcionalidades que hasta cierto punto son independientes unas de otras, dando cabida a que existan grupos de desarrolladores de software que se enfocan en solo una de las múltiples funcionalidades del software.
La analogía sin embargo no es completamente exacta. Existen diferencias entre desarrollar software de manera grupal para un PLC y desarrollar una aplicación “convencional”.
Generalmente existe un ambiente de desarrollo (IDE) con el cual se pueden crear, editar, debuggear, etc. los archivos que forman parte del código fuente de una aplicación (Visual Studio, Eclipse, etc.) y de manera independiente existe un software y una infraestructura encargada de almacenar de manera central los archivos que conforman un proyecto de software y además de manejar las distintas versiones del software a lo largo del proceso de desarrollo de este (Git – github, TFS, Tortoise – SVN, etc. ). En el caso de TIA Portal, TIA Portal es el único software involucrado. TIA Portal es el encargado de comparar y sincronizar los bloques entre los usuarios del software, además también de crear un proyecto multiusuario y de administrarlo.
TIA Project-Server está enfocado al desarrollo del software de control de un PLC de manera grupal y no a la configuración de Hardware, que también forma parte integral del un proyecto de TIA Portal. TIA Project-Server tiene entonces la limitante de que cambios en la configuración de HW se tienen que realizar directamente de manera central. Es decir, en el proyecto común que sirve como base para todos los desarrolladores.
EL tipo de proyectos para los cuales la opción TIA Project-Server puede ser interesante, son proyectos grandes, que involucran una máquina compleja, donde además se recopilan datos para transferirlos a un sistema que los procesa. Usar esta funcionalidad para programar una máquina pequeña y simple, solo podría añadir complejidad de forma innecesaria.
El siguiente video muestra como configurar de la manera más básica un proyecto multiusuario y como usar esta funcionalidad para desarrollar el software de control de un PLC en conjunto con varios programadores.
Para que el desarrollo de un proyecto sea llevado a cabo por varios usuarios, es necesario dividir la infraestructura en varias computadoras PC/PGs, estos son los dispositivos que cada programador posee para desarrollar el software de un PLC. El siguiente video explica como se configura y funciona esto.
