Problema en Tecla de Función de Panel Siemens

SI-OP-001

Es un problema que se repite no obstante el paso del tiempo y el lanzamiento de nuevos paneles de mejor tecnología. Quizá la falla esté en el software de los paneles.

Resulta que hace unos días me hablaron de una planta donde me decían que no podían pasar de un modo de operación a otro. Era una máquina donde me había tocado programar el PLC, mas no el panel de operador. Se trata de un PLC S7-300 y un panel gráfico Siemens.

Llegué a la fábrica y comprobé efectivamente que la máquina no conmutaba su modo de operación, conmutación que se hacía desde la pantalla del panel. Así que decidí desempacar mi lap-top y conectarme al PLC para averiguar qué estaba ocurriendo. Una vez establecida la conexión a la CPU, me puse a monitorear los bits de cambio de modo en el PLC. Para mi sorpresa, observé que un bit que recibía del Panel se quedaba siempre activado. Lo que hice fue, simplemente, cambiar el estado de este bit, de estado lógico "1" lo puse a "0". El bit se desactivó inmediatamente. Al volver a pulsar la misma tecla desde el Panel, el bit se volvió a activar, sin embargo, al momento de soltar la tecla, el bit correspondiente quedó activado de forma permanente en el PLC. Con mi Lap-Top volví a desactivar el bit sin ningún contratiempo. Así que concluí que el problema estaba en el Panel.

Esta situación se la comenté a la persona que programó el Panel. Una vez que comprendió la situación, revisó su programa, y me mostró que la tecla que mandaba el bit al PLC y que nos ocasionaba el problema, tenía asignada la función de "Activar bit mientras tecla pulsada". Esto significaba que, mientras estuviera oprimida la tecla, iba a mantener en uno en el PLC el bit correspondiente. Extrañamente, al dejar de pulsar la tecla, el bit caprichosamente se quedaba en el estado "1".

Recordé que esta situación me había pasado hacía años (unos 5) con un Panel también Siemens. Era un panel gráfico OP 37. Este Panel me tocó programarlo a mí. Recuerdo que este equipo lo programé con el ya pasado de moda software "ProTool", versión 6.0, si mal no recuerdo. En aquella ocasión utilicé la función "Activar bit mientras tecla pulsada" y la asigné a diferentes teclas con la finalidad de arrancar y parar algunos motores. Cuando lo programé todo funcionaba perfectamente. Sin embargo, al cabo de unos meses, resultó que los motores ya no los podían operar con normalidad, ya que o se quedaban activados permanentemente, o no era posible iniciar su arranque. La razón de esta falla: Que las teclas del Panel se quedaban activadas continuamente, aunque se dejaran de pulsar, y ocasionaban que el motor se quedara siempre encendido con la tecla de arranque, o que no se pudiera arrancar, ya que la tecla de paro mandaba siempre señal al PLC. En conclusión, esta función de la tecla del Panel, que es activar el bit sólo mientras la tecla esté pulsada, no se percataba de que la tecla había sido liberada, y seguía mandando señal a la CPU. La solución fue programar en el PLC su autodesactivación luego de unos segundos, de tal manera que la señal de estas teclas se desactivara inevitablemente al cumplirse este tiempo, y con esto evitar que la tecla se quedara enclavada. Hecho esto, no tuvo más problemas el Panel.

Regresamos a nuestro problema actual. Resulta que ahora gozamos de la gran herramienta de programación de Paneles llamada "WinCC Flexible", la cual vino a sustituir al "ProTool". Sin embargo, nos encontramos que adolece de varias imperfecciones. Una de ellas es la referente a esta función de activar un bit mientras se pulsa la tecla en el Panel. Ha evolucionado el software, han salido al mercado nuevos paneles Siemens más sofisticados, pero la misma falla vuelve a repetirse. Podría pensarse que tal vez es cuestión de una mala programación. Sólo que yo programé en ProTool un panel, y otra persona programó en WinCC Flexible. Dos softwares diferentes, dos paneles diferentes, dos programadores diferentes, una misma función, una misma falla. En fin.

El problema no ha sido eliminado por Siemens. Así que hay que evitar usar esa función en los paneles, y, adicionalmente, asegurar desde programa en el PLC, de desactivar bits que se activen desde Panel cuando éstos no tengan que durar tanto activados, como es el caso de la función "Activar bit mientras tecla pulsada".

Finalmente, corregimos la falla de este Panel desactivando los bits luego de cierto tiempo de estar activos.

Así que, a tener cuidado con la función "Activar bit mientras tecla pulsada". Espero no les ocurra nada parecido.

Read More

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

S5-135-001

Una vez más nos encontramos con estos PLC's "dinosaurios". Suelen ser un dolor de cabeza en muchas empresas, ya que son equipos de control bastante viejos y obsoletos. El sólo verlos, desalienta a cualquiera a meterles mano, dadas las dificultades que implican. Sin embargo, los encontramos todavía en muchas máquinas y en muchos procesos industriales. No es fácil deshacerse de ellos. En la mayoría de los casos, no queda más que familiarizarse con estos equipos.

En varias ocasiones, me han preguntado cómo cargarle el programa a una CPU S5-135U desde una tarjeta de memoria. El problema surge cuando, por causas todavía no aclaradas, la memoria RAM de la CPU pierde el programa, incluso teniendo batería de respaldo. Una vez que se borra el programa de la RAM, es necesario cargarlo, ya sea a través de conexión con PC o a través de una Memory Card.

Aquí describiremos el procedimiento de hacer la carga del programa con la ayuda de una Memory Card. Como requisitos previos, es necesario contar con un programa en la Memory Card. Si esta tarjeta ya cuenta con programa, entonces la colocamos en la CPU en la ranura correspondiente. A continuación, ubicamos los selectores de "Run-Stop" y de "Overall Reset".

1. Mantener el selector en la posición de "Overall Reset", sin soltarlo
2. Al mismo tiempo, accionamos el selector de "Run-Stop" a la posición de "Stop"
3. Enseguida lo colocamos en la posición de "Run"
4. Finalmente, volvemos a colocar el selector en la posición de "Stop", y soltamos sólo hasta este momento el selector de "Overall Reset"

Si todo salió bien, el led de "Stop" se encenderá de forma permanente, sin intermitencia.

Es importante resaltar que con este procedimiento borramos todo lo contenido en la memoria de la CPU, si es que hubiera algo.

Lo interesante de este procedimiento es que, una vez que finalizamos este borrado total de la CPU, el sistema operativo se encarga de transferir la información de la Memory Card a la memoria RAM. Así que ya tenemos cargado nuestro programa en la CPU directamente de un cartucho de memoria. Si la carga se realizó correctamente, podemos realizar el arranque del sistema, colocando el selector de "Run-Stop" en la posición de "Run".

Listo, el led de "Run" luce de color verde de forma permanente.

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 en torno a esta tarjeta. Además, partía desde cero y tenía que programarla en un lapso de cinco días para una máquina cuya función era colocar botes de producto en sus cajas.

Ya antes había programado simodrives Siemens conectados a un PLC S7-300 a través de una red Profibus. En base a este conocimiento, la primera pregunta que tenía que resolver era la de si aceptaba el reto de programar la FM-354 en menos de cinco días. No era un reto fácil. No conocía nada acerca de la FM-354. Tenía unos cuantos días para hacer la programación. Y, la pregunta que más estrés me causaba era la de si funcionaría la máquina, no importando cuántos días pasaran. Había que buscar la manera de hacer compatibles las señales enviadas al servo-drive y corroborar que el encoder fuera el adecuado para la FM. Si desde este punto notábamos alguna incongruencia, tendríamos poco tiempo para reaccionar. Bueno, de cualquier modo acepté la responsabilidad y la misión era que tenía que funcionar a como diera lugar, haciendo esto en un tiempo no mayor de cinco días... de lo contrario... la palabra fracaso aparecería en el escenario, con todas la consecuencias que ello trae: incumplimiento con el cliente, producción retrasada, costos operacionales que se saldrían del presupuesto, llamadas de atención interminables de los gerentes de planta para indagarnos por qué no funciona la máquina, cuánto tiempo más necesitaríamos, e, incluso, en el peor de los casos, cancelación del proyecto y ser puestos en la lista negra de las empresas no aptas para realizar este tipo de desarrollos.

Con el reto encima, lo primero que hice fue conseguirme el manual de la FM-354 a través de internet. En este manual, como en la gran mayoría de los manuales, se habla de forma elemental de las funciones de la FM. En base a la experiencia previa con PLC's Siemens, se puede ir trazando la ruta a seguir para programar la tarjeta. Gracias al manual me pude dar cuenta de que esta tarjeta nos ayuda a controlar servo-motores para realizar tareas de posicionamiento, que era una función que tendría que realizar la máquina.

Una de los primeros conocimientos que tuve que adquirir para despejarme dudas sobre si tendría obstáculos desde un inicio, fue acerca del hardware de la tarjeta: qué señales digitales maneja, dónde colocar la tarjeta en el rack del PLC, qué tipos de encoder son compatibles y cómo conectarlos, y cómo enviar las señales de control desde la FM-354 al servo-drive. Aparentemente, contábamos con el encoder adecuado, y la señal para el set-point de velocidad resultó ser también la indicada para el servo-drive (señal de voltaje, de -10V...0...+10V).

Superada la etapa del hardware, y con los componentes montados y conectados, lo siguiente por realizar era sumergirse en el manual y desentrañar la forma en cómo programar la FM-354. En base a esto, lo primero que tuvimos que realizar fue instalar el software de esta tarjeta, el cual, como requisito previo, se instala sobre el Step 7. Yo lo instalé sobre la versión 5.4. Una vez instalado el software, bajé el hardware de mi PLC conectándome a través del puerto MPI de la CPU con mi PC-Adapter y mi Lap-Top Acer.

Con el proyecto en mi compu, abro el "Hardware Configuration" y allí hago click en la FM-354. Emerge una nueva pantalla donde puedo modificar los parámetros de la tarjeta directamente. Una vez que los modifico, puedo hacer click en transferir bloques de datos a la FM. Si no hay errores en la parametrización, la carga se realiza con éxito, de lo contrario nos aparece un mensaje indicándonos que hubo una falla en la transferencia y que hemos de corregir el error. Parece un proceso sencillo, sin embargo, nos llegamos a encontrar con un problema relativamente extraño, y, que al recurrir al manual de la FM-354, no indica nada al respecto.

Nos sucedió en varias ocasiones que hacíamos modificaciones a la tarjeta, se transferían los bloques de datos a la misma, todo realizado correctamente, sin embargo, cuando apagábamos el PLC, nos ocurría que la FM no guardaba las modificaciones, y teníamos que volver a cambiar los valores. Varias veces nos sucedió esto, sin encontrar nada claro en el manual para solucionar este problema. Finalmente, tras probar de diferentes formas, encontramos el procedimiento que nos permitió guardar los bloques de datos en la FM sin que ésta los llegara a perder tras desenergizar el PLC.

El procedimiento que nos funcionó fue el siguiente:

1. Conectados al PLC por el puerto MPI, abrimos la aplicación de la FM-354
2. Modificamos los parámetros que necesitamos de la tarjeta
3. El selector de la CPU lo colocamos en la posición de "Stop"
4. Transferimos los bloques de datos a la FM
5. Desenergizamos la FM únicamente por unos segundos y la volvemos a energizar
6. Al volver a energizar la FM, la CPU nos indica una falla con el led "SF"
7. Finalmente, colocamos el selector de la CPU en "Run"

