Problema en Tecla de Función de HMI Siemens

 

SI-OP-001

    A pesar del paso de los años y de la evolución en la tecnología de los paneles Siemens, sigue repitiéndose un problema relacionado con la función “Activar bit mientras tecla pulsada”. Este detalle, que parece sencillo, puede ocasionar fallas críticas en la operación de máquinas y procesos industriales, lo que genera confusión tanto en programadores como en operadores.

Caso reciente en planta

    Hace unos días fui contactado por una planta donde reportaban que no podían cambiar el modo de operación de una máquina.

• Equipo involucrado: PLC S7-300 con un panel gráfico Siemens.

• Situación: El cambio de modo debía hacerse desde la pantalla del panel, pero no se efectuaba.

    Al conectar mi laptop al PLC para monitorear los bits de cambio de modo, observé que uno de los bits enviados desde el panel se mantenía siempre activado. Al forzarlo manualmente de “1” a “0”, el bit respondía bien, pero al volver a pulsar la tecla en el panel, el bit quedaba nuevamente activado de forma permanente.

     Esto confirmaba que el problema provenía del panel de operador y no del PLC.

Análisis de la falla

    El programador del panel revisó el proyecto y me mostró que la tecla en cuestión tenía asignada la función “Activar bit mientras tecla pulsada”.

     En teoría, el comportamiento debería ser:

• Mientras la tecla esté presionada → el bit se activa.

• Al soltar la tecla → el bit debería desactivarse.

    Sin embargo, la tecla quedaba “enclavada” y mantenía el bit en estado “1” aun cuando ya no estaba siendo pulsada.

Experiencia anterior con ProTool

    Esta no era la primera vez que veía este error. Años atrás, me ocurrió algo similar con un panel gráfico OP 37 programado con ProTool v6.0.

    En ese proyecto, asigné la función “Activar bit mientras tecla pulsada” a diferentes teclas para arrancar y parar motores. Inicialmente funcionó bien, pero con el tiempo los paneles comenzaron a presentar fallas:

• Los motores quedaban encendidos permanentemente.

• En otros casos, no era posible arrancarlos porque la señal de paro permanecía activa.

    El problema era exactamente el mismo: el panel no detectaba que la tecla había sido liberada.

     La solución fue implementar en el PLC un temporizador de autodesactivación, asegurando que la señal se apagara después de algunos segundos.

Situación heredada en WinCC Flexible

    Hoy en día ya no se utiliza ProTool, sino WinCC Flexible, herramienta que sustituyó al software anterior y que acompaña a los paneles Siemens más modernos. Sin embargo, el problema persiste:

• Dos softwares diferentes: ProTool y WinCC Flexible.

• Dos generaciones de paneles diferentes.

• Dos programadores diferentes.

• Un mismo problema con la misma función.

    Esto demuestra que no se trata de un error de programación aislado, sino de un fallo intrínseco en cómo Siemens maneja esta función en sus paneles.

Recomendaciones para evitar el problema

    Dado que Siemens no ha corregido este detalle, y nos toca remediar la situación, lo más prudente es:

     Tomar un cautín para repara la tecla, tal como se ilustra... es broma...

    Ya serio: 

1. Evitar el uso de la función “Activar bit mientras tecla pulsada” en los paneles.

2. Implementar lógica de autodesactivación en el PLC:

   • Programar temporizadores o condiciones que obliguen a que los bits provenientes del panel se apaguen tras cierto tiempo.

3. Monitorear los bits en el PLC para identificar rápidamente si algún bit queda enclavado.

4. Documentar la programación del panel para que futuros técnicos sepan que esta función puede causar problemas.

Para concluir...

    La falla de los bits enclavados al usar la función “Activar bit mientras tecla pulsada” se ha presentado en diferentes generaciones de paneles Siemens y con distintos softwares de programación.

     Aunque la tecnología ha avanzado, el problema sigue sin resolverse. Por ello, la mejor estrategia es prevenir desde el diseño del PLC, asegurando que las señales críticas no dependan exclusivamente de esta función del panel.

    En el caso reciente, la solución fue sencilla: implementar la desactivación automática de los bits luego de cierto tiempo. Con ello, la máquina recuperó su funcionalidad normal.

Una lección importante: confiar demasiado en el panel puede traer dolores de cabeza; siempre es mejor que el PLC tenga el control de la lógica de seguridad y operación

Read More

Carga de Programa a CPU S5-135U desde Memory Card

 S5-135-001

    En muchas empresas aún nos encontramos con los llamados PLC’s “dinosaurios”, como los Siemens S5, que aunque obsoletos y difíciles de manipular, siguen presentes en numerosos procesos industriales. Su sola presencia puede desalentar a los técnicos debido a la complejidad que implica trabajar con ellos. Sin embargo, en la mayoría de los casos no queda otra alternativa más que familiarizarse con estos equipos y aprender a mantenerlos operativos.

    Uno de los problemas más frecuentes con la CPU S5-135U es la pérdida del programa en la memoria RAM, aun cuando cuenta con batería de respaldo. Cuando esto ocurre, es necesario volver a cargar el programa, ya sea mediante conexión con PC o a través de una Memory Card.

    En este documento se explica el procedimiento para cargar el programa desde una tarjeta de memoria directamente a la CPU.

Requisitos previos

• Contar con una Memory Card que ya tenga cargado el programa.

• Identificar la ranura correspondiente en la CPU para insertar la tarjeta.

• Familiarizarse con los selectores de la CPU:

  • Run/Stop

  • Overall Reset

Procedimiento de carga desde Memory Card

1. Insertar la Memory Card en la CPU en la ranura correspondiente.

2. Colocar el selector en la posición de Overall Reset y mantenerlo presionado.

3. Mientras lo mantenemos, mover el selector de Run-Stop a la posición Stop.

4. Sin soltar el Overall Reset, colocar el selector de Run-Stop en la posición Run.

5. Finalmente, regresar el selector a Stop y soltar en este momento el Overall Reset.

✔ Si el procedimiento se realizó correctamente, el LED de Stop permanecerá encendido de forma fija (sin parpadear).

Consideraciones importantes

• Con este procedimiento se borra por completo el contenido de la memoria RAM de la CPU.

• Tras el borrado, el sistema operativo de la CPU transfiere automáticamente el programa de la Memory Card hacia la RAM.

• Una vez finalizada la carga, el programa ya está disponible en la CPU.

