Dear Colleagues,
Some years back, I was engaged in the automation of a mushroom farm (no – we weren’t manufacturing crack or magic mushroom potions). When I joined, the engineering team had already implemented an embedded controller system with the electronics systems designed from scratch. Surely lots of fun for the engineers and technicians who put this system together at a huge expense in terms of hours (although very cheap from a hardware point of view). But a veritable nightmare to design and then to troubleshoot, although probably extraordinarily efficient in terms of size of code on the microcontrollers.
But they could have cut the costs down dramatically by implementing a PLC (programmable logic controller) system. Perhaps, the PLC code isn’t as efficient and it is perhaps somewhat more clunky than something written in C++. But extraordinarily quick to configure and have up and running.
The PLC is surely one of the workhorses in industry – no matter whether you are in industrial automation, electrical or mechanical engineering, you are likely to be confronted with one of these little fellas - a Programmable Logic Controller or PLC (or indeed, Programmable Automation Controller – PAC), a critical cheap building block for all automated systems.
A few tips on troubleshooting these devices
The first decision is to decide whether the problem is internal or external to the PLC. Over 80% of PLC malfunctions are with the I/O modules and field equipment (OK; I agree – where did this statistic come from – but it does make sense). Problems related to a specific I/O module or input/output device are generally external problems while large groups of failures are generally related to the internals of the PLC.
Internal problems - first cab off the rank
- Check that your earthing/grounding is correct. Inspect power and ground wiring. Check that voltage between PLC ground terminal and known ground is actually zero. You may need to log this over time with a scope to find pesky transient (intermittent) changes in voltage.
- Check the power supply to the PLC is operating within the correct ranges for both CPU and I/O modules (and that the ac ripple on your dc supplies is not excessive).
- Check the batteries on the PLC are still OK.
- EMC/EMI problems get more tricky – look for an EMC/EMI “event” such as motor starting/arc welding in the area or lightning strike which may match up with erratic behaviour of your PLC.
- Check the PLC program hasn’t been corrupted (occasionally on cheaper devices I have seen this happen much to my amazement). Ensure the program is backed up off-site when examining it.
- Check the internal diagnostics for a crash of one of your PLC programs or subroutines or some other error (e.g. divide by zero)
External problems – the more likely problem
The main issue here is to find out why your internal program and data status doesn’t match up with the external situation.
Digital inputs
- Check the power supply to the module.
- Look for where the power to a digital input comes from (not normally from the PLC I/O module).
- Check fuses, breakers and any other cause of power interruption to the digital input.
- Check for adequate changes in voltage to the digital input when the external field device is operated.
- If the digital input is operating correctly and the CPU is still misreading it; the problem may lie in the PLC program.
Digital Outputs
- For digital outputs, check where the power is being supplied by. Often not from the PLC output card itself.
- Check the power output from the PLC.
- Check fuses (and fuse blown indicators).
- Force digital outputs on and off.
- Preferably use a test load (rather than open circuit it) when testing the PLC outputs.
Analog Inputs
- For analog inputs; move the field device (an instrument) through the full range of current (e.g. 4-20mA) and confirm this is reflected in the equivalent register in the PLC.
- If there is uncertainty here, hook up a signal transmitter and run through the full range of current (or voltage).
Analog Outputs
- For Analog outputs – in your PLC program force the output to a specific value and observe that the output reflects this. If not; check the external wiring and then the actual output, with a 250 ohm resistor for example.
The hazards of remote troubleshooting
Some of my recent forays increasingly have been into remote troubleshooting of PLCs located thousands of kms away. But this can be a hazardous occupation without enormous care taken with network security to ensure that some one located in Siberia or West Waziristan doesn't hack into your critical industrial control system.
A few thorny transient problems
In my experience in troubleshooting, I have been occasionally exposed to sudden over-voltages which blew a range of variable speed drives and PLC inputs (due to discharge of a capacitor bank with a very sharp transient). Other ones have been horrible harmonics introduced by a new drive. This required isolation of analog inputs to eliminate this (as we then had aliasing problems). Finally, data communications problems traced to common mode voltages surges and fixable by isolation (fiber optics) and improved earthing.
When in doubt; disconnect
And when testing a PLC, ensure that you disconnect any critical high powered equipment when testing outputs. One PLC programmer I know, accidentally started a 1MW ball mill accidentally when testing a tiny digital output from the PLC…...
Particularly true of troubleshooting PLCs is Oscar Wilde's comment: Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught.
The only way to learn is by your own efforts in troubleshooting.
Thanks to Ryan G. Rosandich for a great article on Troubleshooting PLCs.
Yours in engineering learning,
Steve