Hecho esto, reiniciamos la comunicación con la FM y revisamos los parámetros. Al revisarlos, notamos que los cambios se conservaron. Y, por último, apagamos el tablero completamente. Energizamos. Nos comunicamos con la FM nuevamente, y, al verificar los datos de la FM, notamos que no se perdieron las modificaciones, y que la FM conservó los cambios luego de haber sido desenergizada.

Finalmente, comentar que, aunque fue un trabajo maratónico, la máquina quedó finalmente trabajando en el lapso acordado, quedando sólo con detalles menores que fueron eventualmente corregidos.

Read More

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

SI-300-004

Como comentaba en el artículo precedente, a la hora de programar un PLC desde cero, por lo regular lo hacemos sin muchas consideraciones de seguridad. Más de alguna vez nos entusiasmamos con el desarrollo de nuestra programación, viendo como un punto lejano el momento en que mandemos a "Run" nuestra CPU y todo trabaje a la perfección. Movidos por este deseo, nos apresuramos a escribir líneas de código y más código, sin reparar mucho en los detalles. De cualquier forma, los detalles los atacaremos una vez que hayamos dado por terminada la estructura principal de nuestra lógica de control. O podemos también estar atrapados por el tiempo: este programa que controla en su totalidad el proceso de una línea de producción, tiene que estar terminado a más tardar el día lunes... y hoy es viernes... El reto de finalizar a tiempo la programación nos lleva de igual forma a omitir detalles, y sabemos que no descansará nuestra fatigada mente hasta no ver a los jefes satisfechos con nuestro trabajo. Las prisas, siempre las prisas, nos hacen volvernos bastante miopes ante las cosas que nos rodean y nos demandan de nuestra atención.

Es Domingo ya, y nuestro programa apenas va tomando forma. La fatiga hace estragos en nuestra mente. Lo único que se hace presente en nuestra conciencia es el que el día de mañana tenemos que entregar funcionando este cacharro viejo con un PLC de última generación. No atinamos a concentrarnos. Y nuestros compañeros de batalla ya se han retirado a descansar, al fin y al cabo, los problemas mecánicos y eléctricos ya los tienen dominados, más no sabiendo que una válvula está dañada y fuga aire, producto de haber forzado la compuerta para fijarla en su lugar, y que un sensor de temperatura quedó quebrado, luego que una persona de mantenimiento lo usara como escalón cuando hizo el cambio de tubería eléctrica que ya estaba bastante deteriorada. En fin. Sólo queda luchar contra el reloj.

Pero estamos tan fatigados que, aquello que vislumbrábamos con claridad al momento de abordar la programación, lo que habíamos concebido como nuestra ruta de viaje para saber qué cosas van en cada lugar, aquello que veíamos al inicio tan sencillo e integrado, en estos momentos se vuelve confuso y surgen miles de dudas en momentos tan críticos. Hasta llegamos a pensar si no habría sido más sencillo programar como nos sugería nuestro jefe. Si no queda, qué buena rociada me va esperar el día de mañana. Volvemos al programa. Escribimos que queremos leer la DBW48 del DB110. Sin embargo, producto del cansancio físico y la fatiga mental, en vez de DB110 escribimos DB119 (este DB119 no ha sido creado todavía). Me dirán que está súper difícil no notar que en vez de "0" pusimos un "9". Sí, cuando estamos lúcidos y bien despiertos, no se nos pasa nada, pero en las condiciones que aquí describimos, hasta un volcho lo confundimos con un Bora. Sólo exagero un poco. Pero bueno, ya escribimos 119 en vez de 100.

Pensé que no lo iban a notar. Sólo quería ver si estaban atentos a lo que escribía. Arriba puse 100, pero más bien era 110. Igual, pongo el pretexto de que ya ando bastante enfadado y cansado. Bueno, continuemos. Entonces decía que en el programa escribí 119 en lugar de 110. El editor de programas del Simatic Manager no me dice nada, así que sigo tecleando más y más líneas de instrucciones hasta completar la rutina que deseaba. Como veo que todo va funcionar correctamente, decido descargar el bloque de programa en el PLC. Apenas termina la carga de programa y, desastre. La CPU se ha ido a "Stop". No me gano nada con ponerme a maldecir una y mil veces... de todos modos lo hago. Ya que me tranquilicé, busco en el búffer de diagnóstico de la CPU la causa del fallo, y descubro que aparece un mensaje donde dice que no encontró el OB121. Rayos, lo que me faltaba.

Este OB121 es llamado por la CPU cuando cometemos, como en este caso, un error de programación. Si la CPU encuentra cargado en su memoria al OB121, en errores de programa, evita que la CPU se vaya a Stop. Pero si no está cargado, ya sabremos en el búffer de diagnóstico por qué rayos se salió del modo Run. Cabe aclarar que, aunque el OB121 esté cargado en la CPU y así esta no se va falla, de cualquier modo, el error persiste y tenemos que eliminarlo manualmente. Al eliminarlo, eliminamos la falla de la CPU.

Por último indicar que basta con que creemos el OB121 y lo transfiramos a la CPU. No es necesario cargar una sóla instrucción en este OB para evitar que la CPU se vaya a Stop. El único requisito es que el OB121 exista en la memoria del PLC para que nos salve de generar situaciones comprometedoras. Ahora sí, a programar con más confianza.

Read More

Para evitar que los PLC's S7-300 se vayan a Stop por error de I/O

SI-300-003

Una de las tareas que he realizado con cierta frecuencia es la de programar equipos Siemens de la familia S7-300. Cuando tienes el proyecto en tus manos (de programación), puedes invertar gran cantidad de bloques de programa, imaginar cómo se integrarán los equipos, qué entradas y salidas emplear, cuáles timers y banderas asignar para cada grupo de tareas, etc.

Durante esta etapa de diseño es común cometer algunas equivocaciones que traen como consecuencia, a parte de que la máquina no hace lo que esperabas, que mandes la CPU al modo "Stop". Errores de programación son cometidos constantemente; algunos de estos errores los detectamos rápidamente, y otros sólo al cargarlos a la memoria y verlos correr... claro, eso si no mandamos a falla la CPU.

Sin embargo, una vez que terminamos nuestra programación y dejamos lista la máquina, podemos encontrarnos con ciertas sorpresas que no habíamos considerado. Y esto puede suceder tras meses o años de que trabaja bien el control.

Y esto lo menciono porque hace unos días recibí una llamada de un cliente, quien me comentaba de que tenía una falla en su PLC S7-300. Me comentaba que la CPU se iba a "Stop". Al leer el búffer de diagnóstico decía que le aparecía que no encontraba el OB122.

Generalmente, este OB122 se carga desde el inicio de la programación, precisamente en el estado de diseño de programa, como una precaución y evitar mandar a Stop la CPU cuando se comenten errores o se tiene el hardware incompleto.

Para este caso específico, el OB122 lo cargamos por si a la hora de programar intentamos cargar en la CPU instrucciones que hacen referencia a entradas (I) o salidas (O) que no existen físicamente en nuestro hardware. Cuando programamos off-line, no pasa nada; escribrimos líneas de código con las mencionadas direcciones y no nos marca ningún error el software. Sin embargo, el riesgo de mandar la CPU a falla surge a la hora de descargar este programa con las direcciones inexistentes físicamente. Por ejemplo, si en nuestro programa off-line escribimos que queremos leer la PIW 312, pero esta dirección no corresponde a ninguna tarjeta en nuestro hardware físico, a la hora que mandemos este programa a la CPU, de inmediato se nos irá a Stop... A menos que tengamos cargado este OB122.

Y es justamente con este OB con el que eliminamos detener la máquina (y con ello meternos en líos de producción) cuando la CPU trata de leer desde o escribir en una dirección que no existen en el hardware.

Entonces, estando off-line, creamos desde el Simatic Manager el OB122. Una vez creado, lo descargamos directamente a nuestra CPU, y no es necesario que tenga instrucción alguna. Podemos mandarlo a nuestro PLC sin que exista un solo segmento. Pero una vez en la CPU, ésta se dará cuenta de que existe el OB122 buscado, y, al encontrarlo, dejará de caprichosamente irse al modo Stop.

Cabe aclarar que con este OB sólo evitamos que la CPU falle y se vaya a Stop, pero no habremos eliminado el error. Una vez cargado el OB122 en la CPU, si revisamos el búffer de diagnóstico, encontraremos que el estado operativo es "Run", pero no aparecerá en la lista de fallas el error de lectura o escritura en la entrada o salida que no existen.

Así que, para concluir, el OB122 nos evita se vaya a falla la CPU por error en lectura o escritura I/O (de entradas o salidas) que no existen en nuestro hardware. Esta falla puede ser debido a que estamos programando nuevo código y queremos leer desde una entrada que no existe, o quizá queremos escribir en una salida que tampoco aparece en nuestro equipo. En cualquiera de estos dos casos, la CPU llamará al OB122. Pero también puede suceder no estemos programando, sino que la máquina estuvo trabajando por un buen tiempo. Sin embargo, si hubo un corto circuito y alguna tarjeta de entrada o salida quedó dañada, entonces la CPU no la verá, y como consecuencia, no podrá accesar sus direcciones correspondientes y nos indicará la falla.

Finalmente, es recomendable cargar el OB122 para evitar que nuestra CPU se vaya a Stop, y posteriormente revisar la causa del problema, o, incluso, con este mismo OB, indicar la tarjeta en falla.

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

Como complemento al tema anterior acerca de las baterías de respaldo de programa en CPU's, comentaremos el uso de memorias tipo Flash para guardar en ellas nuestro programa.
En el artículo precedente hablamos acerca de cómo prevenir la pérdida de nuestros programas en las CPU's que utilizan una batería. Cuando esta pila se encuentra con carga suficiente, podemos estar seguros que nuestra CPU mantendrá su programa a pesar de que quitemos la alimentación eléctrica del tablero. Pero cuando la batería está agotada, y si por error desenergizamos nuestra CPU, una vez que reestablezcamos la alimentación principal, nos llevaremos la desagradable sorpresa de que el programa de la CPU se perdió de manera irremediable. Es lo malo de confiar en la baterías.
Para no llegar a estas desastrosas situaciones, lo mejor es haber respaldado el programa de nuestros PLC's, quemarlos en un disco compacto, y mantener estos respaldos en un lugar seguro para utilizarlos en casos urgentes.
Otra alternativa que nos garantiza la permanencia de nuestro programa en nuestro PLC, es la utilización de memorias Flash. Estas memorias tienen la característica de que cuando se les carga información, ésta se mantiene, a pesar de que la batería se agote o desenergicemos nuestro tablero. Debido a que este tipo de memorias sólo se modifican (con el propósito de borrarlas, o de agregarles o quitarles información) mediante un proceso de aplicación de voltajes eléctricos, y sólo de esta manera, lo que grabemos en la memoria flash no podrá ser borrado o modificado de ningún otro modo, ni aunque quitemos la fuente de alimentación eléctrica. Una vez grabada la información en la memoria flash, podemos llevar este cartucho a cualquier parte, o podemos dejarlo en su cajita y colocarlo en nuestro estante de respaldos y allí guardarlo durante mucho tiempo, y la información no se alterará en lo más mínimo ni se borrará. Claro, si tomamos la memoria flash y la sometemos a procedimientos destructivos, tales como golpearla o exponerla a altas temperaturas, por supuesto que la dañaremos parcial o totalmente y con esto afectar a la información en ella almacenada.
Finalmente, una vez que hemos tomado la decisión de respaldar el programa de la CPU en una memoria flash apropiada, tomemos en cuenta lo siguiente:

1. La memoria flash depende del tipo de CPU que manejemos. Para las diferentes marcas de PLC's hay diferentes tipos de memorias flash. Tendremos que seleccionar la memoria flash adecuada.
2. Las memorias flash varían en capacidad. Así que, si tenemos un programa muy grande en nuestro PLC, elijamos aquella memoria que podrá contener ese programa.
3. Cada memoria flash sólo puede alojar un programa de una CPU. Aunque nuestra memoria flash sea de 8 KBytes, y nuestro programa en ella almacenado sea de sólo 1 KByte, no podemos utilizar el resto de la memoria para almacenar más programas de otras CPUs. Es una memoria flash para un sólo programa y una sóla CPU.
4. Es importante que antes de instalar la memoria flash en la CPU correspondiente, se haga un respaldo en una computadora del programa que está corriendo en el PLC, con el fin de evitar que la CPU se bloquee al colocarle la memoria flash, y se pierda el programa. En algunos casos, se requiere desenergizar la CPU y desmontarla, con lo cual se corre el riesgo de perder el programa.
5. Una vez instalada la memoria flash en su CPU correspondiente, se le cargará el programa deseado mediante el procedimiento indicado por el fabricante del PLC.
5. Cuando se haya transferido el programa de usuario a la memoria flash, este programa ya no se borrará al desenergizar el tablero o al agotarse la batería de la CPU.
6. En caso de que nuestra CPU (la cual cuenta con un cartucho de memoria flash, y esta memoria con el programa adecuado) perdiera el programa almacenado en la memoria RAM (ya sea porque se agotó la batería y se le retiró la alimentación eléctrica, o por alguna otra razón), al energizar la CPU automáticamente el programa de la memoria flash se transferirá a la memoria RAM. Esta transferencia se realiza de manera casi imperceptible, por lo que ni siquiera nos daremos cuenta de que se perdió el programa de la memoria RAM.
7. Recordemos que la memoria flash transfiere el programa que tiene almacenado directamente a la memoria RAM sólo cuando ésta se queda sin programa, y que todos los datos dinámicos de nuestra máquina se perderán, tales como el conteo de piezas, los set-points que, valores de los temporizadores y contadores, por lo que sería necesario ajustar nuevamente los valores para que la máquina trabaje correctamente. En otras palabras, en caso de transferirse el programa de la memoria flash a la memoria RAM, los temporizadores se van a cero (o a su valor de pre-set), al igual que los contadores. Los valores almacenados en los bloques de datos también regresan a su valor de pre-ajuste con los que se grabó la memoria flash. Así, si nuestra máquina tenía que luego de 10 horas de trabajo entrara un ciclo de lubricación, pero si perdemos el programa de la RAM, y se carga el programa de la flash, y en ésta tenemos que la lubricación se hace cada 18 horas, entonces es así como quedará trabajando desde ese momento nuestra máquina. Y esto se hace extensivo para todas las otras variables que almacenan datos dinámicos. Lo que nunca perderemos, será la lógica del programa.

Read More

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

TyC-006

En estos días he estado trabajando con PLC Siemens que tiene una CPU S7-315. Es un modelo antiguo de CPU que requiere de una batería para mantener el programa en la memoria RAM. Sin embargo, hay gran cantidad de CPU de diferentes modelos y marcas que también requieren una batería para que el programa almacenado en la memoria RAM no se pierda al desenergizar el equipo. En ocasiones ocurre que la misma CPU nos indica con un led (que por lo regular se ilumina en color rojo) que la batería se ha agotado. Cuando esto ocurra, es el momento de reemplazarla cuanto antes, si no queremos perder el programa que controla a esa máquina o a ese proceso. Pero hemos de tener cuidado al realizar esta sustitución, pues, por muy sencillo que parezca, podemos cometer el error de perder el programa de nuestra CPU.
Antes de detallar cómo realizar la sustitución, explicaré un poco cuál es la función de la batería.
Cuando nosotros adquirimos una CPU nueva (de los modelos que requieren batería), ésta nos es entregada sin su pila y, obviamente, sin programa. De igual forma, cuando sacamos una CPU de nuestros polvorientos estantes, por lo regular la tenemos arrumbada y sin su batería, tampoco esta CPU tendré programa alguno. Una vez que la instalamos en su rack correspondiente, la energizamos y le cargamos un programa. Si a esta CPU no le ponemos su pila correspondiente, una vez que la desenergicemos y nos vayamos a dormir, al día siguiente nos encontraremos con la sorpresa de el programa ha desaparecido nuevamente. Sí, aunque esté conectada a una fuente de alimentación. Y no es que la CPU esté defectuosa, sino simplemente que, al quitar nosotros la energía eléctrica, al no tener batería, perdemos lo almacenado en la memoria RAM. Recordemos que la memoria RAM es una memoria volátil, es decir, es una memoria no permanente, que al quedar desenergizada, pierde todo lo que tenía es sus microtransistores. Entonces, ¿cómo hacer para que no se pierda el programa de esta memoria? Es muy sencillo. La memoria RAM de nuestra CPU puede recibir alimentación eléctrica ya sea conectándola a la fuente de poder de nuestro tablero, o mediante la conexión de una batería (claro, una batería en buen estado, del voltaje que marque el modelo de CPU, no cualquier batería). Incluso, la RAM puede recibir su suministro de energía por cualquiera de las estas dos fuentes al mismo tiempo, tanto de la fuente de alimentación como de la pila. Así, si desconectamos el suministro de energía al tablero donde está alojada esta CPU, el programa se mantiene en su lugar gracias a la batería incorporada en la CPU. En otro caso, podemos quitar la batería de la CPU mientras tengamos el tablero energizado, ya que de esta manera el programa sigue alimentado mediante la fuente de poder. Pero, si quitamos la pila y además apagamos el tablero, puedes decirle adiós al programa de la CPU y tu máquina estará muerta. Tampoco con el procedimiento contrario evitas darle un borrado completo a la memoria de la CPU; es decir, si primero apagas el tablero y luego retiras la batería. Es igualmente mortífero este procedimiento.
Entonces, ¿qué hacer para poder reemplazar la batería de una CPU sin que perdamos el programa de la RAM?
Primeramente, hemos de recordar que la memoria RAM necesita permanecer energizada para que pueda conservar su programa. Así que, si notamos que el foco rojo que indica batería agotada enciende en nuestra CPU, no nos asustemos. Pero, importante, no desenergicemos el tablero. Y, antes que nada, respaldemos el programa de nuestra CPU y pongámoslo en lugar seguro. Enseguida, consigamos una pila apropiada para el modelo de la CPU. Una vez que ya tenemos respaldado el programa, y la pila nueva en nuestras manos, entonces, con el tablero energizado (y, por supuesto, la CPU energizada), extraigamos la batería agotada, e insertemos la nueva. Inmediatamente hemos de notar que el foco rojo de pila agotada se ha eliminado. Y eso fue todo. Nuestra máquina sigue trabajando como si nada hubiera pasado, y tenemos la seguridad de que la nueva batería respaldará durante mucho tiempo el programa aunque desenergicemos el tablero.
Ahora, si lo que queremos es precisamente lo contrario, es decir, queremos borrar lo que tenemos en la memoria de nuestra CPU, ya sea porque el programa será reemplazado por uno nuevo y completamente diferente al actual, o si queremos usar esta CPU en otra máquina que no trabaja con el programa que trae en su memoria, simplemente desenergicemos el tablero y extraigamos la batería y esperemos unos segundos. Cuando volvamos a energizar nuestra CPU, nos daremos cuenta de que no tiene ya programa.
Finalmente, unas recomendaciones. Es importante respaldar todas las CPU's de nuestras máquinas, ya que en el momento menos pensado, falla la batería sin darnos cuenta, llega el fin de semana y apagamos todo, y, para el día lunes... ya no tenemos programa en la CPU. Por esta misma razón, llevemos un control de la vida de cada batería. Los fabricantes nos dirán cuál es la vida útil de cada batería (uno o dos años) y estaremos preparados con los reemplazos correspondientes. No reemplacemos una batería agotada por una de diferente voltaje, pues correríamos el riesgo de dañar la memoria de nuestro PLC, y entonces, tendríamos que reemplazar toda la CPU.
Por último, remitámonos al manual del fabricante de cada CPU para cada caso particular, ya que lo que aquí se ha expuesto, ha sido en líneas generales no aplicables universalmente, y con el fin de acentuar la importancia de mantener en buen estado las baterías de nuestras CPU y tener el cuidado necesario al momento de reemplazarlas.
Ahora, a cargar baterías...

Nota ecológica: No tirar a la basura ningún tipo de baterías, sea de medio uso o totalmente agotada, sino depositarla en su contenedor correspondiente, o entregarlas a las corporaciones encargadas de su manejo.

Read More

Misteriosa Falla en PLC Siemens (tarjeta FM 354)

SI-300-001

Hace algunos días, me encontraba en una planta de visita.
Mientras recorría las líneas de producción, una persona de mantenimiento se me acerca y me pregunta si lo podría ayudar a resolver un problema en una máquina. Para saber si llevaba las herramientas adecuadas, le pregunté cuál máquina era y qué PLC tenía. Esta persona me dijo que se trataba de una máquina envolvedora de producto, la cual trabaja con un PLC Siemens de la línea S7-300.
Por suerte, llevaba conmigo tanto la lap-top como el cable de comunicación para este PLC, con lo cual me ahorré el tiempo de ir a la oficina por las herramientas indipensables.
Ya estando en la máquina, empecé a ver los detalles del problema. La persona de mantenimiento y el operador de esta máquina me comentaban que todo trabaja bien en forma manual, sin marcarles ninguna falla. Incluso, podían referenciar el eje principal sin complicaciones. Sin embargo, al poner la máquina en modo automático, de pronto la máquina se detenía completamente, se iba a falla, y en el Panel de Operador, aparecía el texto de alarma de "Falla en el Eje Principal", lo cual indicaba que había un problema en torno a los componentes del servo. Podría ser el servo motor, o el cableado, o el módulo FM-354, un problema de programa, un error de configuración de valores en el Panel, u otra falla.
Una vez que se alarmó la tarjeta FM-354, me conecté a la CPU y revisé el búffer de diagnóstico. Mi sorpresa fue que aquí no encontré ninguna falla registrada, ni en la red Profibus, ni en ningún otro componente. Como tenía un respaldo del programa de esta misma máquina, hice la comparación de bloques, con el fin de saber si había alguna modificación hecha por alguien más. Pero tampoco encontré diferencias en los programas. Me puse a monitorear el programa mientras se ponía la máquina en producción automática para detectar alguna anormalidad. Sin embargo, ocurría la falla, y no detectaba nada raro, incluso, ni siquiera perdía la comunicación con la CPU, pensando en que ésta pudiera estar fallando.
A continuación, el personal de mantenimiento desenergizó el tablero completamente y sustituyó la tarjeta FM-354 del PLC. Y se reiniciaron las pruebas. Pero nuevamente la máquina se detuvo en pleno ciclo de producción, marcando la falla en el Eje Principal. La FM-354 encendía su led rojo. ¿Le faltaba alimentación eléctrica? No, estaba bien conectada y alimentada.
Las cosas se estaban poniendo difíciles, y la línea tenía que arrancar ya; la producción estaba bastante atrasada.
Deje a un lado la lap-top y el monitoreo del programa. Me puse a observar el PLC. Pedí que se pusiera en marcha la máquina otra vez en automático. Y lo que pude observar en el momento en que apareció la falla, se me hizo algo bastante extraño. Lo que ví fue que los leds de todo el PLC, de la CPU, de las tarjetas de entradas y salidas, de la tarjeta FM-354, por unos instantes parpadeaban; era un parpadeo casi imperceptible; ¿sería un parpadeo normal en la operación de la máquina? Tal vez, pero no consideré que algo raro había en ese parpadeo. Y es que a continuación de ese parpadeo, ocurría que fallaba la tarjeta FM-354.
Nuevamente se arrancó la máquina, y sí, otra vez el parpadeo, y otra vez la falla.
De ahí que supuse que había un problema eléctrico en la máquina, ya sea que la fuente de alimentación del PLC estaba fallando o que había un corto circuito en alguna parte de la máquina.
Se procedió a cambiar la fuente de alimentación. Una vez sustituida, se arrancó la máquina, y... nuevamente falló. Así que, supimos que la fuente de alimentación no era el problema; el parpadeo siguió, la falla de la FM volvió a aparecer.
La tarea más laboriosa estaba por empezar: rastrear el componente que estaba haciendo corto. Por la forma en que se presentaba la falla, supusimos que era un sensor. Así que se revisó sensor por sensor, y, luego de un rato, se encontró el sensor fotoeléctrico causante del problema. Este sensor estaba roto, y al rotar el mecanismo de la máquina, ocasionaba que el sensor se aterrizara provacando un corto momentáneo, suficiente para mandar a falla la fuente de alimentación, y ésta a su vez, ocasionar que la máquina se detuviera.
Hecho el cambio del sensor, todo volvió a la normalidad.

