Hace años, estaba en medio de un día normal de trabajo cuando recibí una llamada en la radio que un transportador se había detenido, y luego me informaron que todo el proceso alrededor de ese transportador también se había apagado.
Cuando entré en línea con el procesador respectivo para ese sistema, al principio me sorprendió ver que el procesador estaba "Fallido", ya sabes, esa luz roja brillante en el estado del procesador de RSLogix o Studio 5000 que dice "¡Ya terminé!" ".
Cuando investigué para saber por qué había ocurrido la falla, el error me llevó a un error que cometí semanas antes y que se hizo realidad ese día.
Verá, había escrito un cálculo que, basado en la velocidad del transportador, colocaría un controlador EPID en automático exactamente en el momento correcto.
Escribí ese cálculo a un valor predeterminado del temporizador sin darme cuenta de lo que podría pasar. Cuando el transportador se detuvo, la referencia de velocidad (que era parte del cálculo) envió un valor al sistema de control ligeramente inferior a cero y eso fue todo lo que se necesitó para que el temporizador se preajuste en negativo y fallara el controlador.
Como joven programador, ese día aprendí una valiosa lección que no olvidaría, que es evaluar tanto el impacto positivo como el negativo de todo lo que coloco en el código.
Los controles y equilibrios, por así decirlo, son muy importantes en lo que hacemos.
Con los años, también he visto muchas otras fallas. He sido testigo de fallas causadas por direccionamiento indirecto y otras formas de causar una referencia fuera de los límites a una matriz.
Tener cuidado con el FFL (FIFO Load) y el FFU (FIFU Unload) también es una experiencia aprendida.
Una vez me llamaron a una máquina que se apagó poco después de la instalación con un procesador que falló. Una vez en línea, comencé a mirar el código (el código fue escrito por otra persona) para entender la falla.
Fue un desbordamiento de matriz, y lo que causó la falla del procesador provino de un interruptor de límite defectuoso.
El programa contaba los paneles a medida que entraban en la máquina, y los contaba a medida que salían de la máquina, todo mientras llenaba una matriz con datos del panel.
Cuando el interruptor de límite en la salida de la máquina dejó de funcionar, hizo que la matriz se llenara en exceso y el procesador se detuvo.
Después de hacer un cambio para reparar el código, fue otra lección aprendida en el viaje de un joven programador.
En el siguiente ejemplo, la instrucción FFL hacía referencia a una matriz con solo el tipo de datos DINT [16]. No hay forma de hacer referencia a una longitud de 17.
Podría seguir y seguir con otras historias y experiencias, pero la conclusión es que, si no está familiarizado con lo que se debe y no se debe hacer en un procesador ControlLogix, sería una buena idea consultar la publicación de Rockwell 1756-pm014_-en-p.pdf para comprender algunas de las muchas formas en que puede "enojar" a un procesador y hacer que diga "¡Ya terminé!"
Los foros y blogs en línea como este son otra forma de aprender de las aventuras y errores de otras personas.
Después de enterarse de una falla y corregir el error en el código, puede seleccionar "Borrar fallas" como se muestra a continuación.
El controlador cambiará de "Faulted" a "Program Mode", después de lo cual puede volver a colocar el controlador en "Run Mode".
No hay duda de que cada uno de ustedes que mantiene sistemas automatizados ha tenido experiencias similares en su propio viaje como ingeniero de sistemas de control.
La clave para mí es aprender de nuestros errores y ser mejores de lo que éramos antes de cada experiencia.
Después de cada uno de los eventos anteriores, me convertí en un mejor programador al aprender el valor de insertar los controles y equilibrios necesarios para que mi código permanezca dentro de los límites de operación necesarios.
Un buen programador amigo mío siempre dice "Puedo seguir las reglas si sé cuáles son". Así que dejaré ese pensamiento contigo y lo mejor para ti, ya que todos mejoramos algo todos los días.