Arranque del sistema

1. Colocar el selector Run-Stop en la posición Run.

2. Verificar que el LED de Run se encienda en verde de forma permanente.

    Esto indica que la CPU ha iniciado correctamente y que el programa de la Memory Card fue cargado de manera exitosa.

    Aunque los PLC Siemens S5-135U son equipos obsoletos y poco amigables, aún es posible mantenerlos operativos si se conoce el procedimiento adecuado. La carga desde una Memory Card resulta una alternativa práctica y rápida para recuperar el programa perdido en la CPU, evitando paradas prolongadas de producción.

Read More

Cómo Grabar los Bloques de Datos en FM-354

 

  

SI-300-005

    La primera vez que me tocó programar una tarjeta FM-354 carecía de muchos conocimientos básicos sobre este módulo. El desafío era mayor porque debía programarla en un plazo de cinco días para una máquina cuya función era colocar botes de producto dentro de sus cajas.

    Ya antes había trabajado con Simodrives Siemens conectados a un PLC S7-300 mediante red Profibus, lo que me daba una base mínima. Sin embargo, este nuevo proyecto representaba una prueba exigente: ¿sería posible programar la FM-354 desde cero en menos de una semana y, además, lograr que la máquina funcionara correctamente?

    El panorama era complejo:

• Poco tiempo disponible.

• Desconocimiento total de la FM-354.

• Alta presión por parte del cliente.

• Riesgo de incumplimiento, retrasos en producción y posibles consecuencias contractuales.

    Aun así, acepté la responsabilidad. La misión era clara: la máquina debía funcionar a como diera lugar.

Primeros pasos: documentación y estudio

    Con el reto encima, lo primero que hice fue conseguir el manual de la FM-354 en internet. Como suele suceder con los manuales, la información estaba explicada de manera elemental, pero suficiente para trazar una ruta.

    A partir de esa investigación descubrí que la FM-354 es una tarjeta diseñada para controlar servomotores en tareas de posicionamiento, exactamente lo que necesitaba el proyecto.

Consideraciones de hardware

    Antes de iniciar con la programación, tuve que aclarar varios aspectos relacionados con el hardware:

• Señales digitales que maneja la tarjeta.

• Ubicación de la FM-354 dentro del rack del PLC.

• Tipos de encoders compatibles y su forma de conexión.

• Envío de señales de control al servo-drive.

    Tras revisar los componentes, confirmé que:

• El encoder era compatible.

• La señal de set-point de velocidad (–10V … 0 … +10V) era adecuada para el servo-drive.

    Con esto, la primera etapa de validación estaba superada.

Instalación del software y configuración inicial

    Con los componentes montados y conectados, el siguiente paso fue instalar el software de la FM-354, que se integra como complemento del Step 7. Utilicé la versión 5.4.

    Luego:

1. Descargué el hardware del PLC conectando la CPU vía puerto MPI, usando un PC-Adapter y una laptop Acer.

2. En el proyecto, abrí el Hardware Configuration.

3. Seleccioné la FM-354, lo que desplegó una ventana de parametrización.

4. Tras modificar parámetros, intenté transferir los bloques de datos a la FM.

    Cuando los parámetros eran correctos, la transferencia se completaba sin errores. Pero si había inconsistencias, aparecía un mensaje de fallo que obligaba a corregir la configuración.

Problema recurrente: pérdida de parámetros

    En esta etapa surgió un obstáculo inesperado. Varias veces notamos que, aunque la transferencia de datos a la FM era correcta, los parámetros se perdían al apagar el PLC. Al reiniciar, la FM aparecía sin las modificaciones guardadas.

   Este comportamiento no estaba documentado en el manual, lo que aumentó la frustración y la incertidumbre.

Procedimiento de solución

     Finalmente, tras varios intentos, descubrimos un procedimiento que permitió que la FM-354 conservara los parámetros después de apagar y encender el sistema:

1. Conectarse al PLC por el puerto MPI y abrir la aplicación de la FM-354.

2. Modificar los parámetros requeridos.

3. Colocar el selector de la CPU en posición “Stop”.

4. Transferir los bloques de datos a la FM.

5. Desenergizar únicamente la FM por unos segundos y volver a energizarla.

6. Al energizarla, la CPU indicará una falla con el LED “SF” encendido.

7. Cambiar el selector de la CPU a posición “Run”.

    Luego de este procedimiento:

• Se reinició la comunicación con la FM.

• Se verificó que los parámetros modificados permanecían almacenados.

• Tras apagar y energizar todo el tablero, comprobamos que la FM conservaba los cambios.

    Aunque fue un trabajo maratónico y lleno de presión, el proyecto fue concluido con éxito en el tiempo establecido. La máquina quedó operativa, presentando solo detalles menores que posteriormente fueron corregidos.

    La experiencia dejó varias lecciones importantes:

• La importancia de estudiar a fondo los manuales técnicos.

• La necesidad de validar siempre la compatibilidad del hardware.

• La utilidad de la prueba y error frente a problemas no documentados.

• Y, sobre todo, que los retos técnicos, por más complejos que parezcan, pueden resolverse con disciplina y método.

Read More

Otro OB útil en los PLC's S7-300

 

SI-300-004

    Como comentaba en el post precedente, al programar un PLC desde cero solemos iniciar sin muchas consideraciones de seguridad. El entusiasmo por ver la CPU en "Run" y funcionando a la perfección nos lleva a escribir líneas de código sin detenernos demasiado en los detalles. Estos, pensamos, podrán resolverse después de tener lista la estructura principal de la lógica de control.

    Además, muchas veces trabajamos contra el reloj: la programación que controla toda una línea de producción debe estar lista el lunes… y hoy es viernes. La presión por entregar a tiempo puede llevarnos a omitir detalles importantes. Y es en estas condiciones donde se gestan errores que más tarde pueden provocar que la CPU se detenga y se vaya a "Stop".

El escenario real: prisas, fatiga y errores

    Es domingo y el programa apenas toma forma. El cansancio nubla la mente y la concentración disminuye. Lo que al inicio parecía claro y sencillo ahora se vuelve confuso. Surgen dudas y hasta llegamos a pensar si hubiera sido mejor seguir la sugerencia del jefe, aunque fuese menos elegante.

    En ese estado de fatiga ocurren errores mínimos pero críticos. Por ejemplo, al escribir en el programa que queremos leer la dirección DBW48 del bloque de datos DB110, por descuido tecleamos DB119. Una diferencia aparentemente insignificante (confundir un "0" con un "9"), pero suficiente para desencadenar un problema serio.

    El editor de programas del Simatic Manager no detecta el error en esta etapa, así que seguimos escribiendo más líneas hasta completar la rutina deseada. Convencidos de que todo funcionará, descargamos el bloque de programa al PLC… y de inmediato la CPU se va a "Stop".

