Most engineers have taken a programming course where they learned to write a program and then debug it. Debugging involves running the program, testing it for errors, and then fixing them. Even for an experienced programmer it is common to spend more time debugging than writing software. For PLCs this is not acceptable! If you are running the program and it is operating irrationally it will often damage hardware. Also, if the error is not obvious, you should go back and reexamine the program design. When a program is debugged by trial and error, there are probably errors remaining in the logic, and the program is very hard to trust. Remember, a bug in a PLC program might kill somebody.
After a system is in operation it will eventually fail. When a failure occurs it is important to be able to identify and solve problems quickly. The following list of steps will help track down errors in a PLC system.
1. Look at the process and see if it is in a normal state. i.e. no jammed actuators, broken parts, etc. If there are visible problems, fix them and restart the process.
2. Look at the PLC to see which error lights are on. Each PLC vendor will provide documents that indicate which problems correspond to the error lights. Common error lights are given below. If any off the warning lights are on, look for electrical supply problems to the PLC.
HALT - something has stopped the CPU
RUN - the PLC thinks it is OK (and probably is)
ERROR - a physical problem has occurred with the PLC
3. Check indicator lights on I/O cards, see if they match the system. i.e., look at sensors that are on/off, and actuators on/off, check to see that the lights on the PLC I/O cards agree. If any of the light disagree with the physical reality, then interface electronics/mechanics need inspection.
4. Consult the manuals, or use software if available. If no obvious problems exist the problem is not simple, and requires a technically skilled approach.
5. If all else fails call the vendor (or the contractor) for help.
Most PLCs will allow a user to force inputs and outputs. This means that they can be turned on, regardless of the physical inputs and program results. This can be convenient for debugging programs, and, it makes it easy to break and destroy things! When forces are used they can make the program perform erratically. They can also make outputs occur out of sequence. If there is a logic problem, then these don’t help a programmer identify these problems.
Many companies will require extensive paperwork and permissions before forces can be used. I don’t recommend forcing inputs or outputs, except in the most extreme circumstances.