Read More

Expediente PLC: La Historia (1)

Comenzaba a caer la noche cuando llegamos a la fábrica. Era un atardecer como cualquier otro en estas latitudes, un clima templado, un sol que comenzaba su caída por el horizonte. Lo que no era como cualquier otra cosa, era mi nerviosismo. Con apenas un curso de Step 5 tomado hacía unas semanas, con cero experiencia en el mundo de la automatización, y con la fría compañía de mi ex-jefe, iniciaba mi camino en este ámbito del control industrial.
Nos anunciamos en la caseta de vigilancia, nos registramos y dirigimos nuestros pasos al interior de la nave junto con uno de los supervisores de mantenimiento. Al ingresar a aquella fábrica, la primera sensación que tuve fue de vértigo, era una nave inmensa, donde había infinidad de máquinas y de operadores haciendo miles de piezas por minuto, robots moviéndose automáticamente de un punto a otro con una gran exactitud y a gran velocidad, olor a aceite quemado por cada pasillo, toda la gente vistiendo el mismo uniforme, pero todos sumamente concentrados y con el semblante expresando que tenían dominado al monstruo que tenían rugiendo delante de ellos, maquinando piezas con una enorme precisión, y el ruido constante de miles de motores trabajando al mismo tiempo era sumamente molesto, al grado de resultar difícil entablar una conversación sin evitar usar el recurso de elevar el volumen de la voz.
Aquella sensación que me invadió, podría haber derivado en temor, y ese temor en... huida. Sin embargo, en cuestión de segundos tuve que realizar algunos ajustes en mis procesos mentales, y sobreponerme a esta primera impresión. La adrenalina de ese momento me acompañaría durante mucho tiempo después. Imaginé que a muchos les pasaría algo similar a mí, y que muchos optarían por buscar un trabajo de no tanta exigencia mental, y ver los toros desde la barrera. Pero eso no sería mi caso, y decidí continuar, sólo para... llevarme más sorpresas ese mismo día.
Caminamos durante varios minutos para llegar finalmente a la línea de producción donde teníamos que intervenir. Justo en ese lugar, se retiró el supervisor que nos guiaba, y procedimos a realizar nuestro cometido. "Conéctate", fue la instrucción que me dió mi jefe una vez que localizamos la CPU. Aquella era una CPU S5-95U. En ese tiempo, era considerada una maravilla de PLC, con una fuente de alimentación integrada, entradas/salidas digitales y analógicas integradas también, entradas de contador rápido, y funciones de comunicación. Todo esto, en una sóla CPU. Bueno, lo que me salía muy bien, si el mugre cable de conexión no tenía alambres desoldados, era el conectarme a las CPU's S5. Saqué mi portátil, la encendí, corrí la apliación Step 5, e hice la conexión del cable adaptador de TTY a RS-232 entre la CPU S5-95U y mi compu. Al dar , se estableció la comunicación entre el PLC y el Step 5. Todo iba bastante bien, excepto que apenas podía controlar mis pensamientos y mi sudoración.
Hecha la conexión, siguiendo el sabio consejo de mi ex-jefe, hice un respaldo de todos los programas de la CPU, incluyendo los OB's, los FB's, los PB's, los DB's. Una vez hecho este respaldo, hago una copia de este archivo, y trabajo sobre este nuevo. Hasta allí, todo lo recuerdo bien. Lo que no recuerdo es qué demonios íbamos a modificar, si un ciclo, si un tiempo, si el respaldo de un valor de proceso (número de piezas, posición, presión, etc.) en una variable, si adaptar un valor para el panel, no lo recuerdo. Bueno, supongamos que era almacenar un valor generado por el ciclo de la máquina en una DW (Data Word) del DB (Data Block 10).
Pues bien, hago la modificación en el programa que tengo en la portátil, agregando algunas líneas de programa utilizando el editor del Step 5. Esto lo hago, mientras mi ex-jefe les explica a los operadores de la línea la modificación que se va a realizar. Es una explicación breve, en palabras comunes y corrientes, sólo que esa petición convertirla a instrucciones de PLC, no resulta ser tan sencillo, y menos cuando se es principiante. Miles de acrobacias mentales hay que hacer para dar con el resultado esperado. Pones a trabajar tu mente, y te salta y asaltan ideas por doquier, sin saber cuál te ofrece la mejor opción. Todas sus ofertas parecen atractivas, pero luego de analizarlas por unos segundos, te das cuenta de que son una burrada. Cuál elijo? Cuál resuelve mi problema? Cuál es la solución más sencilla? Será sencilla, pero, cómo la traduzco al programa? Y si me tardo mucho y mi jefe se desespera? Tal vez me despida? Tengo los conocimientos necesarios para esto? No será que necesito ejercitarme primero antes de que mi jefe me mande al ruedo? Qué rayos hago aquí, tan tarde? Será mejor decirle a mi jefe que lo haga él, y la próxima lo hago yo? No! Lo voy a hacer yo, sin su ayuda. Ahora está sumergido en una amena pero superflua charla con uno de los operadores; tan despreocupado uno como el otro, mientras yo me desgasto las neuronas por darle gusto y lo hago quedar bien con los supervisores. En fin... aquí estoy. He escrito todas las instrucciones necesarias; he revisado el programa una y otra vez, y, creo que está bien. Así que... a descargarlo al PLC...
¡Foco rojo de Stop en la CPU! ¡El programa no se ejecuta! ¡La línea de producción se ha detenido! ¡Los operadores se quejan de que ya no trabaja ninguna estación!
Antes de que mi jefe deje su insulsa conversación, se dé cuenta de lo que pasa, y venga a ver qué rayos hice, en cuestión de segundos abro el programa que respaldé al llegar a la línea (el programa con el que el PLC trabaja bien), y lo descargo a la CPU. Pongo el selector de la CPU en "Stop" primeramente, y en seguida lo pongo en "Run". Foco verde de "Run" encendido.
La línea vuelve a trabajar. Y yo vuelvo a respirar.
Todos los operadores se ocupan en probar que todo trabaje correctamente. Se acerca mi jefe, y en voz baja me pregunta que qué fue lo que hice. Le dije que había escrito varias líneas de programa que, a mi ver, hacían lo que me solicitaban, y además eran correctas todas las instrucciones. Una vez que ya tenía todo listo, lo cargué a la CPU, y se fue a falla.
Me preguntó si había respaldado el programa modificado, y le dije que no, a lo que me contestó que eso era un error. Luego me preguntó si me había puesto a revisar en la CPU la causa de la falla, y también le dije que no. "Otro error", fue lo que me respondió.
Se hizo tarde en aquella ocasión, y nos retiramos de la fábrica. No volvimos a tocar el tema. No volví a hacer la modificación solicitada. Creo que nunca se hizo. Pero sí volví a la misma línea, a la misma CPU en repetidas ocasiones a realizar otros y diferentes cambios. Y la CPU no volvió a irse a "Stop". Incluso, también llegué a modificar el panel tiempo después. Hoy en día esa línea sigue con la misma CPU, trabajando como antaño. Y hoy sigo recordando ese día, el día en que me inicié en la automatización. Reflexiono en qué sería lo que escribí para que el PLC se fuera a falla. No hice ninguna función de salto. No utilicé banderas duplicadas, no direccioné entradas fuera de rango. Quizá direccioné un DB que no existía o una DW fuera de rango.
"No guardé el programa modificado", fue lo que le dije a mi jefe, para que no lo analizara y me dijera en dónde estaba la burrada que había cometido y sirviera para hacer más extenso su sermón.
Sin embargo..., sí lo guardé. Guardé el programa que modifiqué y que llevó a falla la CPU. Y lo he vuelto a revisar para encontrar el error... y no hay error!
He cargado este mismo programa en otra CPU S5-95U, y no se va a falla!
Algo raro pasa con esa CPU de esa fábrica.
Qué diferencia hay entre esa CPU y esta otra? Capacidad de memoria? Versión de la CPU? Qué está pasando?
Algo extraño sucede con estas 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 SLC-500, quizá en lo primero que solemos pensar es en que vamos a utilizar un cable de comunicación PIC (bueno, así lo conocemos, aunque el de forma completa es 1747-PIC). Esto es cierto sólo para 3 tipos de CPU's de los 5 tipos que hay. En otras CPU's, hemos de emplear un cable de comunicación RS-232, e incluso, hasta un cable tipo DH+.

Esta versatilidad de la familia SLC-500 para comunicación, puede convertirse también en un buen acertijo a la hora de querernos comunicar a la CPU. Nos llaman de una fábrica "X" (sí, a la hora que sea), y nos dicen que tienen un problema en el programa del PLC. Asumamos que, luego de un largo cuestionario, concluimos que la causa del problemas está en las intrincadas líneas del programa de la CPU. Así que le preguntamos a este señor que nos involucra en sus apuros, qué tipo de PLC es, y sólo atina a decirnos que es un SLC, es uno de los cuadrados medianos de Allen-Bradley. Es un SLC 5/02, o SLC 5/03 o cuál? Preguntamos. Y nos dice, que sí, o más bien que cree que sí, que es un SLC 5/03, pero no está seguro. Rayos!, mejor ni nos confiamos y nos armamos con todos los cables que tenemos. Y nos lanzamos a ver qué sucede con el dichoso PLC. Y cuando llegamos a la planta, resulta que es un SLC 5/01. Bueno, por lo menos, nos preparamos con todos los cables.

Se preguntarán, ahora ustedes, cuál cable es para qué CPU del SLC-500. Para contestar a esta pregunta, recurrimos primero a la siguiente tabla para saber qué tipo de puerto de comunicación trae cada CPU:

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)

Una vez que definimos la CPU y a qué puerto nos vamos a comunicar, seleccionamos el tipo de cable que necesitamos, de acuerdo a la siguiente tabla:

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, bastará con tener el cable PIC (1747-PIC) y un cable RS-232 (1747-CP3).

Listos para conectarnos...

Read More

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

Luego de algunos días en los que anduve bastante ocupado, vuelvo a darle continuidad a este blog.