Diagnóstico del fallo

    Tras la frustración inicial, acudimos al búffer de diagnóstico de la CPU y encontramos la causa del problema: aparece un mensaje donde se indica que no se encontró el OB121.

    Aquí es donde entra en juego este bloque de organización: el OB121 es llamado por la CPU cuando se comete un error de programación, como el ejemplo descrito. Si este OB está cargado en la memoria del PLC, la CPU no se va a "Stop" automáticamente. En cambio, si no existe en memoria, el resultado inevitable es que la CPU abandone el modo "Run" y se detenga.

El papel del OB121

    El OB121 actúa como un “salvavidas” para los errores de programación:

• Prevención de parada inesperada: si el bloque está cargado, evita que la CPU entre en modo "Stop" ante un error de código.

• Persistencia del error: aunque la CPU siga en "Run", el error sigue existiendo y debe corregirse manualmente en el programa.

• Facilidad de implementación: basta con crear el OB121 en el Simatic Manager y transferirlo a la CPU. No es necesario añadir instrucciones dentro del bloque; con que exista en memoria es suficiente para evitar que la CPU se detenga.

Para concluir...

    El OB121 es fundamental cuando programamos bajo presión o en condiciones poco favorables, donde los errores de escritura y referencia a bloques inexistentes pueden ocurrir fácilmente. Su presencia en la CPU asegura que ésta no se detenga por un fallo de programación, evitando comprometer el arranque de una máquina o interrumpir un proceso productivo.

    Sin embargo, debe quedar claro que el OB121 no corrige el error, sólo lo enmascara para que la CPU siga en ejecución. La responsabilidad final es del programador, quien debe revisar el código, localizar y eliminar el fallo.

    En resumen, crear y cargar el OB121 en el PLC no requiere esfuerzo adicional, pero puede marcar la diferencia entre un proyecto estable y una CPU detenida en el peor momento. Con él, podremos programar con mayor confianza, sin olvidar que la verdadera solución siempre será una programación clara, organizada y libre de errores.

Read More

Prevenir que las CPU's S7-300 se vayan a Stop por error de I/O

 SI-300-003

    En la programación de PLC Siemens de la familia S7-300, una de las tareas más comunes es el diseño de bloques de programa, la integración de equipos, la asignación de entradas y salidas, el uso de temporizadores y banderas, entre otros recursos.

    Durante esta etapa de diseño es normal cometer errores de programación que pueden ocasionar que la máquina no funcione como se esperaba o, peor aún, que la CPU entre en modo "Stop".

• Algunos errores se detectan en la fase de programación.

• Otros sólo aparecen al cargar el programa en la CPU y ejecutarlo.

• En casos graves, la CPU se detiene al no poder procesar instrucciones inválidas.

    Un ejemplo típico de este problema ocurre con la ausencia del OB122, el cual cumple una función clave para evitar que la CPU se bloquee por errores de direccionamiento en entradas o salidas.

Caso típico

    Hace poco recibí la llamada de un cliente con una CPU S7-300 que se detenía constantemente.

    Al revisar el búffer de diagnóstico, el mensaje indicaba que faltaba el bloque OB122.

    Esto ocurre porque:

• El OB122 no estaba cargado desde la etapa inicial de programación.

• El programa intentaba acceder a direcciones de entradas o salidas que no existían físicamente en el hardware instalado.

¿Qué es el OB122 y para qué sirve?

    El OB122 (Organization Block 122) es un bloque de sistema que el programador puede incluir como medida de precaución.

    Su función principal es:

• Evitar que la CPU se detenga en modo "Stop" cuando intenta acceder a una dirección de entrada (I) o salida (O) inexistente en el hardware.

    En la práctica:

• Cuando programamos off-line, el software no marca error aunque usemos direcciones que no correspondan a ninguna tarjeta física.

• El problema surge al descargar ese programa en la CPU: si intenta leer o escribir en una dirección inexistente, la CPU entra inmediatamente en Stop, a menos que exista el OB122.

    Ejemplo:
     Si en el programa se incluye la instrucción para leer desde la dirección PIW312, pero en el hardware no existe ningún módulo asociado a esa dirección, la CPU se detendrá salvo que tenga cargado el OB122.

Cómo implementar el OB122

     El procedimiento es sencillo:

1. En el Simatic Manager, crear el bloque OB122.

2. Descargarlo directamente a la CPU.

3. No es necesario escribir ninguna instrucción en su interior. Incluso puede enviarse vacío, sin segmentos.

    Con solo estar presente en la CPU:

• El sistema reconoce que el OB122 existe.

• Ante un error de acceso a direcciones I/O inexistentes, la CPU invoca este OB en lugar de detenerse.

• El estado operativo permanece en Run, evitando la interrupción del proceso.

Consideraciones importantes

    Aunque el OB122 evita que la CPU se detenga, no elimina el error.

• El acceso a una dirección inexistente seguirá ocurriendo.

• El diagnóstico mostrará que la CPU está en Run, pero el error no aparecerá listado como falla grave.

    Esto significa que:

• La máquina puede seguir operando, pero con el riesgo de pérdida de señales reales.

• Se debe revisar el hardware o el programa para corregir el problema de fondo.

Situaciones donde se activa el OB122

    El OB122 puede ser invocado en los siguientes casos:

1. Durante la programación y pruebas

   • Se escriben líneas de código con direcciones de entradas o salidas inexistentes.

   • Al descargar el programa, la CPU evita el "Stop" gracias al OB122.

2. En operación normal de la máquina

   • Tras meses o años de funcionamiento estable, puede ocurrir un corto circuito o daño en alguna tarjeta de E/S.

   • La CPU ya no reconoce la tarjeta y, al no poder acceder a sus direcciones, se genera la condición para llamar al OB122.

Para finalizar...

    El OB122 es un recurso indispensable en la programación de PLC Siemens S7-300 para:

• Evitar que la CPU entre en modo "Stop" por errores de direccionamiento en entradas o salidas inexistentes.

