Troubleshooting PLCs

sivaranjith · May 21, 2018, 4:06pm

In the case of a PLC failure, you must use a careful and systematic approach to solve the system problem.

PLCs are relatively easy to solve because the control program can be displayed on a monitor and can be viewed in real time while running. If a control system has been running, you can be fairly sure of the accuracy of the program’s logic. For a system that has never worked or is only being commissioned, programming errors should be considered.

The first step to solving problems is to identify the problem and its origin. The origin of a problem can usually be reduced to the processor module, I / O hardware, wiring, inputs or outputs of the machine or the ladder logic program.

The following sections deal with troubleshooting in different problem areas:

Processor Module:

The processor is responsible for the self-detection of potential problems. It performs error checks during its operation and sends status information to indicators that are normally located on the front of the processor module.

One can diagnose faults in the processor obtain more detailed information about the processor by accessing the processor status through the programming software. LEDs in the processor light up indicating the diagnostic result:

GREEN light, RUN: Run, On steady indicates that the process is in the RUN mode, Flashing during operation indicates that the process is transferring a program from RAM to the memory module.

RED light, FLT: Fault indication, Flashing at power-up indicates that the processor has not been configured. Flashing during operation indicates a major error either in the processor, chassis, or memory, On steady indicates that a fatal error is present.

RED, BATT: On steady indicates that the battery voltage has dropped below a threshold level, or that the battery is missing or not connected.

The processor continuously monitors the program that might cause a fault. The processor continuously monitors the program that could cause a failure. If the fault relays are installed to control the processor, they are activated when there is a fault.

Most PLCs incorporate a surveillance timer to monitor the system’s scanning process. The watchdog timer is usually a separate timing circuit that the processor must establish and reset within a predetermined period.

Input Malfunctions:

If the controller is operating in the RUN mode but output devices do not operate as programmed, the faults could be associated with any of the following:

Input and output wiring between field devices and modules
Field device or module power supplies
Input sensing devices
Output actuators
PLC I/O modules
PLC processor

Narrowing down the problem source can usually be accomplished by comparing the actual status of the suspect I/O with controller status indicators. Usually, each input or output device has at least two status indicators. One of these indicators is on the I/O module; the other indicator is provided by the programming device monitor.

A circuit check for the input malfunction, malfunction checking procedure is shown below:

When you suspect that the input hardware is the source of a problem, the first check is to see if the status indicator on the input module lights up when it is receiving power from its corresponding input device (for example, push button, switch of limit).
If the status indicator on the input module does not illuminate when the input device is on, take a voltage measurement across the input terminal to check for the proper voltage level.
If the voltage level is correct, then the input module should be replaced.
If the voltage level is not correct, power supply, wiring, or input device may be faulty.

If the programming device monitor does not show the correct status indication for a conditional instruction, the input module may not be converting the input signal properly to the logic level voltage required by the processor module. In this case, the input module should be replaced. If a replacement module does not eliminate the problem and wiring is assumed to be correct, then the I/O rack, communication cable, or processor should be suspected.

Input troubleshooting guide:

Output Malfunctions:

In addition to the logic indicator, some output modules incorporate a blown fuse indicator or a power indicator or both. A blown fuse indicator indicates the status of the protection fuse in the output circuit, while a power indicator shows that power is being applied to the load.

Electronic protection is shown in the figure below, is also used to provide protection for the modules from shortcircuiting and overload current conditions. the following items should be noted when troubleshooting discrete output modules:

otrouble

If the blown fuse indicator is not illuminated (fuse OK), then check to see if the output device is responding to the LED status indicator.
An output module’s logic status indicator functions similarly to an input module’s status indicator. When it is on, the status LED indicates that the module’s logic circuitry has recognized a command from the processor to turn on.
If an output rung is energized, the module status indicator is on, and the output device is not responding, then the wiring to the output device or the output device itself should be suspected.
If, according to the programming device monitor, an output device is commanded to turn on but the status indicator is off, then the output module or processors may be at fault.
Check voltage at output; if incorrect, power supply, wiring, or output device may be faulty.

Ladder Logic Program:

Many PLC strong text software programs offer various software checks used to verify program logic. There are verifying program errors using RSLogix 500 software. Selecting edit then verify project will check the program for errors. The sample shows what the error message might look like.

A hardware fault in the memory IC that holds the ladder logic program could alter the program, but this is a PLC hardware failure. If all other possible sources of trouble have been eliminated, the ladder logic program should be reloaded into the PLC from the master copy of the program. Make sure the master copy of the program is up to date before you download it to the PLC.

Certain diagnostic instructions can be included as part of a set of PLC instructions for troubleshooting. The Temporary End Instruction (TND) is used when you want to change the amount of scanned logic to progressively debug your program. There are two types of diagnostic instructions, temporary end (TND) and suspend (SUS) instruction. The operation of this output instruction can be summarized as follows:

TND func:

The instruction operates only when its rung conditions are true and stops the processor from scanning any logic beyond the TND instruction.
When the processor encounters a true TND rung, it resets the watchdog timer (to 0), performs an I/O update, and begins running the ladder program at the first instruction in the main program.
If the TND rung is false, the processor continues the scan until the next TND instruction or the END statement.
By inserting the TND instruction at different locations in the program you can test parts of the program sequentially until the entire program has been tested.
Once the troubleshooting process has been completed, any remaining TND instructions are removed from the program.

SUS Instruction:

The suspend (SUS) instruction, is used to trap and identify specific conditions for program debugging and system troubleshooting. Troubleshooting instructions operation:

When the rung is true, this instruction places the controller in the suspend or idle mode.
The suspend ID, in this case, 100, must be selected by the programmer and entered in the instruction.
When the SUS instruction executes, the ID number 100 is written in word 7 (S:7) of the status file.
If multiple suspend instructions are present, then this will indicate which SUS instruction was active.
The suspend file (program or subroutine number identifying where the executed SUS instruction resides) is placed in word 8 (S:8) of the status file.
All ladder logic outputs are de-energized, but other status files have the data present when the suspend instruction was executed.