Es cosa que pasa muy seguido cuando vives en este mundo de los PLC's. Hay días en los que todo marcha bien, que las máquinas se sienten felices trabajando, ninguna falla, y crees que ya tienes todo bajo control. Pero luego hay esos días nefastos en que todo parace confabularse para sacarte de quicio: un equipo que estuvo trabajando bien, lo apagas y ya no quiere funcionar; una máquina en una línea crítica presenta una falla recurrente, que por más que le buscas, no das con el elemento dañado; luego, por si fuera poco, es sábado por la noche y no hay forma de conseguir refacciones. Cuando esto se te junta, te olvidas de todo (incluso hasta de comer y dormir) y te enfocas todo el tiempo a encontrar la falla en la máquina. Hasta que medio funciona, te das un ligero respiro y te alejas con mucha desconfianza de dicho equipo, no sea que una vez que le des la espalda, aproveche para volverse rebelde y falle, ocultándote el momento en que se descompuso, con lo cual pierdes valiosa información para comprender lo que está pasando. Así que, regresas casi maldiciendo a la máquina y te das a la tarea detectivesca de dar con la intrincada causa del problema... hasta que lo resuelves. Ahora sí, a ir a otro equipo que ya te está esperando desde hace horas (o días) para que le quites su empecinamiento a no querer trabajar... Y este ciclo puede repetirse una vez o multiplicarse casi hasta el infinito, sin darte tiempo de hacer más nada.

De esta forma, hay días en que tranquilamente puedo dedicarme a este blog, y, en cambio, durante otros días, estoy fuera de la jugada atendiendo algún problema en alguna fábrica.

Al estar trabajando de cerca con todas esas máquinas de diversas plantas, a veces dedicándoles horas o días, te vas adentrando más en su funcionamiento, al grado de que asimilas la experiencia necesaria para aplicarla cuando vuelva a surgir la misma falla o algo similar ocurra en otro equipo. Vas aprendiendo.

Como hay gran variedad de máquinas, obviamente muchas serán completamente diferentes unas de otras. Si fueran todas iguales, qué alivio, lo que le falle a una, sabrás cómo arreglarlo en la otra; es decir, si llegas a conocer bien sólo una de ellas, ya sabrás cómo trabajan todas. En este caso, dominas una, y muy pronto podrás gozar de una vida tranquila. Por el contrario, si las máquinas son diferentes, en operación, en cableado, en control, en lo mecánico, en lo hidráulico, en comunicaciones, etc., sabrás que te llevará mucho tiempo conocer a cada una, y muchas veces no podrás aplicar lo que aprendiste de una máquina en la otra, por lo que dominar todos los equipos llevará mucho más tiempo. Lo bueno de conocer varias máquinas que son diferentes entre sí, es que aprendes más; en cambio con máquinas iguales o teniendo sólo unas dos o tres, aprendes poco, pero tus problemas son relativamente pocos.

Me sucede por lo regular que tengo que atender problemas en máquinas diferentes. Algunas son sencillas, otras son más complicadas. A veces los equipos son muy viejos, y en otras ocasiones son de última tecnología. Pero de todas las máquinas aprendes algo. No todas hacen lo mismo, ni traen los mismos controles, ni los mismo PLC's. Y aunque muchas hacen productos en serie, pareciera que ellas mismas no estuvierna hechas en serie. Por muy parecidas que sean, algunas cambian debido a que algunas funciones no se requieren para una determinada línea de producción y otras funciones sí, o el cableado eléctrico se realizó de manera relativamente diferente, o, incluso, el PLC que incorporan trae una nueva CPU o nuevas tarjetas, o simplemente, el programa ha cambiado para que la máquina trabaje más eficientemente.

En fin, todo lo que voy aprendiendo en este mundo de los PLC's lo voy plasmando en este blog. A veces andaré algo ocupado, por lo que me alejaré por unos días del mismo. Pero con seguridad regresaré a redactar lo aprendido en esos días.

Aunque tengo varios años trabajando en esto de la automatización industrial, es fácil deducir que la literatura referente a la misma no la podré abarcar en su totalidad, ya que a diario aparecen nuevas mejoras tecnológicas, nuevas tarjetas, nuevos PLC, nuevas marcas, nuevos sensores, nuevos equipos, nuevas redes de comunicación, nuevos softwares, etc. Por lo mismo, no me considero un experto en el tema, aunque con el tiempo puedo aprender más y más (a veces bajo mucha presión), y resultarme más sencillo resolver un problema en una máquina. No pretendo dar cursos de PLC's en este blog ni transcribir o redactar extensos manuales técnicos; eso está fuera del alcance de cualquier blog. Podemos aprender mucho en cursos de PLCs, lo cual algo muy recomendable para familiarizarnos con los términos que se manejan en este mundo, y nos resulte más asimilable lo que leeamos en este blog. Sin embargo, algunas veces escribiré definiciones de términos raros, o detallaré algunos conocimientos básicos necesarios para entender el manejo de los PLC's. También escribiré procedimientos paso a paso para la realización de tareas de rutina con los PLC's, tales como respaldar un programa, configurar una tarjeta, crear bloques de datos, parametrizar un variador, etc.

Finalmente mencionar que con este blog sólo trato de registrar lo que voy aprendiendo, pues a veces lo detalles se van olvidando con el paso del tiempo, o simplemente, puede suceder que alguien (o yo mismo) se enfrente a una situación similar, y con esta experiencia tendrá una orientación de cómo resolver el problema. Para mí este blog será de gran utilidad, y espero que también lo sea para quienes lo lleguen a leer.

Read More

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

SI-9X-001

Conforme pasa el tiempo, van apareciendo nuevas tecnologías, y van quedando obsoletos los equipos que hace unos años los considerábamos una maravilla.
Lo mismo pasa con los PLC's S5 de Siemens. Hubo un momento en que las máquinas modernas venían equipados con estos equipos. Incluso, era de cajón utilizarlos al desarrollar un proyecto de automatización industrial.
Muchos de esos equipos todavía los encontramos en varias plantas industriales.
Hace algunos días me encontré con S5-95U, el cual controla el desplazamiento de un carro transportador. Tiene funciones sencillas, como posicionarse en una estación indicada, avance y retroceso manual, y carga y descarga de producto.
Para su labor de posicionamiento envía una consigna analógica a un variador de velocidad, y mediante un encoder se da cuenta de en qué posición está ubicado.
Los equipos S5-95U tienen la ventaja de ofrecer integrada una CPU para el procesamiento del programa, entradas y salidas digitales, entradas y salidas analógicas, entradas de contador, fuente de alimentación, todo esto en un sólo módulo, sin necesidad de comprar nada más. Es un equipo bastante completo, por lo que lo hace bastante versátil y sea ideal para una gran cantidad de aplicaciones... bueno, era ideal, en aquel tiempo; hoy ha sido desplazado por el S7.
Hay muchos temas para hablar de esta CPU, sólo que nos centraremos en sus señales analógicas integradas, dado que me encontré con esta aplicación particular del carro transportador.
Como decía, el carro se mueve en función de un motor controlado por un variador de velocidad. A este variador de velocidad se le manda una consigna de velocidad a través del módulo S5-95U.

Este módulo maneja una sóla señal de salida analógica, que puede ser de corriente de 4 a 20 mA o puede ser de voltaje de 0 a 10 V. Así que, el variador lo configuramos para que cuando reciba 0 Volts, tenga una velocidad de 0 Hz, y cuando en sus bornes de entrada tenga un voltaje de 10 Volts, le estaremos indicando que trabaje a toda su capacidad (en la mayoría de los casos, 60 Hz). Un voltaje intermedio hará que el variador se mueva a una velocidad intermedia correspondiete a este voltaje. Si, por ejemplo, aplicamos 5 Volts al variador mediante esta salidad del PLC, el variador trabajará a la mitad de su velocidad máxima configurada (30 Hz, cuando su fmáx = 60 Hz).
Para direccionar esta salida analógica integrada del módulo S5-95U, utilizamos la QW40 en el programa.
Las entradas analógicas del S5-95U son un total de 8, las cuales se direccionan como IW40 a IW 54 en el programa del PLC.
En temas sucesivo, veremos ejemplos de programación de estas señales de entradas analógicas.

Read More

Cómo normalizar una señal de entrada analógica

TyC-005

Hace algunos días me tocó revisar una falla en una máquina con un PLC CompactLogix.
El problema me lo describieron de la siguiente manera: Se cambió un sensor de nivel tipo varilla de un tanque que recibe producto. Luego del cambio, en la pantalla del panel operador, se observó que cuando el tanque se llenaba, el valor de nivel desplegado indicaba 100%, lo cual era correcto, pero cuando se vaciaba el tanque, el valor se iba a -65252%, un valor incorrecto.
Se revisó primeramente que el sensor de nivel no estuviera mandando un valor equivocado, por lo que se revisó la corriente que enviaba. Sin embargo, se encontró que realmente variaba correctamente su valor, de 4 a 20 mA, conforme se disminuía o aumentaba el nivel del tanque.
A continuación se revisó que la tarjeta del PLC de entradas analógicas, estuviera leyendo correctamente la señal. Pero también se tenía una correcta variación de la señal.
El siguiente paso fue revisar el programa.
Aquí en el programa encontré una sencilla forma de normalizar esta lectura de nivel analógico, la cual se base en una sencilla fórmula:

y = d * VE - comp

donde

d = (LS - LI) / (VSE - VIE)

comp = d * VIE

definiendo los términos, tenemos que:

VE: Valor actual de la entrada analógica
comp: Valor de off-set para compensación de la lectura analógica
LS: Límite máximo superior normalizado
LI: Límite máximo inferior normalizado
VSE: Valor de límite superior de la entrada analógica (cuando recibe 20 mA)
VIE: Valor de límite inferior de la entrada analógica (cuando recibe 4 mA)
d: Relación entre los límites normalizados y los límites leídos en la entrada analógica
y: Valor normalizado de la lectura analógica

Para darle el uso correcto a esta fórmula, procedemos de la siguiente forma:

1. Primero establecemos los límites superior e inferior normalizados. Para nuestro caso, como queremos leer un valor de nivel de un tanque, nos interesa saber si el tanque está lleno (100%) o está vacío (0%). Así que, LS = 100 y LI = 0. Los valores intermedios, quedarán en este rango.
2. El siguiente paso es definir el valor del límite superior de la entrada analógica. Para ello, hacemos que nuestro sensor nos mande 20 mA, y anotamos el valor que leemos en nuestro PLC. Si, por ejemplo, cuando tenemos 20 mA leemos en nuestra entrada analógica el valor de 50000, éste lo tomamos como nuestro valor VSE. Así, VSE = 50000
3. De una manera similar al paso anterior, procedemos a definir el valor para VIE. Cuando nuestro sensor nos mande 0 mA, anotamos qué valor rebimos en nuestra entrada analógica. Si recibimos el valor de 0, queda que VIE = 0

Al aplicar esta fórmula, tendremos que nuestro valor normalizado "y", variará de 0% a 100%, conforme varíe la lectura de la señal analógica.

Si, por ejemplo, tenemos en la entrada analógica una lectura de 25000, esto indicará que nuestro tanque estará lleno al 50% (valor normalizado).

El problema con quedó solucionado al calibrar los valores que mandaba el sensor de nivel cuando teníamos 4 y 20 mA.

A partir de esta calibración, la máquina trabajó satisfactoriamente.

Read More

Problema de Clonación de Disco Duro con Norton Ghost

TyC-004