• Permitir que la máquina continúe en operación, mientras se diagnostica y corrige el problema real.

    Recomendaciones:

• Siempre cargar el OB122 desde la etapa inicial de programación.

• Utilizarlo como medida preventiva en proyectos nuevos y en sistemas en operación.

• Recordar que el OB122 no soluciona el error: únicamente evita la detención de la CPU, por lo que siempre será necesario revisar el hardware o la programación para identificar la causa.

    En conclusión, incluir el OB122 en la CPU es una práctica sencilla, pero de gran impacto, para garantizar la continuidad operativa de los procesos industriales controlados por PLC.

Read More

Cómo respaldar programa en Flash en PLC's Siemens S7-300

 SI-300-002

    En esta línea de respaldos de programa en memoria flash, describiremos la forma de hacerlo en las CPU's de la línea S7-300 de los PLC's Siemens.

    Como requisitos para hacer este respaldo, tenemos que estar conectados a nuestra CPU, y ésta ha de tener su cartucho de memoria flash ya insertado. Una vez que hemos hecho la conexión con nuestro software Simatic Manager, estamos listos para iniciar el procedimiento. Por supuesto, esto lo podemos hacer sólo si la máquina no está en operación o en producción, ya que por unos momentos será necesario pasar a "Stop" la CPU. Así que, cuidado al realizar este respaldo. De igual forma, al terminar el proceso de carga en la memoria flash, cuidemos que al poner el sistema en "Run", no haya nadie interviniendo el equipo, ya la máquina puede arrancar ciertos equipos de improviso, con lo cual podemos causar accidentes y sus consecuentes daños materiales o personales. No está de más tomar nuestras precauciones.

    Bien, ahora estamos frente a nuestra PC, con nuestro Simatic Manager (Administrador Simatic) abierto, así como también tenemos abierto el programa de la CPU a la que estamos conectados.

1. Vamos a la opción "Sistema de destino" de nuestro menú principal del Simatic Manager.
2. En la lista de submenús, seleccionamos haciendo click en "Cargar programa de usuario en Memory Card", como se muestra a continuación:

3. Una vez que seleccionamos esta opción, el programa examina el sistema y evalúa si es posible la transferencia del programa a la memoria flash. Si no hay inconsistencias, nos aparecerá una ventana que nos preguntará si estamos seguros de realizar la carga, a lo que daremos click en "Sí" para continuar. De lo contrario, podemos cancelar el proceso seleccionando la opción "No":

4. Por si fuera poco, luego de que damos click en "Sí", nos aparece un nuevo cuadro de diálogo en el que se nos aclara que para realizar la carga del programa, la CPU necesita cambiar al modo "Stop". De estar listos, oprimimos la opción "Sí"...

    ¡Y con esto dejamos muerto nuestro PLC, así como dejamos muerta nuestra máquina! Claro, esto sólo dura unos cuantos segundos, mientras el Simatic Manager realizar su labor de borrar la CPU y cargar el programa a la flash.

5. Cuando el Simatic Manager concluye su proceso, de improviso nos aparece una ventana que nos informa que la carga del programa ya fue realizada, por lo que podemos proceder a rearrancar nuestro PLC al poner la CPU en modo "Run". Si, luego de analizar que no se corre riesgo alguno, damos en "Sí" para mandar la CPU a ejecutar su nuevo programa, y con este paso finalizamos.


Fue sencillo, no les parece?

Read More

Respaldo del programa de los PLC's en memoria Flash

  

TyC-007

 

    En un tema anterior hablamos sobre el papel de las baterías en las CPU’s de los PLC como medio para conservar los programas en memoria RAM. Sin embargo, este método tiene una desventaja: si la batería se agota y la CPU pierde alimentación eléctrica, el programa desaparece irremediablemente. Para evitar este tipo de situaciones críticas, existe una alternativa mucho más segura: las memorias Flash.

    Estas memorias permiten almacenar el programa de manera permanente, sin depender de la batería, garantizando que la lógica de control esté siempre disponible cuando la CPU se energice.

Limitaciones del respaldo con batería

• Cuando la batería está en buen estado, la CPU mantiene su programa incluso sin alimentación eléctrica.

• Si la batería está agotada y se corta la energía, el programa se pierde totalmente.

• Este riesgo hace que confiar únicamente en la batería sea insuficiente en aplicaciones críticas.

    Por esta razón, además de respaldar en medios externos (como guardar copias en computadora o discos), se recomienda el uso de memorias Flash.

Ventajas de las memorias Flash

    Las memorias Flash poseen características que las hacen ideales para respaldo:

• Conservan la información grabada sin importar el estado de la batería o la alimentación eléctrica.

• Sólo pueden borrarse o modificarse mediante procedimientos eléctricos controlados (no por desconexión de energía).

• Una vez grabado el programa, la información es estable y puede almacenarse por largos periodos sin alteración.

• Son portátiles: pueden retirarse, transportarse y reinstalarse fácilmente.

⚠️ Nota: Si se someten a golpes, altas temperaturas o condiciones destructivas, podrían dañarse parcial o totalmente.

Consideraciones al usar memorias Flash

     Al decidir respaldar un programa en una memoria Flash, deben tomarse en cuenta los siguientes aspectos:

1. Compatibilidad: Cada fabricante y modelo de CPU requiere un tipo específico de memoria Flash. Es fundamental elegir la adecuada.

2. Capacidad: Los programas grandes necesitan memorias de mayor tamaño. Seleccionar una memoria con suficiente capacidad es clave.

3. Un solo programa por memoria: Aunque la memoria tenga más espacio libre, sólo puede almacenar el programa de una CPU.

4. Respaldo previo: Antes de instalar la memoria Flash en la CPU, es importante guardar el programa en una computadora. Esto evita riesgos de bloqueo o pérdida durante la instalación.

5. Procedimiento de carga: La memoria Flash se instala en la CPU y luego se carga el programa siguiendo las instrucciones del fabricante.

6. Autonomía: Una vez almacenado el programa en la memoria Flash, este no se borrará al cortar energía ni al agotarse la batería.

7. Recuperación automática: Si la memoria RAM de la CPU pierde el programa, al reenergizarse, la CPU copiará automáticamente el contenido de la memoria Flash a la RAM. Este proceso es casi imperceptible.

Limitaciones de la restauración automática

    Aunque el programa lógico siempre estará disponible, hay un detalle importante:

