I got the call at 2:17 p.m. on a Wednesday. A food packaging line was down, the operator said the Mitsubishi PLC was dead, and the maintenance manager had already ordered a replacement CPU. He wanted me to confirm the part number before he paid for expedited shipping.
It wasn't the CPU. The program was fine. The output card was fine. The problem was between the output terminal and a relay coil in the field. That call taught me something I still use almost every week: a Mitsubishi PLC program can be correct and still cause a machine failure, because the program is not the machine.
When a machine stops, the first thing everyone does is open the Mitsubishi PLC program and hunt for the rung that caused it. I've done it myself. I've spent an hour staring at a ladder diagram, convinced that a SET/RST issue or a hidden built-in contact was eating my signal. And sometimes it is. But more often, the program is doing exactly what it's supposed to do. The problem is that the program assumes the physical world will behave like an ideal electrical circuit.
Here's what took me too long to understand: a Mitsubishi PLC program is a list of rules about electrical states. It doesn't know if a wire is pinched under a cable tray. It doesn't know if a sensor's power supply is sitting at 10.8 V instead of 24 V. It doesn't know if the relay coil on the other end of an output is old, leaking current, or wired to the wrong common. The program only sees one thing: whether the input terminal sees a voltage state its circuit interprets as ON or OFF. So when someone asks 'why doesn't my Mitsubishi PLC program work?' the real question is usually 'why isn't the field device on the other end of the wire doing what the program assumes it will do?'
Inputs are electrical, not logical. A PLC input doesn't read a sensor's true or false value. It reads a current path. If you wire a 3-wire DC sensor to an input card, the sensor has to sink or source enough current to pull the input circuit. If the common wire is broken, or if the sensor is wired for the opposite type, the input LED might still glow faintly. The program sees a flicker or, worse, a clean 1 that isn't actually reliable.
I remember a job where the customer's Mitsubishi PLC program had a door open input that randomly cycled. Everyone blamed a faulty module. The actual cause was a sensor with a leaky transistor and a floating common. The program was right. The wiring was almost right. The electrical state was wrong.
This is where the car battery lesson comes in. If you've ever wondered how to use a multimeter to test a car battery, here's the short version: a static voltage reading of 12.6 V doesn't mean the battery can start the engine. You need a load test to see if the battery can deliver current. PLC inputs are the same. Measuring 24 V between a signal wire and ground doesn't prove the input will work, because the input needs a current path between the signal wire and the input card's common. If you test between the wrong points, you get a voltage that looks right and a machine that still won't run.
I've started teaching our technicians to check PLC inputs the way you'd check a car battery: first verify the source, then verify the path under load, and don't trust a floating voltage.
A specific example: we had a skid that was supposed to start an electric start propane generator when a tank level hit a setpoint. The Mitsubishi PLC program showed the output was ON. The output LED was ON. But the generator never cranked. The maintenance person tested the wire with a multimeter and saw 24 V at the control terminal. 'The PLC is sending the signal,' he said. What he didn't check was whether that 24 V could actually carry current through the relay coil. The relay was a DC coil with a nasty surge characteristic, and the PLC output had been configured for a different output type. The program was perfect. The output card would have been fine for some loads. It just wasn't the right card for that load.
Think about a dishwasher control panel. It has a little microcontroller that runs a wash cycle step by step, exactly like a PLC program. If the door latch switch is dirty, the panel lights flash and the cycle won't start. The control panel is working. The program is correct. The switch is the problem. A Mitsubishi PLC program is the same: it's only as good as the signals it receives and the loads it drives.
That food plant call cost more than a repair. The customer had already ordered a replacement CPU from a supplier that was not an authorized Mitsubishi PLC USA distributor. The part was non-refundable, $1,800, and they had to pay for expedited shipping because the line was down. Total downtime was 11 hours. The actual issue was a $12 relay and a 30-minute wiring correction.
The logic was never the problem. But because everyone was focused on the Mitsubishi PLC program and not the circuit, they went straight to buying parts. The numbers said replace the CPU. My gut said not yet. That hesitation wasn't magic; it was based on one question the operator answered differently the second time: the relay clicked, but the generator didn't crank. That told me the CPU was sending a signal. The signal just wasn't doing anything useful.
This is where the value-over-price lesson becomes real. In my experience managing service orders for eight years, the lowest quote has cost us more in about 60% of cases. Not because the parts are always bad, but because a cheap part or a cheap diagnosis focuses on replacing hardware instead of understanding the system. The $1,800 CPU didn't cost $1,800. It cost $1,800 plus 11 hours of downtime plus the trust of the production manager.
(Mental note: I should have asked the operator what the last person did before I ordered anything. That one sentence would have saved everyone a really bad afternoon.)
If I could redo every one of the 11 significant mistakes I've made and documented in the past eight years (they total roughly $26,000 in wasted budget and delay), I would do one thing differently: I would measure the actual electrical condition at the PLC terminal before I opened the program. Now I maintain our team's checklist so the next person doesn't repeat my version.
Here's the short checklist I now use on every Mitsubishi PLC troubleshooting call, even when I'm in a hurry:
Then, and only then, open the Mitsubishi PLC program. If the inputs are correct, the outputs are correct, and the wiring between the terminals and the field devices is correct, the program is usually not the villain.
Looking back, I should have started with a voltage-drop test under load. At the time, it seemed faster to open the program. It wasn't. The program doesn't know what the wiring did. You have to ask the wiring.
One last thing: my experience is based on about 150 service calls with FX and Q series Mitsubishi PLCs, mostly in food plants and custom skids. If you're working with a safety-rated R series system or a high-speed motion application, your experience might be different. And this was all true as of early 2025. Hardware revisions change, so verify current specifications with your distributor before you order. But the core lesson doesn't change: measure the circuit before you blame the Mitsubishi PLC program.