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
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.
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,