• La memoria Flash sólo transfiere el programa de usuario (lógica).

• Los datos dinámicos de la máquina se pierden al restaurar desde la Flash.

    Esto incluye:

• Conteo de piezas.

• Valores de temporizadores y contadores.

• Set-points configurados por el operador.

• Variables en bloques de datos.

    En consecuencia, tras una restauración desde la Flash, todos los valores regresan al estado inicial con el que se grabó la memoria.

    Ejemplo:
     Si en la Flash el programa está configurado para lubricar cada 18 horas, pero la máquina había trabajado 10 horas y debía lubricar en 2 horas más, esa información se perderá. Al restaurarse, la CPU volverá al valor de 18 horas.

    Lo único que se garantiza permanentemente es la lógica del programa.

Conclusión

    El uso de memorias Flash en PLC’s es una práctica altamente recomendable para asegurar la disponibilidad del programa de usuario, incluso cuando las baterías fallan o se corta la energía.

• Ofrecen respaldo seguro y permanente.

• Evitan pérdidas de programación costosas o críticas en producción.

• Sin embargo, no sustituyen la importancia de realizar respaldo externo en computadora y de considerar que los datos dinámicos siempre se perderán al restaurar desde la Flash.

    En resumen, las memorias Flash son una herramienta confiable y complementaria a las baterías, que garantiza la continuidad operativa de los sistemas automatizados.

Read More

Cambio de Batería en las CPU's de los PLC

  TyC-006

    Al trabajar con PLC Siemens y, en particular, con la CPU S7-315, debemos considerar un aspecto crítico: este modelo, al igual que muchos otros de distintas marcas y gamas, requiere de una batería para conservar el programa en la memoria RAM.

    El descuido de este detalle puede ocasionar la pérdida total del programa y, en consecuencia, la detención de la máquina o del proceso que controla. Por ello, es fundamental conocer cuál es la función de la batería, cuándo reemplazarla y cómo hacerlo sin riesgos.

Función de la batería en la CPU

    Las CPU que requieren guardar el programa de usuarios en memoria RAM necesitan una fuente constante de alimentación para mantener almacenado el programa. Recordemos:

• La memoria RAM es volátil, es decir, pierde la información si no recibe energía.

• La alimentación de la RAM puede provenir de dos fuentes:

  • La fuente de poder del tablero.

  • La batería interna de la CPU (cuando el tablero se encuentra apagado).

    De esta manera, la batería actúa como respaldo energético cuando no hay tensión en el tablero.

Ejemplo práctico

• Si instalamos una CPU nueva y cargamos un programa, pero no insertamos la batería, al desenergizar el tablero el programa se borrará.

• Si mantenemos la CPU energizada, podemos incluso retirar la batería sin perder el programa. Sin embargo, si quitamos la batería y apagamos el tablero, el programa se perderá irremediablemente.

Indicadores de batería agotada

    La mayoría de las CPU que emplean baterías incluyen un LED indicador (generalmente de color rojo) que advierte cuando la batería está agotada.

     Cuando este LED se enciende, es indispensable reemplazar la batería lo antes posible para evitar la pérdida del programa.

Procedimiento adecuado para reemplazar la batería sin perder el programa

     El cambio de batería es un proceso sencillo, pero requiere seguir ciertas precauciones:

1. Verificar el estado de la CPU:

   • Confirmar que el LED de batería agotada está encendido.

   • Mantener energizado el tablero en todo momento.

2. Respaldar el programa:

   • Antes de cualquier intervención, realizar una copia de seguridad del programa y almacenarla en un lugar seguro.

3. Conseguir la batería adecuada:

   • Asegurarse de que la batería sea del modelo y voltaje indicado por el fabricante.

4. Reemplazar la batería:

   • Con el tablero energizado, retirar la batería agotada.

   • Insertar inmediatamente la batería nueva.

5. Verificar resultado:

   • Confirmar que el LED de batería agotada se apague.

   • Comprobar que la CPU y la máquina continúan trabajando normalmente.

Cómo borrar el programa intencionalmente cuando se requiera restablecer la CPU

    En algunos casos puede ser necesario eliminar el programa almacenado en la CPU:

• Porque se cargará un nuevo programa totalmente distinto.

• Porque se reutilizará la CPU en otra máquina.

    El procedimiento es muy simple:

1. Desenergizar el tablero.

2. Retirar la batería de la CPU.

3. Esperar unos segundos.

4. Volver a energizar la CPU → ésta ya no contendrá ningún programa.

Recomendaciones prácticas

• Respaldar siempre el programa de todas las CPU en las máquinas.

• Llevar un control de vida útil de cada batería.

  • Generalmente, los fabricantes indican entre 1 y 2 años de duración.

• No usar baterías de voltajes distintos a los recomendados, ya que esto puede dañar la memoria y obligar a reemplazar la CPU completa.

• Consultar siempre el manual del fabricante, ya que las indicaciones específicas pueden variar según el modelo.

Nota ecológica

    Las baterías, incluso las agotadas, no deben tirarse a la basura común.

     Se deben depositar en contenedores especiales para baterías usadas o entregarlas a las entidades responsables de su reciclaje y disposición segura.

Finalmente... 

El cuidado de la batería en una CPU Siemens S7-315 (y en general, en cualquier PLC que emplee RAM con respaldo) es vital para garantizar la continuidad operativa de las máquinas y procesos industriales.
Reemplazar la batería siguiendo los pasos correctos asegura que el programa se conserve intacto, evitando pérdidas de tiempo, dinero y producción.

---

¿Quieres que te prepare esta misma versión en formato guía técnica descargable en PDF, lista para entregar a técnicos en planta?

Read More

Misteriosa Falla en PLC Siemens (tarjeta FM 354)

 

SI-300-001

    Durante una visita a planta, mientras recorría las líneas de producción, un técnico de mantenimiento me solicitó apoyo para resolver un problema en una máquina envolvedora de producto. La máquina trabajaba con un PLC Siemens de la línea S7-300, lo cual facilitó mi intervención, ya que llevaba conmigo la laptop y el cable de comunicación necesarios.

Descripción de la Falla

    Al iniciar la revisión, el personal de mantenimiento y el operador me explicaron la situación:

• En modo manual, la máquina funcionaba correctamente, sin fallas.

• Era posible referenciar el eje principal sin inconvenientes.

