Years ago, I was in the middle of a normal day of work when I got a call on the radio that a conveyor had stopped, and then I was informed that the entire process around that conveyor had shut down as well.
When I went online with the respective processor for that system, I was at first surprised to see the processor was “Faulted”, you know, that bright red light on the processor status of RSLogix or Studio 5000 that says “I’m Done!”.
When I investigated to learn why the fault had occurred, the error led me to a mistake that I had made weeks earlier that came to fruition on that day.
You see, I had written a calculation that, based on the conveyor speed, would place an EPID controller in auto at precisely the correct time.
I wrote that calculation to a timer preset value not realizing what could happen. When the conveyor stopped, the speed reference (that was part of the calculation) submitted a value to the control system slightly less than zero and that was all it took to make the timer preset negative and fault the controller.
As a young programmer, that day I learned a valuable lesson that I would not forget, that is to evaluate both, the positive and the negative impact of everything that I place in code.
The checks and balances, so to speak, are very important in what we do.
Over the years, I have seen numerous other faults as well. I have witnessed faults caused by indirect addressing and other ways of causing an out of bounds reference to an array.
Being careful with the FFL (FIFO Load) and FFU (FIFU Unload) is a learned experience as well.
I once was called to a machine that was shut down not long after installation with a processor that was faulted. Once online, I began looking at the code (code was written by someone else) to understand the fault.
It was an array overflow, and what caused the processor fault came from a faulty limit switch.
The program was counting panels as the went into the machine, and counting them down as they exited the machine,all while filling an array with panel data.
When the limit switch on the outfeed of the machine stopped functioning, it caused the array to overfill and the processor came to a stop.
After making a change to repair the code, it was yet another lesson learned in the journey of a young programmer.
In this below example, I had the FFL instruction reference an array with only DINT data type. There is no way to reference a length of 17.
I could go on and on with other stories and experiences, but the bottom line is, if you are not familiar with the do’s and don’ts of coding in a ControlLogix processor, then it would be a good idea to check out the Rockwell publication 1756-pm014_-en-p.pdf to understand some of the many ways that can “anger” a processor and cause it to say “I’m Done!”
Online forums and blogs like this one are another way of learning from other peoples’ adventures and mistakes.
Clearing your fault after it occurs
After learning about a fault and correcting the mistake in the code, you can select “Clear Faults” as shown below.
The controller will switch from “Faulted” to “Program Mode,” after which you can place the controller back into the “Run Mode.”
Referenced Publication: Logix 5000 Controllers Major, Minor, and I/O Faults
There is no doubt each one of you who maintain automated systems have had similar experiences on your own journey as a control system engineer.
The key to me is to learn from our mistakes, and be better than we were before each experience.
After each of the above events, I became a better programmer by learning the value of inserting the checks and balances needed so my code stays within the necessary bounds of operation.
A good programmer friend of mine always says “I can play by the rules if I know what they are”. So I’ll leave that thought with you and my best to you as we all improve something every day.
Written by Brandon Cooper
Senior Controls Engineer and Freelance Writer