A PLC-controlled system stops for no apparent reason, causing excess scrap, production delays, and quality problems. The final control elements in the PLC loops include seven valves, two heating elements, and four motors. All have been checked for proper operation. The valves have even been stroked (at 20%, 50%, 80%, fully closed, and fully open) using a loop simulator at the input to the PLC module that accepts the process sensor inputs for the valves.
The process sensor loops have all been loop-checked using simulators for the various sensors. Half of the sensors have been bench-calibrated, the rest have been field-checked. All have passed their testing.
The first rule in troubleshooting a PLC system is to check the final control elements, and the second is to check the inputs. The third rule is the logic doesn’t “go bad.” So, what do you do next?
Answer to quiz. So far, the troubleshooting has been done as it should have been done. But it’s not complete. Just because the control logic doesn’t “go bad” doesn’t mean you shouldn’t look at it. Looking at the control logic is the next logical step in this troubleshooting process.
What you need to do is walk through the logic diagram(s) and identify every permissive and interlock. A permissive is a condition that must be present for an action to commence. For example, a mixing motor won’t start unless the low-level switch indicates at least a minimum level in the vessel. An interlock is a condition that must be present for an action to continue (it usually must also be present for an action to start). For example, a mixing motor will stop if the low-low level switch indicates the level is insufficient for running the mixer.
Permissives are likely not the problem here because the problem isn’t that the system won’t start but that it won’t keep running. However, a permissive not satisfied at one stage could create an interlock in a later stage by (for example) not opening a particular coil and the results is the logic shuts down the system. So to avoid chasing your tail, proceed methodically. Start with the permissives.
First, interview the operators to determine at what process step the process is stopping. Armed with this information, you can then determine from the PLC logic what permissive(s) must be “on” for that step to initiate. For example, you see that Coil 2 must pick up before Motor 2 can start. If Motor 2 is needed at Step 23 of the process but can’t start, then the process will stop at Step 23. Check each permissive one at a time to see what the condition is and if the system is actually seeing that permissive as “on.” If all of the relevant permissives check out, then look at the interlocks using a similar process.
Another possibility is bad wiring connections to (and from) the PLC system. These are typically caused by improper crimping on the signal or power conductor connectors. A gentle tug on each one should reveal a problem if it exists. Also use a torquing screwdriver to test for loose terminal screws.
Another possibility is a bad PLC module. First check the power lights. Solve any issue you find there. Then simulate the inputs as needed to execute the control logic and ensure it executes properly through the PLC. If it is not possible to do this in situ, you’ll have to install a replacement temporarily and bench test each module.
If you still have not found the problem at this point, look at the sensor connections, wiring, placement and (if applicable) sensor reference. For example, a temperature sensor provides input that is too latent because the sensor is too far from the heat source or the input is too early because the temperature is too close to the heat source. If you’ve ever tried to fill a bowl with hot water to (for example) soak your hand in Epsom salts (a common first step in addressing a finger infection), you know how this works. In a system with level sensors on multiple vessels, the control strategy is often based on variance between vessels. But if they are referenced to the floor grating instead of to the centerline of each vessel, you already have an offset that will cause excess sensitivity in the system.
Sensor placement issues need to be presented, with drawings or sketches, to the responsible systems engineer for resolution. That same engineer needs to be apprised of another issue, and that is apparent deficiencies in the control logic. Is a particular permissive or interlock the correct one? Or is it needed at all? Answers to these questions must be provided by the systems engineer, and only after due consideration of all the data. Don’t push for a particular resolution, because you probably don’t have all the information needed. If you’ve gotten to this point in the troubleshooting, it’s almost certain the equipment is functioning as it was designed to and the design itself is the problem.