• El problema aparecía únicamente en modo automático, cuando la máquina se detenía abruptamente, mostrando en el panel de operador la alarma:
  “Falla en el Eje Principal”.

    Este tipo de alarma sugería un problema relacionado con el sistema de servo: motor, cableado, módulo FM-354, configuración del panel, o incluso una falla de programación.

Primeras Acciones de Diagnóstico

1. Revisión de diagnóstico en la CPU
   Me conecté al PLC y revisé el búffer de diagnóstico. Sorprendentemente, no aparecía ninguna falla registrada ni en la red Profibus, ni en otros módulos.

2. Comparación de programas
   Utilicé un respaldo existente del programa para verificar modificaciones en los bloques, pero no encontré diferencias.

3. Monitoreo en tiempo real
   Observé el programa durante la producción automática. La falla se presentaba, pero sin anomalías visibles en la CPU ni pérdida de comunicación.

Acciones de Mantenimiento

    Ante la incertidumbre, el personal de mantenimiento decidió:

• Sustituir la tarjeta FM-354.
  Sin embargo, el problema persistió: la máquina volvió a detenerse y el LED rojo de la FM-354 se encendió, descartando un simple fallo del módulo.

• Revisar la alimentación eléctrica.
  Se verificó que la tarjeta estaba correctamente alimentada. Aun así, la falla continuaba.

Observaciones Críticas

      Durante un nuevo arranque en automático, noté un comportamiento anómalo:

• Los LEDs de todo el PLC (CPU, módulos de E/S y FM-354) parpadeaban por unos instantes justo antes de la falla.

• Este parpadeo, casi imperceptible, no correspondía a una operación normal.

    La hipótesis inicial fue un problema eléctrico en la máquina, como una fuente defectuosa o un corto circuito intermitente.

Nueva Línea de Diagnóstico

1. Cambio de la fuente de alimentación.
   Fue reemplazada por una nueva, pero el problema persistió.

2. Revisión detallada de la máquina.
   Se sospechó de un sensor en mal estado, por la naturaleza intermitente del fallo.

3. Detección del problema real.
   Tras revisar sensor por sensor, se identificó un sensor fotoeléctrico roto, que al girar el mecanismo de la máquina se aterrizaba y provocaba un corto momentáneo.

    Este corto afectaba la fuente de alimentación del PLC, ocasionando la caída del sistema y, con ello, la falla de la FM-354.

Solución

    Una vez sustituido el sensor defectuoso:

• La máquina volvió a operar normalmente.

• El sistema dejó de registrar fallas en el eje principal.

• Se eliminó el parpadeo anómalo de los LEDs del PLC.

Lo aprendido

    Este caso ilustra la importancia de:

• No limitar el diagnóstico únicamente al software y la programación, ya que la causa puede ser eléctrica o mecánica.

• Observar indicadores físicos (como LEDs de módulos y CPU), que pueden aportar pistas cruciales.

• Considerar fallas indirectas: un sensor en corto puede ocasionar errores en módulos críticos como un FM-354.

    La experiencia reafirma que en automatización, la clave está en un diagnóstico integral, donde hardware, software y condiciones eléctricas deben ser analizados en conjunto.

Read More

Expediente PLC: Se Gesta la Historia

Comienzos en la automatización industrial

    Comenzaba a caer la noche cuando llegamos a la fábrica. Era un atardecer como cualquier otro en esas latitudes: un clima templado y un sol que se ocultaba lentamente en el horizonte. Lo que no era tan común era mi nerviosismo. Apenas unas semanas antes había tomado un curso de Step 5, sin experiencia alguna en el mundo de la automatización, y ahora me encontraba allí, acompañado únicamente por la fría presencia de mi exjefe, dando los primeros pasos en el ámbito del control industrial.

    Nos anunciamos en la caseta de vigilancia, nos registramos y fuimos guiados por un supervisor de mantenimiento hacia el interior de la nave. La primera sensación que tuve al entrar fue de vértigo. Era un espacio inmenso: máquinas por todos lados, operadores produciendo miles de piezas por minuto, robots moviéndose con precisión milimétrica a gran velocidad, olor a aceite quemado impregnando cada pasillo. Todos vestían el mismo uniforme, con semblantes de seguridad, como si domaran a diario al monstruo metálico que rugía frente a ellos. El ruido ensordecedor de los motores hacía casi imposible conversar sin gritar.

    En esos primeros segundos pensé que aquel impacto inicial podría derivar en temor… y ese temor en huida. Sin embargo, tuve que ajustar mi mente rápidamente para sobreponerme. La adrenalina de ese momento me acompañaría mucho tiempo. Tal vez otros en mi lugar habrían preferido buscar un trabajo más sencillo, “ver los toros desde la barrera”. Pero yo decidí seguir adelante, solo para descubrir que ese día aún me aguardaban más sorpresas.

La primera prueba

    Tras caminar varios minutos llegamos a la línea de producción donde debíamos intervenir. El supervisor se retiró y quedamos solos.

—“Conéctate” —fue la instrucción seca de mi jefe al localizar la CPU.

    Era una CPU S5-95U, considerada en ese tiempo una maravilla: fuente de alimentación integrada, entradas y salidas digitales y analógicas, contadores rápidos y funciones de comunicación, todo en un solo dispositivo. Lo único que realmente dominaba bien era la conexión, siempre y cuando el cable adaptador TTY-RS232 no diera problemas.

    Saqué mi portátil, encendí el Step 5 y realicé la conexión. La comunicación se estableció sin complicaciones. Todo marchaba bien… excepto por mis pensamientos desbordados y el sudor frío que me empapaba.

    Siguiendo el consejo de mi exjefe, hice un respaldo completo de los programas de la CPU (OB’s, FB’s, PB’s, DB’s). Luego generé una copia adicional para trabajar sobre ella. Hasta allí todo era correcto. Lo que no recuerdo con claridad es qué debíamos modificar: quizá un ciclo, un tiempo, el almacenamiento de un valor de proceso en una variable, o una adaptación para el panel. Supongamos que se trataba de guardar un valor en una DW del DB10.

    Con esa idea, me puse a editar el programa en la portátil, agregando líneas en el editor del Step 5. Mientras tanto, mi jefe explicaba a los operadores, en lenguaje sencillo, el cambio solicitado. Lo difícil no era la explicación a los humanos, sino traducir esa petición a instrucciones de PLC.

    Mi mente se saturaba de posibilidades: ¿Qué opción elegir? ¿Cuál es la solución más simple? ¿Cómo traducirla al programa? ¿Y si me tardo demasiado y mi jefe se desespera? ¿Y si me despide?

    No, no podía rendirme. Decidí hacerlo yo mismo, sin su ayuda. Mientras él conversaba despreocupado con los operadores, yo peleaba con las instrucciones y mis propias dudas. Tras varias revisiones, concluí que el programa estaba correcto. Era momento de descargarlo al PLC.

