At this post i will give some basic instructions which are from my personal experience in order to give you a guide for how troubleshooting in automation systems (PLC/DCS) is.
Automation systems troubleshooting has in general the same tactic in order to find the solution of system’s fault. Nevertheless, depends the complexity and the size of application and the specific automation system, the troubleshooting steps would be a little different or more complicated. The best knowledge is obtained through practise and actual troubleshooting conditions. Practice again and again is the solution in my opinion. Any supplement and comments are welcome!!
Before we proceed, we agree that modern automation systems have PLCs for controlling the application. If we have a small application then the system possibly has a microPLC (or nanoPLC) or another type of compact controller (many times this depends of the application). I said modern automation systems because in the past (before PLCs/other compact controllers be well known and used by automation development companies), the control of an automation system was going on only with relays.
Investigate controller’s programme
The first thing we should do, is to find out if we have the right conditions fulfilled for the operation that is faulty. To do this we should find the “mind” of our system. This “mind” is the controller (either this is a kind of PLC or another type of compact controller). If we don’t have the right conditions fulfilled, then we should investigate the controller’s programme for finding out the origin of the problem (ALWAYS check messages appear at SCADA. This will guide faster to the solution because at SCADA appear important information such as fault/alarm description or a specific address in PLC).
The thing that we will find out is…
either a faulty signal from hardware (eg a digital signal from a button or a digital signal from a mechanical switch or a digital signal from a relay’s contact that “does not come” to controller’s input or an analog signal which has wrong values) or a faulty signal from another software system (eg SCADA).
Investigate the conditions came from hardware
When we conclude for the origin of the problem, then we leave for a while controller’s programme and go out to check our conclusions. We should already have find the drawings of automation system in order to see the connections for the components we want to check.
For example, if we find out that we have a digital signal from a button which “does not come” to controller’s input, then we take our multimeter and go to check the button.
If the button is OK, then we investigate if there is any fuse between button and controller’s input. If there is, then we check it.
If the fuse is OK, then we investigate the route of the cable. Maybe we have a cut cable.
If the cable is OK, then maybe we have hardware problem to the controller’s input and maybe we should change this input module with a new one or otherwise fix it (the repairs should be done by qualified staff).
Investigate the hardware after the outputs of our controller
If we conclude that we have the right conditions, then we should check the components that we have between controller and the faulty equipment (we mean the equipment that doesn’t work as it should).
For example, if we have an industrial furnace that does not close its door (even though we have the conditions for closing the door from programme), maybe we have a faulty relay that energizes from PLC (or other controller) for closing the door.
If the relay is OK, then maybe we have problem with the motor that is responsible for closing the door. We should check motor for its status (motor coils, mechanical parts)
If the motor is OK, we should check the voltage values come to motor’s input (with our multimeter) and also check the cable for its status if multimeter’s measurements are not right.
If the voltage and cable are OK, then maybe we have a jam somewhere at the door-furnace construction.
Power units are a “plus”!
Generally, when we have power units (drives) in our automation system in order to drive a motor, then we should have together the manual of the specific power unit. That’s because power units have a digital display or 7-segment led displays or simple leds for informing us about the fault that exists inside them or at the driven motor. This is very useful for engineers and technicians. Also, modern power units have special algorithms for checking motor status, voltage and current values etc.
For example, if a motor is overheated, the drive will inform us about it because it checks continuously the temperature sensor (eg thermistor) which is located inside motor’s enclosure.
Then we should check the motor if it is overheated actually or we have a faulty temperature sensor that we should replace it.
Check controllers status
Some times, when the CPU of our PLC detects an unacceptable condition at the programme’s flow, then it goes to “STOP” mode and possibly a led flashes and indicates this malfunction. Also, if any other malfunction is going on to the system, some led’s indicate the kind of fault (refer to controller’s manual for more information). Same behavior have in general any kind of controller is established in an automation system.
Many automation systems (often production machines) have in their design some “safety systems” like “Pilz” or “Siemens Sirius”. These are smart compact controllers for monitoring situations like protective door opening or Emergency-Stop. When something of these occurs, the safety system stops the operation of the automation system for human and machine protection. In order to reset the automation system to the functional state, there are special instructions in safety systems manuals.
The conclusion for all the above is to have a step by step tactic in troubleshooting. Passing time and getting more experience, maybe we will bypass some steps, specifically if we are the staff responsible for the maintenance of a system which we come across every day. However a good tactic is to be organised and patient. Good luck to your efforts!