Hace algunos días me dirigí a una empresa donde tenían un problema con un disco duro, aparentemente estaba dañado y no arrancaba el sistema operativo.
Hay varios puntos que poner en claro respecto al problema. En primer lugar, la CPU era de tipo industrial, pero ya viejita, con procesador 486. El disco duro que tenía era de 280 MB (leyeron bien, de 280 megabytes; no se rían, es en serio, realmente existieron y existen estos discos con estas capacidades). El sistema operativo era MS-Dos (qué términos tan raros, dirán los que sólo saben de la existencia de Windows). Y, por supuesto, la aplicación corre sobre este sistema operativo. Lo normal es que prendas la máquina, encienda la pantalla, cargue el sistema operativo, y corra la aplicación.
Pero la falla que me comentaron fue que la máquina estaba prendida y la aplicación corriendo, sólo que de improviso se congeló y ya no se respondió. Por lo que se procedió a apagar el equipo, y luego de unos segundos, se volvió a encender. Sólo que ya no arrancó la CPU.
Se pensó que el problema era el disco duro, que tal vez se había dañado.
Me entregaron el disco duro para revisarlo. Lo conecté como maestro al IDE-1 de una PC de escritorio, y en el IDE-0 conecté otro disco duro con Windows XP. Encendí mi PC y entré de forma normal, sin hacer ajustes adicionales.
Ya en Windows, revisé el disco duro, pero no encontré problemas. Enseguida, procedí a respaldarlo con Norton Ghost. Una vez respaldado, apaqué mi PC.
Probé el disco duro que se presumía dañado, pero sí arrancó, y la máquina la pusieron a trabajar. Al revisar la CPU de la máquina se observó que el ventilador no estaba trabajando, lo que quizá produjo un calentamiento excesivo y bloqueó la aplicación.
Luego de que trabajó la máquina, procedí a clonar el disco duro respaldado en otro disco de 210 MB (sí, más pequeño). Sin embargo, Norton me marcó error al clonarlo. Probé con otro disco, de 8 Gigabyte (pero este disco no lo reconoce una tarjeta madre con procesador 486), y la clonación se realizó con éxito. Así que deduje que el problema era que el Norton Ghost no puede clonar de un disco de un tamaño a un disco de menor capacidad. Quise clonar uno de 280 MB en uno de 210 MB, pero no pude con el Norton Ghost. Al ver la aplicación, del disco original me dí cuenta de que sólo ocupaba 10 MB del disco!, y 270 MB estaban libres, sin ser ocupados por nada.
Tuve que implementar el plan B. Formatée el disco de 210 MB y le transferí el sistema operativo MS-Dos. Una vez hecho esto, copié todos los archivos (10 MB) del disco duro de 280 MB al disco de 210 MB con el método de copiar y pegar. Copié incluso los discos de sistema y ocultos. Hecha esta copia algo extraña, probé el disco duro "clonado" en mi PC, y... sí arrancó en MS-Dos y ejecutó la aplicación correctamente.
El disco clonado quedó listo para ser usado como relevo una vez que se dañe el original.

Read More

Falla de Comunicación entre Panel Omron y Controles de Temperatura

OM-PAN-001

Con frecuencia me encuentro ante el mismo problema en una máquina llenadora.
Tiene un Panel Omron NS-12 que se comunica a un CompactLogix por su puerto COM1. A través del COM2, el Panel se conecta a un grupo de controles de temperatura también marca Omron con las que se controla un grupo de resistencias de calentamiento, midiendo la temperatura con sus respectivos termopares.
En la interfase de operador encontramos una pantalla donde se tiene la configuración del control de temperaturas. En esa pantalla visualizamos las temperaturas actuales de cada zona, además de que se puede ajustar el set-point para cada una de ellas. Una vez puestas en automático, la regulación de la temperatura es tarea de estas tarjetas de control (ocho en total).
El problema que se presenta muy frecuentemente es que algún termopar deja de funcionar, al dejar de funcionar, no se lee la temperatura real de la placa de calentamiento, sino un valor prácticamente de cero, por lo que la resistencia continúa calentándose tratando de alcanzar el set-point (pero con el termopar dañado, nunca la alcanzará). Este sobrecalentamiento daña el producto, y, en muchas ocasiones, también se daña la resistencia de calentamiento y los relevadores de estado sólido que conmutan el paso de corriente a éstas. A veces pasa que se llega a dañar incluso el control de temperatura Omron.
Bueno, cuando ocurre un problema por el lado del calentamiento, se suele cambiar este control de temperatura. Sin embargo, cuando se reemplazan, ocurren problemas.
Uno de ellos es que al accesar la pantalla de temperaturas en el panel, éste se bloquea unos momentos para luego desplegar error de comunicación en el puerto COM2. La pantalla, entonces, se bloquea y deja de desplegar algunos (a veces todos) valores de temperatura de las zonas.
Para solucionar este problema, que por lo regular no es el cableado ni la configuración de comunicación del Panel, necesitamos concentrarnos en los controles de temperatura Omron. Cada uno de estos controles tiene dos selectores múltiples. El selector inferior nos sirve para configurar la velocidad de comunicación. En nuestro caso, según los diagramas eléctricos de la máquina, este selector ha de ser colocado en el número 3 para todos los controles de temperatura. Una vez que hemos configurado la velocidad de comunicación de todos los controles a la misma velocidad, procedemos a ajustar el selector superior, cuyo valor indicará el número de nodo para cada control. No puede haber dos o más controles con este selector superior apuntando al mismo número. Cada control tendrá un número específico y diferente al de los demás. Atendiendo los diagramas eléctricos, ajustamos los selectores del 0 al 7.
Como decía, en algunas ocasiones se cambia un control de temperatura, pero no se atiende a la posición de los selectores, lo cual trae como consecuencia el bloqueo del panel y falla en la red, como se comentó en líneas precedentes.
La correcta sustitución de un selector se hará, entonces, respetando la posición de los selectores del selector que queremos eliminar para estos ajustes aplicarlos en el control que vayamos a colocar. Así, el control reemplazado y el nuevo habrán de coincidir en los dos selectores de manera correspondiente, el selector superior del equipo viejo con el superior del equipo nuevo, y el selector inferior del equipo viejo con el selector del equipo nuevo.
Una vez hecho este ajuste, insertar correctamente el módulo de control de temperatura, ya que una colocación inadecuada, trae como consecuencia los mismo problemas descritos arriba.
Finalmente, asegurarnos que los selectores apunten correctamente a su valor, ya que una colocación intermedia (que apunte entre el 2 y el 3, por ejemplo), también nos traerá fallas.

Read More

Nueva Línea de PLC's Siemens: S7-1200

SI-S7B-001

Damos un salto "gigantesco" de los equipos S5 mencionados en el post anterior, para darle la bienvenida a esta nueva gama de PLC's Siemens, la línea S7-1200.

Sí, tanto su nombre como su diseño evocan un S7-200. Pero el S7-1200 lleva consigo más y mejores funcionalidades que el S7-200.
El S7-1200 es un PLC modular miniatura. Cuenta con una interfase PROFINET integrada para comunicación con equipos HMI o con otros PLC's. Integra funciones tecnológicas para conteo, funciones de lazo de control, y control de movimiento. Por si fuera poco, tiene integradas señales digitales y analógicas. tanto de entrada como de salida. Y también acepta varios módulos de comunicación con los cuales se pueden transferir datos a/desde otros equipos.
Este PLC ofrece una máxima automatización por un bajo costo (una excelente opción para la solución de muchas tareas de control).
Por su tamaño compacto, puede ser instalado en espacios pequeños de manera rápida y simple.
Finalmente, la programación es sumamente sencilla a través de su software "Step 7 Basic".

Realmente creo que este PLC promete mucho, y pronto lo veremos implementado en varios equipos y sistemas de automatización. Interesante, no les parece?

Read More

Tipos de Datos en Step 5

Si-S5-001

Step 5 ha sido una herramienta de programación para los PLC's Siemens de primera generación. Algunos años ya han pasado desde que apareció esta línea de PLC's, por lo que, a la hora de darle un vistazo al pasado, surgen dudas de todo tipo, tanto en relación al hardware de los sistemas S5 como del manejo del software Step 5.
Una de esas dudas está en relación a cómo representar un valor numérico, como puede ser una temperatura, una posición, un set-point, etc.
Dentro de Step 5 se codifica esta representación de un mismo dato, de un mismo valor. Para nosotros, acostumbrados a manejar el lenguaje decimal, leemos datos como, por ejemplo, la cantidad de objetos producidos por una máquina. Esta máquina guarda en una de sus variables de datos, este valor de producción, que, en un momento determinado puede tener el valor de 179 (en el sistema decimal). Pero, cuando lo queremos visualizar en la computadora que tenemos conectada el PLC, necesitamos especificarle al software cómo queremos leer este valor. Para ello nos ayudamos de la siguiente tabla:

Formato Denominación del Formato
--------- ----------------------------

KH Hexadecimal

KF Número en coma fija (sin punto decimal)

KG Número en coma flotante (con punto decimal)

KT Valor de temporización con base de tiempo

KZ Valor de contaje

KY Byte

KM Representación binaria

KC Formato de texto

Con la ayuda de esta tabla, podemos leer el valor de la producción en el formato que mejor nos convenga. Así, por ejemplo, tenemos lo siguiente:

KH = C5 (representación hexadecimal)

KF = 197 (representación decimal)

KY = 12, 5 (representación en bytes)

KM = 1100 0101 (representación binaria)

Aunque la representación varía, el valor (197 decimal) es el mismo. Es decir, podemos representar un valor en diferentes formatos, según nos convenga.

De esta manera, podemos elegir el formato apropiado para el valor específico que queramos leer. En este caso, el valor de producción de una máquina la leemos en formato decimal (coma fija), al igual un valor de velocidad, la temperatura de un horno, etc.

Pero, si, en otro caso, estamos monitoreando qué señales se activan en una tarjeta de entradas digitales determinada, no nos servirá ni el formato KH, ni el KF, sino que utilizamos el KM donde podemos ver bit a bit el status de cada una de las señales de forma individual.

Finalmente, tenemos dos formatos específicos: para leer el valor de temporización de un timer, utilizamos el formato KT, y para un contador, el formato KZ. Esto es así, debido a que los valores de tiempo y de contaje están codificados, según normas ya establecidas en el sofware.

Read More

Diferencia entre IDE y SATA

TyC-003

En el mundo de las computadoras, la tecnología no se detiene. Continuamente van apareciendo nuevas innovaciones que hacen, en la mayoría de los casos, más eficiente el uso de nuestra PC.
Hace algunos años, encontrábamos en el mercado super discos duros de 2 Gigabytes de capacidad. Hoy en día nos reímos, ya que esta cantidad de gigas ya la trae la USB que usa nuestro chamaco en la escuela. Y mejor ni le decimos con qué dinosaurios nos tocó aprender computación en nuestro tiempo. Perderemos esa aureola de súper-héroe con que nos ven sus pequeños ojos.
Bueno, volviedo al punto, las mejoras que se han hecho en las computadoras incluyen mejores y potentes procesadores, mayor velocidad de procesamiento, más memoria RAM, optimización de las características multimedia, diferentes tipos de comunicaciones y más rápidas, y más capacidad en los discos duros, entre otras muchas más.
En lo que toca a los discos duros, encontramos, pues, que han crecido bárbaremente en capacidad de almacenamiento. Pero también ha aparecido un nuevo tipo de disco, el SATA. La diferencia más notable con respecto a los discos tipo IDE, es que los SATA son mucho más rápidos, esto es, para leer o escribir información. En la parte física encontramos que el IDE utiliza un cable de muchos hilos (40) para conectarse a la tarjeta madre (placa) de nuestra PC, mientras que el SATA necesita un cable delgado por el cual transfiere los datos.
Este mismo tipo de conexión aplica para otros dispositivos además del disco duro, como son las unidades de CD o DVD, los cuales pueden ser tipo IDE o SATA.
Si queremos sustituir un elemento IDE por uno SATA (ya sea porque queremos más capacidad o más velocidad), o queremos añadir uno nuevo, tendremos que destapar nuestra PC (o consultar su manual técnico) y ver si la tarjeta madre viene equipada para este tipo de conexión.
Si nuestra PC todavía trae conector IDE (el cable plano de muchos hilos), sabremos que la tecnología comienza a rebasarnos nuevamente, y, si nuestro presupuesto lo permite, pongámonos al día con la tecnología.