El desastre

    ¡Foco rojo en la CPU!

    ¡El programa no se ejecutaba!

    ¡La línea de producción estaba detenida!

    Los operadores comenzaron a quejarse de inmediato.

    En segundos, y antes de que mi jefe dejara su charla trivial y viniera a ver el desastre, reaccioné: cargué de nuevo el programa original que había respaldado al inicio. Puse la CPU en “Stop”, descargué el respaldo y la arranqué en “Run”.

    El foco verde volvió a encenderse.

    La línea se reactivó.

     Y yo… pude volver a respirar.

Como era de esperarse...

    Los operadores verificaron que todo funcionara correctamente. Mi jefe se acercó y, en voz baja, me preguntó qué había hecho. Le expliqué: había escrito varias líneas, las había revisado y creía que eran correctas, pero al cargarlas la CPU se fue a falla.

—¿Respaldaste el programa modificado? —me preguntó.
—No —respondí.
—Error —me dijo.

—¿Revisaste en la CPU la causa de la falla?
—No.
—Otro error.

    No se habló más del tema. Era tarde y nos retiramos de la fábrica. Nunca volví a intentar esa modificación en particular. Sin embargo, regresé muchas veces a la misma línea, a la misma CPU, y realicé otros cambios sin que volviera a ocurrir lo mismo. Incluso llegué a modificar el panel después. Hasta hoy, esa línea sigue funcionando con la misma CPU, como si nada hubiera pasado.

El misterio

    Con el tiempo reflexioné: ¿qué código escribí para que el PLC fallara?

      No utilicé saltos indebidos, ni banderas duplicadas, ni entradas fuera de rango. Tal vez direccioné un DB inexistente, o una DW fuera de rango.

    Le dije a mi jefe que no había guardado el programa modificado, para evitar que lo analizara y encontrara el error. Pero en realidad sí lo guardé. Lo revisé después… y no encontré nada.

    Lo más inquietante: cargué ese mismo programa en otra CPU S5-95U y no presentó fallas. Funcionaba perfectamente.

    Entonces, ¿qué sucedía con la CPU de esa fábrica?

    ¿Era diferente en capacidad de memoria? ¿Versión de firmware? ¿Un defecto particular?

    Algo extraño ocurre con esas CPU’s.

    Estoy investigando…

(Continuará)

Read More

Puertos de comunicación de las CPU's (de los PLC's) familia SLC 500

AB-SLC-001

    Cuando vamos a comunicarnos con un PLC de la familia SLC-500 de Allen-Bradley, lo primero que solemos pensar es en el famoso cable de comunicación PIC (1747-PIC). Sin embargo, este cable no es universal: sólo funciona con 3 de los 5 tipos de CPU de la serie. En otros modelos será necesario utilizar un cable RS-232 o incluso un cable tipo DH+.

    Esta versatilidad en las opciones de comunicación del SLC-500 puede ser una ventaja, pero también un verdadero acertijo cuando necesitamos conectarnos a la CPU.

El problema típico en planta

    Imaginemos la situación:

• Una empresa nos llama a cualquier hora diciendo que tienen un problema con el programa del PLC.

• Después de varias preguntas, concluimos que la falla está escondido en las líneas de programa de la CPU.

• Preguntamos qué modelo de SLC tienen, y el encargado solo responde: “es uno de los cuadrados medianos de Allen-Bradley”.

• Tal vez nos diga que cree que es un SLC 5/03, pero no está seguro.

    En este punto, lo mejor es llevar todos los cables posibles, porque al llegar a la planta podríamos encontrarnos con un SLC 5/01, o cualquier otro.

Tipos de CPU y sus puertos de comunicación

     Para evitar confusiones, lo primero es identificar qué puertos de comunicación trae cada CPU de la familia SLC-500:

• SLC 5/01 → DH-485 (1 puerto RJ45)

• SLC 5/02 → DH-485 (1 puerto RJ45)

• SLC 5/03 → DH-485 (1 puerto RJ45) y DH-485/DF1/ASCII (1 puerto DB9)

• SLC 5/04 → DH-485/DF1/ASCII (1 puerto DB9) y DH+ (1 puerto conector DH+)

• SLC 5/05 → DH-485/DF1/ASCII/RS-232 (1 puerto DB9) y Ethernet (1 puerto RJ45)

Tipos de cable según el puerto

    Una vez identificado el modelo de CPU y el puerto al que nos vamos a conectar, elegimos el cable adecuado:

• DH-485 (Puerto RJ45) → 1747-UIC (con cable 1747-C13) o 1747-PIC

• DH-485/DF1/ASCII (Puerto DB9) → 1747-UIC (con cable 1747-CP3) o 1747-CP3 

  

• DH+ → 1784-PCMK (con cable 1747-PCM6) o 1784-U2DHP

   

• Ethernet → Cable cruzado de red (10/100Base-T Ethernet)

    En la mayoría de los casos, basta con tener:

• Un cable PIC (1747-PIC)

• Un cable RS-232 (1747-CP3)

    La familia SLC-500 ofrece varias opciones de comunicación, pero eso implica que debemos identificar correctamente el modelo de CPU y su puerto antes de elegir el cable.

    La recomendación práctica:

• Ir siempre preparados con los cables más usados (PIC y RS-232).

• Verificar en campo el modelo de SLC.

• Conocer la tabla de compatibilidad entre CPU, puertos y cables.

    De esta forma evitaremos sorpresas y estaremos listos para conectarnos al PLC en cualquier situación.

    Veáse también el blog:

    SLC Uncoded

 

Read More

Automatización Industrial: La tecnología en constante evolución

 

    Luego de algunos días en los que estuve bastante ocupado, vuelvo a darle continuidad a este blog. Y es que, en el mundo de los PLC’s, nunca se sabe qué puede pasar: hay jornadas tranquilas, donde todo marcha bien, y otras en las que parece que todo se confabula para sacarte de quicio.

