“Engineer Wang, please come to the workshop! This new equipment has broken down again. Xiao Li has been troubleshooting for over half an hour, checked the program eight hundred times, but still can’t find the problem!”
The voice on the other end was Production Director Lao Zhang, nearly frantic. I put down my teacup and jogged over. The equipment was stopped, operators were gathered around, and Xiao Li, a programmer who had just graduated two years ago, stood in front of the electrical cabinet, his brow furrowed, clutching a laptop.
“Engineer Wang, look, all the logic seems fine!” He pointed at the ladder diagram on the screen, “This segment meets all the power conditions, but the output coil just won’t activate! It’s bizarre!”
I didn’t look at his computer first. I walked around the equipment, opened the electrical cabinet door, took a glance, then reached in and touched the output relay that Xiao Li had analyzed countless times in the program.
“Hmm, my hand feels a bit cold…” I muttered, then pulled the thumb-sized relay out with some force.
“Here, the problem is right here.” I handed the relay to Xiao Li, “The contacts are burned and stuck. You see it getting power in your program, but in reality, it has long since ‘exhausted itself and died’. Even if you sit in front of the computer until the end of your shift, it won’t move.”
Xiao Li’s face turned bright red.
This incident happened several years ago, but I often bring it up. Why? Because it vividly illustrates the topic we are discussing today: knowing PLC programming and understanding electrical maintenance are not the same in the eyes of your boss and experienced engineers.
1. Having a “hammer” doesn’t mean you should only see “nails”.
I have seen too many excellent programmers with clear logic, elegant code, and the ability to handle various complex algorithms and communication protocols. Once they sit in front of a computer, they are like generals strategizing in a command tent.
But the problem is, the battlefield is not just a sand table.
A PLC program is the brain, but the ultimate executors of the brain’s commands are those bulky “bodies” and “limbs”—contactors, relays, sensors, motors, valves… These things won’t discuss logic with you. They will only communicate in the most physical way: burned out, rusted, jammed, or loose.
Knowing PLC programming is a “software” skill; while electrical maintenance is an “art of hardware”.
The core task of a programmer is “to create” and “to optimize”: to make the equipment operate according to the intended logic, efficiently and stably.
The core task of a maintenance engineer is “to protect” and “to restore”: when the equipment does not operate according to logic, you must bring it back from “pathological” to “normal”.
One builds skyscrapers under clear skies, while the other patches leaks in skyscrapers during storms. Both are crucial, but their thought processes and skill sets are fundamentally different.
2. It’s not just about fixing electrical cabinets; it’s about interpreting the “language of the field”.
Most of the skills in electrical maintenance are outside the electrical cabinet.
Last summer, a piece of equipment kept reporting a “servo overload” fault for no apparent reason, but after resetting, it could run for half a day. Programmer Xiao Liu checked all the gain parameters, load curves, and even re-did the inertia identification, but the problem persisted.
He came to me, suggesting that the driver itself might have a hidden fault and requested a replacement. A new driver costs several thousand yuan, and I didn’t agree immediately.
I asked him to take me to the site. While the equipment was running, I did nothing but squat there and listen.
“Xiao Liu, do you hear that? Every twenty seconds or so, there’s a very faint ‘creak’ sound?”
He listened for a while and nodded.
“That sound is not right; it’s not a normal mechanical sound.” We followed the sound and eventually found that a support bearing at the end of the screw was slightly jammed. Normally, it was fine, but at a specific load point, the resistance suddenly increased, causing the servo motor to exert all its strength, leading to the overload!
Replacing it with a bearing that cost a few dozen yuan completely resolved the issue.
What I want to convey with this story is that a true electrical maintenance expert must be like an “old doctor”, focusing on “observation, listening, questioning, and palpation”.
Observation: Check the status of indicator lights, look for burnt wires, and check for mechanical misalignment.
Listening: Smell for burnt odors or ozone in the electrical cabinet.
Questioning: Ask operators about any abnormalities before the equipment failed and what operations were performed.
Palpation: Feel the temperature of the motor and check for abnormal vibrations.
These “field languages” are something cold code can never tell you. And this is precisely the key distinction between a “programmer” and an “engineer”.
3. The calculations in the boss’s mind: downtime and costs.
From the boss’s perspective, he doesn’t care whether you use ST language or ladder diagrams, nor does he care how sophisticated your algorithms are. What he cares about is: can the equipment consistently produce qualified products? Can it be repaired quickly when it breaks down?
The boss fears downtime even more than he fears you causing secondary downtime and cost waste.
A so-called “expert” who only knows programming is likely to be like Xiao Li at the beginning or Xiao Liu in the story (if I hadn’t gone). The most common mistake they make is: getting trapped in the perfect self-consistency of program logic while ignoring the complexity of the external physical world. The easiest judgment to make is: “The PLC is broken,” “The module is broken,” “The driver is broken”—these are all the most expensive solutions.
In contrast, an engineer who understands electrical maintenance will follow a troubleshooting path that goes from the outside in, from cheap to expensive, from mechanical to electrical.
1. First check the power supply: Is the voltage stable? Did the circuit breaker trip? This is the cheapest part.
2. Next check the actuators: Is the motor turning? Is the cylinder moving? Is the valve opening? These are intermediate links.
3. Then check the sensor feedback: Is the limit switch in position? Is there a signal from the sensor? Is there any looseness or misalignment?
4. Finally, check the PLC itself: Is the output point burned out? Or is there really a bug in the program?
This process is learned through countless lessons and tuition fees. It can solve problems at the lowest cost and in the shortest time. This is the core competitiveness that the boss is truly willing to pay you a high salary for—you are not a cost center, but a value guarantee.
4. Walking on two legs allows you to walk more steadily and further.
Having said all this, I am not belittling the importance of PLC programming. On the contrary, in today’s increasingly automated world, programming skills are the ceiling.
What I want to emphasize is: do not be a giant that walks on one leg.
If you are a young person learning PLC, do not just cling to computer simulation software. Go to the workshop, pick up your multimeter, tighten some screws, connect some wires, feel the powerful “click” when the contactor pulls in, and see the moment when the sensor light turns on and off. This is the real world that your program ultimately needs to control.
If you are a seasoned programmer feeling stuck, consider going back to school. Lower your stance and work with the experienced engineers to troubleshoot a few faults. You will find that your understanding of the program will deepen because you will know what each Q point and M point you write corresponds to in the real world, which sparks and moves.
Programming makes you powerful, while maintenance makes you reliable. When you can possess both the logical ability to “create a world” and the hands-on ability to “repair the world”, you become that irreplaceable person. At that point, it won’t be you looking for a job; it will be jobs looking for you. The way your boss looks at you is not as an employee, but as a “gold mine” that can ensure his production.
Finally, I leave a question for discussion: What amusing stories have you encountered due to only knowing programming without understanding maintenance, or only knowing maintenance without understanding programming? Share them so we can all have a laugh and learn some lessons together.