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