Los días tranquilos y los días complicados

    Hay días en los que las máquinas trabajan en armonía, sin fallas, y uno cree que ya tiene todo bajo control. Pero también existen esos días nefastos en los que:

• Un equipo que funcionaba perfectamente, de repente ya no quiere arrancar.

• Una máquina crítica presenta fallas recurrentes que parecen no tener causa aparente.

• Para empeorar la situación, el problema ocurre en sábado por la noche, sin posibilidad de conseguir refacciones.

    En esos momentos, todo lo demás pasa a segundo plano: comida, descanso o pendientes personales. El tiempo se convierte en una carrera detectivesca contra la falla. Cuando apenas logras medio resolverla, ya otro equipo está esperando su turno para reclamar atención. Este ciclo puede repetirse una y otra vez, dejando poco espacio para otras actividades… incluso para escribir en este blog.

Aprender de cada máquina

    La experiencia con cada máquina es única. Al trabajar de cerca con equipos de distintas plantas, dedicándoles horas o incluso días, uno termina adentrándose en sus particularidades. Con el tiempo, esto permite reconocer patrones y aplicar lo aprendido en situaciones futuras.

    Sin embargo, no todas las máquinas son iguales:

• Si fueran todas idénticas, bastaría con dominar una para dominar todas, lo que facilitaría mucho el trabajo.

• Pero la realidad es otra: difieren en operación, cableado, control, mecánica, hidráulica, comunicaciones, etc. Esto implica que lo aprendido en una no siempre aplica en otra, haciendo que el proceso de aprendizaje sea más largo… aunque también más enriquecedor.

Diversidad de tecnologías

     En mi día a día me toca atender desde equipos muy viejos hasta máquinas de última tecnología. Algunas son sencillas, otras extremadamente complejas. No todas fabrican lo mismo, ni utilizan los mismos controles, ni incorporan los mismos PLC’s. Incluso cuando parecen similares, cambian por detalles como:

• Funciones específicas para una línea de producción.

• Diferencias en el cableado eléctrico.

• Nuevas CPU’s o tarjetas añadidas.

• Modificaciones en el programa para mejorar la eficiencia.

    De cada una, sin importar su edad o complejidad, se aprende algo nuevo.

El propósito de este blog

    Todo lo que voy aprendiendo en este mundo de la automatización lo plasmo aquí. Habrá días en los que esté ausente por estar ocupado resolviendo problemas, pero siempre volveré para compartir lo aprendido.

    Aclaro que, aunque llevo varios años en este campo, no me considero un experto absoluto. La tecnología evoluciona a diario: aparecen nuevos PLC’s, sensores, tarjetas, redes, softwares, etc. Nadie puede abarcarlo todo.

    Este blog no pretende ser un curso de PLC’s ni un manual técnico exhaustivo. Para eso existen los cursos especializados, que recomiendo ampliamente. Lo que sí encontrarás aquí son:

• Definiciones de términos poco comunes.

• Procedimientos básicos paso a paso (respaldar un programa, configurar una tarjeta, crear bloques de datos, parametrizar un variador, etc.).

• Experiencias reales que pueden servir como orientación en situaciones similares.

Para concluir...

    La finalidad de este espacio es sencilla: registrar mis experiencias, porque los detalles se olvidan con el tiempo. Y quizá lo que aquí quede escrito sea útil para alguien más… o incluso para mí mismo en el futuro, cuando enfrente de nuevo una falla en algún rincón de una planta.

Read More

S5-95U: Entradas/Salidas Analógicas Integradas y su direccionamiento

 

 SI-9X-001

    Conforme avanza el tiempo, nuevas tecnologías van surgiendo y aquellas que hace algunos años eran consideradas una maravilla, poco a poco quedan obsoletas. Esto mismo ocurrió con los PLC de la serie S5 de Siemens, que en su momento fueron ampliamente utilizados en proyectos de automatización industrial.

    Durante años, era prácticamente un estándar encontrarlos en máquinas modernas. Hoy en día todavía es posible hallar muchos de estos equipos funcionando en distintas plantas industriales, aunque hayan sido desplazados por los más recientes S7.

    Hace algunos días tuve la oportunidad de trabajar con un S5-95U, que controla el desplazamiento de un carro transportador de material. Su programación incluye funciones sencillas: posicionamiento en estaciones específicas, avance y retroceso manual, así como la carga y descarga de producto.

Ventajas del PLC Siemens S5-95U

    El S5-95U fue un equipo muy completo para su tiempo, ya que integraba en un solo módulo:

• CPU para el procesamiento del programa.

• Entradas y salidas digitales.

• Entradas y salidas analógicas.

• Entradas de contador.

• Fuente de alimentación incorporada.

    Esto lo hacía versátil y práctico, ya que no requería módulos adicionales para muchas aplicaciones. Por estas razones se volvió ideal en su época para una gran variedad de soluciones de control.

Aplicación en el carro transportador

     En el caso que revisé, el S5-95U envía una consigna analógica a un variador de velocidad, el cual regula el motor encargado de mover el carro transportador. Además, mediante un encoder, el sistema detecta la posición exacta del carro para realizar las operaciones de avance, retroceso, carga y descarga.

Señales analógicas del S5-95U

    Este módulo cuenta con una sola salida analógica integrada, que puede configurarse de dos maneras:

• Señal de corriente: 4 a 20 mA.

• Señal de voltaje: 0 a 10 V.

    En el caso del variador de velocidad:

• Cuando recibe 0 V, trabaja a 0 Hz (motor detenido).

• Cuando recibe 10 V, alcanza su frecuencia máxima (normalmente 60 Hz).

• Valores intermedios corresponden a velocidades proporcionales.

  • Ejemplo: con 5 V, el variador opera a 30 Hz (la mitad de su capacidad).

Direccionamiento de señales

• La salida analógica del módulo S5-95U se direcciona como QW40 dentro del programa.

• El módulo también dispone de 8 entradas analógicas, direccionadas desde IW40 hasta IW54.

    El S5-95U representó un gran avance en su tiempo gracias a su diseño compacto y sus funciones integradas. Aunque hoy ha sido desplazado por la familia S7, sigue siendo interesante encontrarlos en aplicaciones industriales que aún operan de manera confiable.

    En próximos temas revisaremos ejemplos prácticos de programación de señales analógicas en este modelo, que permitirán comprender mejor cómo aprovechar estas entradas y salidas en proyectos de automatización.

Read More