Read More

Estudio de Termografía: Herramienta Sumamente Recomendada

TyC-002

Iniciamos con una pregunta: Qué es la termografía?
La termografía está basada en la captación de la radiación que emite un cuerpo en particular. Al captar esta radiación mediante las técnicas e instrumentos adecuados, se puede interpretar a qué temperatura está el objeto.
Todo cuerpo que se encuentre a una temperatura por arriba del cero absoluto emite radiación infrarroja. Incluso el hielo (compuesto de agua solidificada) que conocemos, emite radiación infrarroja, ya que se encuentra a 0 °C. Pareciera que he mencionado una contradicción. Cómo es que cualquier objeto arriba del cero absoluto emite radiación, y por otro lado, el hielo, cuya temperatura es de 0 °C, digo que sí emite radiación? Al esta a 0 °C, el hielo no tendría por qué emitir radiación... No, no es una contradicción. Es cuestión de definir y entender los términos que estamos empleando.
Hay diferentes escalas de temperatura. Las más comunes que conocemos son la escala Celsius y la escala Farenheit. La primera divide la escala en grados centígrados (°C) y la segunda en grados Farenheit (°F). Adicionalmente, podemos convertir grados centígrados en grados Farenheit y viceversa, tal como nos lo enseñaron en la escuela.
Lo interesante es que existen otras dos escalas de temperatura. Una es la escala Kelvin y la otra es la Rankin. La escala Kelvin se deriva de la Celsius. Y la escala Rankin, a su vez, se deriva de la Farenheit.
Tenemos que en la escala Celsius nuestro cero (0 °C) se marca en la temperatura de congelamiento del agua, y el cien (100 °C) se fija en la temperatura de evaporación del agua, a nivel del mar. Pero existen temperaturas más frías que el 0 °C, así como temperaturas más elevadas de 100 °C. Si disminuimos la temperatura de un objeto, con el equipo y técnicas adecuadas, bajaremos de los 0 °C, llegando a -10 °C, -50 °C, -100°C, hasta llegar a un límite. Sí, no es posible enfriar más a ningún objeto existente en el universo por debajo de éste límite. Este límite es el -273 °C. Estamos en la escala Celsius, recordando. Pero precisamente es en este punto donde inicia la escala de la temperatura Kelvin. Aquí, a -273 °C, es donde inicia la escala Kelvin, aquí es su cero (0 °K). Es este punto al que llamamos Cero Absoluto. Al relacionar las escalas Celsius y Kelvin, tenemos que -273 °C equivalen a 0 °K, y 0 °C equivalen a 273 °K.
Todo aclarado, cierto?
Entonces, regresando al punto inicial, cualquier cuerpo cuya temperatura esté arriba del cero absoluto (cero grados Kelvin, más no cero grados centígrados), emite radiación infrarroja.
Es por eso que el hielo (a cero grados centígrados) emite radiación infrarroja, pues está lejos del cero absoluto (0 °K) por 273 °K.
Bueno, luego de este breve paréntesis, retomamos el tema de este post.
Para qué nos sirve saber a qué temperatura se encuentra los objetos de nuestra planta? Hablo de los equipos eléctricos y mecánicos, no de personas. Con esto de la influenza, a alguien se le podría ocurrir hacerle termografía a todo el personal de la planta para saber cuánta temperatura tiene cada individuo, y así saber si lo mandamos a su casa si anda con fiebre. Sí, pero yo me voy a enfocar en los objetos únicamente.
Con la termografía infrarroja podemos saber a qué temperatura se encuentran los equipos eléctricos y mecánicos en nuestra área de producción. Esta medición la hacemos a distancia, con un instrumento especial que capta la radiación de los objetos y nos da un espectro en escala de colores visibles al ojo humano de sus temperaturas.
Con la información recabada por la termografía, podemos identificar en nuestro tablero eléctricos o en nuestra instalación eléctrica, puntos calientes. Estos puntos calientes nos indican dónde hay fugas de energía. Incluso, con la ayuda de este estudio, podemos determinar problemas potenciales en nuestros equipos. Si un elemento, un fusible, un contactor, un bloque de contactos, muestra un calentamiento excesivo, es indicativo de que tenemos una fuga de energía, lo cual trae como consecuencia un consumo adicional de corriente eléctrica (ya que la alta temperatura opone resistencia al paso de los electrones en un conducto), carbonización de los elementos, e incluso, se podría generar un incendio, y en el peor de los casos, hasta una explosión en ciertos ambientes industriales. También podremos tener cables recocidos por el calor, que será necesario reemplazar, o quizá nos ocurra que las protecciones térmicas de nuestros tableros se estén disparando continuamente sin razón aparente.
Con la termografía podemos identificar estos problemas y evitarnos problemas mayores, en caso de que un elemento sobrecalentado llegue a fallar.
Pero la termograría también la podemos utilizar no sólo para identificar problemas eléctricos, sino también mecánicos. Podemos determinar qué tan bien están funcionando los motores, los cojinetes, bombas, compresores, y otros rodamientos. De esta forma, nos adelantamos a evitar que sucedan graves problemas en los equipos, lo cual se reflejará en ganancias para la empresa, ya que evitaremos situaciones lamentables donde tengamos tiempo de paro de la máquina (e incluso de la línea de producción en ciertos casos) debido a que no se pudo preveer el problema potencial.
Finalmente, se recomienda hacer un estudio de termografía a todos nuestros equipos eléctricos y mecánicos (los más críticos prioritariamente, aunque pueden ser sujeto de estudio todos los equipos) para saber en qué estado se encuentran. En base a los resultados que arroje el análisis termográfico, podemos realizar correcciones preventivas para eliminar los puntos calientes. Una vez hecho este mantenimiento correctivo, procedemos a realizar una segunda inspección termográfica con el objetivo de corroborar que efectivamente se eliminaron todos los problemas. Si no, con este segundo estudio, sabremos cuáles quedan por hacer una revisión y corrección más concienzuda.

Read More

Falla en Servo Movidrive de SEW-Eurodrive

SEW-MOV-001

Hace algunos días recibí una llamada de una planta donde me comentaban tenían un problema en un servo drive de la marca SEW-Eurodrive.
Cuando revisé el módulo, en el display de siete segmentos observé que aparecía la letra "F" y enseguida los números "1" y "4".
Una vez con esta información, me puse a revisar el manual para este drive, que es el manual "MOVIDRIVE (c) MDX60B / 61B, Instrucciones de funcionamiento".
Aquí encontramos que la letra "F" indica que existe una falla en el módulo. Para saber cuál es la falla, recogemos los números que aparecen en el display, que en este caso, corresponden al código de falla número "14". Este número nos indica que la falla está en el elemento "Encoder". Y la descripción de la falla nos da la pista de lo que anda mal, ya sea que el cable del encoder esté defectuoso o mal conectado, un cortocircuito en cable, o que el encoder esté dañado.
Consultando con el personal que detectó la falla, me comentó que el equipo estaba trabajando bien el día anterior, pero en la mañana se desconectó el equipo para hacer cambio de unas bandas, lo cual implica desconexión eléctrica de la máquina, desmontar el servo-motor, y quitar los cables de fuerza y del encoder. Sin embargo, al finalizar este trabajo del cambio de bandas, se volvió a cablaer todo y a montar el servo-motor, pero en el Panel de operación aparecía falla en servo. Como tenían la idea de que todo lo que habían realizado estaba correcto, pensaron que quizá era una falla en PLC (un SLC-500 de la marca Allen-Bradley), o quizá se había dañado el servo-motor, o, tal vez el defecto estaba en los cables de fuerza o del encoder, o hasta tal vez fuera el módulo SEW.
Así que optaron, primeramente, en sustituir el motor. El servo-motor se cambió, pero el módulo seguía indicando una anomalía. Entonces, lo siguiente que hicieron fue el cambiar el cable de fuerza. No funcionó tampoco. A continuación cambiaron el cable del encoder y... tampoco resultó.
Se resistían a cambiar el servo-drive, ya que se parametriza para una tarea específica, y si ponían uno nuevo, tendrían que configurarlo desde cero.
De ahí, que mejor prefirieron pedir ayuda.
Con esta información, descarté que el problema fuera, obviamente, el servo-motor o el PLC. El código de falla indicaba claramente que era el encoder o el cable del encoder.
Puesto que el nuevo encoder seguía marcando la misma falla en el módulo, descarté que el problema fuera el encoder; no es muy probable que dos encoders, uno usado y uno nuevo, dieran el mismo código de falla.
Como el tiempo es crítico, les pedí revisar el cable del encoder, que era lo más sencillo de hacer.
Al verificar continuidad en cada uno de los pines del cable, constatamos que no había ningún hilo roto. El cable instalado (el nuevo) estaba bien. Se conectó nuevamente... pero la falla seguía.
Optamos por retirar este cable nuevo y conectar el que estaba en uso cuando la máquina trabajaba bien. Una vez conectado... falla.
En este punto, empieza uno a pensar en soluciones descabelladas presa de los primeros síntomas de la desesperación. Los pensamientos se cruzan unos con otros. Qué estará pasando, es lo que cruza por la mente cuando el código de falla es evidente (falla en encoder o cable de encoder), y la lógica más lógica parece carecer de sentido con los caprichos de las máquinas. Será el módulo el que ya se dañó y esta falla es uno de sus síntomas? Cambiar el módulo? Revisar los parámetros uno por uno? Conseguir un tercer cable de encoder o un tercer encoder? Pero cualquier cosa de estas lleva mucho tiempo realizarlas, y aquí el tiempo es un gran adversario que está aquí para atormentar y entorpecer la ejecución de cualquier trabajo que requiere concentración y calma. Qué hacer entonces?
Paso uno, mantener la calma. Paso dos (y los que siguen), revisar los elementos involucrados en la falla más a detalle. Se revisa nuevamente continuidad en los cables de encoder. Todos los pines marcan bien. Muy bien, ahora a conectar ambos extremos. Uno de los extremos lo conectamos al módulo SEW, y observamos que entra bien, no se forza, no hay juego en el conector, no hay humedad ni algún otro agente contaminante. Ahora vamos a conectar el otro extremo. En este lado del conector, que no es un conector muy común, observamos que es redondo, así como el receptáculo del servo-motor donde va conectado. Es necesario girar el conector para enroscarlo y quede fijo. Al momento de atornillarlo notamos que se forzaba un poco. Parecía que esto era normal. Y se seguía roscando con fuerza. Una vez conectado, observamos que la falla seguía. Así que atendimos a este forzamiento del conector. Y encontramos que este forzamiento había provocado que los pines se hundieran, por lo que no había contacto físico entre el conector y el recptáculo, y, consecuentemente, no había paso de corriente, lo que provocaba que nunca llegaran las señales del encoder al módulo SEW.
Una vez que se pusieron en su lugar los pines, y revisado continuidad eléctrica, se volvió a conectar el cable, pero ahora se conectó roscando con cuidado y suavidad, sin que se forzara el apriete.
Y, finalmente, se eliminó la falla!
Por fin podría ir a descansar tranquilo.
La máquina volvió a trabajar como siempre.

Read More

CPU 5/04 a Stop por valor de tiempo en PanelView

AB-R500-001

Hace algunos días estaba programando una CPU 5/04, el cual está conectado a un PanelView 1000. En el PanelView programé los set-points de algunos temporizadores, los cuales tienen como función retardar la operación de unas bandas transportadoras.
Sucedió que en cierto momento en que se estaban probando los transportadores, me solicitaron aumentar el tiempo de retardo del paro de un transportador. Así que me dirigí al panel y escribí el valor de -10 (segundos). Como escribí rápidamente el valor y le dí en el teclado también de manera rápida, no tuve tiempo de reaccionar, y este valor enviado a la CPU trajo como consecuencia inevitable que la CPU se fuera a Stop, y, como es de esperarse, todos los transportadores se fueron a paro, ya que todos eran controlados por el PLC.
Bueno, esto me sirvió para darme cuenta de que necesitaba cuidar más las seguridades en la programación.
A continuación, lo que hice fue poner límites a los set-points de los temporizadores, y en caso de que alguien escriba un valor negativo, el programa se dé cuenta a tiempo y cambien el valor por cero. Estos límites los puse tanto en el programa de la CPU como en el del PanelView.
En conclusión, cuando necesitemos manipular los set-points de los temporizadores, cuidemos que estos valores nunca sean negativos, de lo contrario mandaremos inevitablemente a Stop nuestra CPU, y a su vez, provocaremos que toda la máquina (y hasta quizá la línea de producción completa) quede muerta por un tiempo, y, en ciertos casos, podríamos generar daños en los equipos, en los productos o hasta en las personas.
Así que, a tener cuidado a la hora de programar, no sólo los temporizadores, sino todos los elementos de nuestro control.

Read More

Posición de selectores para los nodos de la Red Profibus

SI-PFB-001

Han sido ya varias las ocasiones en las que en algunas plantas industriales me preguntan acerca de cuál es la posición correcta en los selectores de los conectores de los nodos en una Red Profibus.
Es por este motivo, que escribo este sencillo post.
Recordemos que la Red Profibus es una red de estándar internacional para conexión de equipos descentralizados a un PLC Maestro, red en la cual se transfiere información en forma bidireccional, ya sea del Maestro a los Esclavos, o de los Esclavos al Maestro.
Tenemos que la Red Profibus es una red lineal, donde hay un nodo inicial (por lo regular, aunque no siempre, es el Maestro) y un nodo final, nodos interconectados con un cable especial de dos hilos (generalmente de color morado) y conectores Profibus.
En los conectores Profibus cableamos la llegada de dos hilos (uno llamado "A" y el otro "B"), y si más adelante existe otro nodo, saldremos de este conector con otros dos hilos, de tal forma que creamos un puente para estos nodos intermedios.
Cada elemento de la red, Maestro y Esclavos, tienen asignada una dirección, la cual es única para cada nodo, e irrepetible. Es decir, no puede haber dos nodos con la misma dirección (digamos, el Número 2), ya que esto traería como consecuencia una falla en la red.
Es importante entender que el paso de la información en la red se realiza a través de estos dos hilos, pero el PLC Maestro (que podría ser, por ejemplo, una CPU 315-2DP) direcciona todos los nodos en la red, y si nota que uno o más nodos no existen, la red se irá a falla, falla indicada en color rojo en el led "BF" de la CPU.
Bueno, aterricemos en el punto central de este post, luego de estas consideraciones.
Ya que hemos cableado nuestra red y asignado direcciones únicas a cada nodo, es necesario colocar correctamente el selector del conector Profibus de cada uno de los nodos.
El conector Profibus tiene dos posiciones: "Off" y "On".
Esta es la nota importante: Unicamente el nodo inicial y el nodo final ha de ser puesto el selector del conector Profibus en "On", y los nodos intermedios en "Off".
Supongamos, por ejemplo, que tengo una red Profibus con un PLC Maestro y 4 módulos esclavos (esclavos "X1", "X2", "X3", "X4"), donde el PLC Maestro es el inicio de la red y un módulo "X4" es el nodo final. Entonces, para los conectores Profibus procedemos de la siguiente manera: El PLC Maestro y el módulo final "X4" tendrán sus selectores en "On", y todos los nodos intermedios lo llevarán en "Off".
Si por equivocación el selector del módulo esclavo "X2" lo ponemos en "On", lo que sucederá es que nuestra CPU marcará falla en la red al no encontrar los módulos "X3" y "X4", aunque físicamente allí estén, pues nadie los quitó ni están desenergizados, ya que cuando ponemos en "On" el selector de "X2", le decimos a red que éste es el nodo final, y que lo que haya a continuación no lo tome en cuenta, y eléctricamente, así sucede, pues con el selector en "On" cortamos la transmisión de corriente de la red a los conectores Profibus siguientes.
Así que, para reestablecer la red, simplemente volvemos a colocar nuestro selector en "Off" de nuestro conector del nodo "X2", y al hacer esto, eliminamos la falla en la CPU que indica falla en la red.
En post sucesivos analizaremos más fallas en la red Profibus.

Read More

RSLinx: Herramienta clave de comunicación de Allen-Bradley

AB-RX-002

RSLinx es una herramienta de comunicación escencial cuando nos queremos comunicar con equipos o redes de Allen-Bradley.
Cuando aquirimos un equipo, una CPU Micrologix 1200, por ejemplo, la primera pregunta que nos hacemos es cómo lo programaremos. Tenemos el cable de comunicación y el software de programación RSLogix 500. Pero para enlazarnos con la CPU con nuestra computadora, necesitamos una herramienta adicional. Esta herramienta es RSLinx.
Sin RSLinx, no podremos conectarnos a nuestro equipo.
Una vez que hemos instalado este software, sólo nos resta configurar el driver apropiado para establecer la comunicación con nuestra CPU, y, enseguida, podremos abrir nuestro editor de programas, como el RSLogix 500, y comenzamos a programar.
Suena bastante simple. Sin embargo, para establecer una comunicación con éxito, hemos de sortear varios puntos cruciales en RSLinx.
Empecemos por conocer este software que tiene una gran versatilidad.
Existen varias versiones de RSLinx, que entre las más conocidas están las versiones Lite y la Professional.
Sin embargo, existen varias versiones adicionales, seis en total, las cuales describiremos poco a poco en post sucesivos. Por el momento, sólo listamos estas versiones: Lite, Single Node, OEM, SDK, Professional, RSView y, por último, Gateway.
La versión Lite, como su nombre lo indica, es la versión más sencilla de RSLinx, y la versión Gateway es la más completa.
Cuál versión hemos de adquirir, dependerá de las necesidades que queramos cubrir. Si sólo queremos comunicarnos con una CPU cualquiera a través de un driver de RSLinx, bastará con obtener la versión Lite. Pero si necesitamos implementar la comunicación a través de una red Allen-Bradley para monitoreo de datos, por ejemplo, o si queremos utilizar la tecnología DDE, posiblemente requiramos la versión Professional o, para estar completamente armados, usaremos RSLinx Gateway.
Precisamente, RSLinx (excepto en las versiones Lite y RSView) ofrece otra poderosa herramienta de acceso a los datos de nuestros PLC, llamado OPC/DDE, con la cual podremos llevar datos directamente de nuestro PLC a una simple hoja de Excel, páginas web o aplicaciones Visual Basic.
Si, por ejemplo, queremos registrar en nuestra computadora la temperatura de uno de nuestros hornos que es controlado por un PLC Allen-Bradley, bastará con que nos conectemos (a través del cable de comunicación apropiado) con nuestra CPU, instalemos RSLinx (Professional, por ejemplo) en nuestra PC, configuremos el driver de comunicación para la CPU específica, y, creando una tag DDE/OPC, ésta la insertamos en nuestra hoja de Excel. Una vez aquí, podremos crear una macro en Visual Basic para que el registro se haga automáticamente cada cierto tiempo y se vaya almacenando línea a línea y en archivos que también de manera autónoma, se generen diariamente, semanalmente, mensualmente. Con esta información, podremos llevar un historial de la temperatura del horno para implementar modificaciones, ya sea para eficientar el proceso, eliminar alguna falla en el ciclo, presentar una base estadística para un producto, etc.
Para terminar este post, simplemente mencionar que ciertos softwares de visualización, utilizan RSLinx para poder comunicarse a los equipos de control.
Como podemos ver, RSLinx parecerá un accesorio que está de más en el repertorio de aplicaciones de Allen-Bradley, pero realmente se trata de una herramienta muy poderosa y versátil que, utilizándola apropiadamente, podemos explotarla para obtener información sumamente relevante de nuestros equipos y procesos, con lo que lograremos tener un mejor control de los mismos.

Read More

La importancia de respaldar CPU's y Paneles

TyC-001

Cuando se nos daña una CPU o un Panel, o simplemente se va la energía eléctrica y resulta que la batería de respaldo ya está agotada, como consecuencia ¡perdemos el programa!, y en qué lío nos metemos para arrancar nuevamente la máquina. Pueden pasar horas o hasta días o semanas para volver a operar normalmente nuestro equipo si no contamos con el programa de respaldo en algún lugar de nuestro archivero.

Por otro lado, a veces sucede que se nos borra el programa de la CPU o el Panel y tenemos el archivo de respaldo en algún CD, pero resulta que no es el más actualizado, y, aunque se lo cargamos al equipo, resulta que éste no trabaja completamente bien, algunos movimientos no los hace, etc., y resolver estos detalles nos llevan valioso tiempo de producción.

De ahí que es sumamente recomendable tener un respaldo de nuestros equipos en CD y en un lugar seguro y accesible, para el caso de que ocurra que se va el programa en una CPU, rápidamente podamos cargarle el respaldo correspondiente.

Si no hemos hecho respaldo de nuestras CPU's y Páneles, es un buen momento para empezar a hacerlo. De lo contrario, vivimos con una bomba de tiempo en nuestras máquinas hasta que ocurra que a algún equipo se le ocurra perder el programa, y tendremos que asumir las consecuencias de tener fuera de producción una máquina o quizá hasta una línea de producción, si este equipo al que se le perdió el programa es un equipo crítico, pilar en la producción.

No escribo esto para asustar a nadie, sino más bien para tomar acciones cuanto antes y realizar respaldos de todos los equipos. Asímismo, luego de haber respaldado todo, y tener estos archivos en lugar seguro, también es recomendable realizar respaldos periódicos de las máquinas (programar los respaldos por semana o por mes), claro, cuando a estos equipos se les hacen constantes o críticas modificaciones en los programas.

Finalmente, si no sabemos cómo realizar los respaldos, si no contamos con cables de comunicación ni con los softwares correspondientes a cada equipo, o simplemente, si andamos muy ocupados para hacerlos nosotros mismos, en este caso podemos contactar al fabricante del equipo, o quizá podamos contactar a alguna empresa dedicada a la automatización industrial en la zona, pues siempre hay alguna a la mano.

Consejo: No dejar los respaldos para después, ¡es necesario empezar a respaldar ya!

Read More