Mitsubishi PLC Modbus Failure: The Real Culprit Was a Battery Charger for 18650 Cells

When I first started in field service, a Modbus communication failure meant one thing to me: software. I'd sit for hours with my laptop plugged into whatever device was misbehaving, digging through IP settings, port assignments, and register tables. It took a Friday night emergency—and one very quiet Mitsubishi PLC—to teach me that sometimes the dumbest hardware is the smartest place to look first.

The Call at 3:47 PM

The phone rang at 3:47 PM on a rainy March afternoon in 2024. I was already mentally checked out for the weekend when the dispatcher transferred a call from a food packaging plant about 45 minutes away.

The plant manager didn't waste time with pleasantries. “The line's been down for over an hour. The Mitsubishi PLC is running—we can see the LEDs—but the HMI keeps showing Modbus TCP timeouts. The Intel control panel upstairs won't connect to it. We've got a $40,000 order that needs to run through the weekend.”

Night shift started at 7 PM. I did the math quickly: roughly three hours to find the fault, fix it, and have the line verified before shift change. If we missed that window, the plant would start the weekend on a stopped line, which basically meant losing the entire production slot. In my four years coordinating emergency service calls for industrial clients, I've handled over 200 rush situations. The pressure never really changes—you just get faster at moving through it.

I grabbed my multimeter, threw a few spare patch cables in the case, and headed out into the rain.

The Initial Misjudgment

My first guess was something in the network path. A switch flaked out, a cable that got clipped by a forklift, or a configuration glitch in the Intel control panel PC. Standard field call stuff.

When I got to the plant, the PLC itself looked completely healthy. Mitsubishi Q series, solid RUN light, nothing in the diagnostic LEDs, no alarm flags. In my experience, when a Mitsubishi PLC looks this healthy, it is healthy. The problem had to be somewhere else.

I started with the obvious checks:

• Ethernet cable from the PLC communication module to the switch: seated, no cuts
• Switch link lights: all green and blinking
• Control panel PC NIC: linked at 100 Mbps
• Ping from the panel PC to the PLC IP address: no response

Nothing looked wrong—which is exactly what made it suspicious.

The Turn

I've learned that the fastest way to narrow down an intermittent connection is to reboot the devices one at a time. I suggested restarting the Intel control panel while I watched the Mitsubishi PLC from my laptop.

It connected instantly. The HMI flooded with live values, and the plant tech's face lit up. “There it is—working again.”

Six minutes later, it dropped again. “Modbus TCP: Connection Timeout.”

That six-minute pattern cracked the case. Software issues don't work perfectly for six minutes and then quit. They fail, period. A connection that works and then dies, rhythmically, smells like a power delivery problem—something sagging, overheating, or struggling under load.

That's when I finally pulled out the multimeter. I should have done it much earlier.

How to Use a Multimeter to Test a Car Battery (and Why the Same Logic Applies to Control Panels)

If you've ever looked up how to use a multimeter to test a car battery, you already know the most important part: the measurement under load, not at rest. A battery can sit at 12.6V and look perfectly fine until you try to crank the engine. The load test tells the truth.

Industrial control panels are exactly the same. I measured the 24V power supply feeding the Intel control panel at rest: 24.1V, textbook. But when I asked the plant technician to cycle a washdown valve while I watched—the load brought it down to 21.6V for nearly two seconds. That's a serious sag, enough to make the panel PC's network card stutter and break the Modbus session with the Mitsubishi PLC.

The PLC wasn't the villain. It never had been.

Inside the control panel, I found the real suspect: a backup battery pack built from 18650 lithium cells, strapped to a DIN rail mount. It was meant to ride through these power dips. Instead, it was deepening them.

The Battery Charger for 18650 Cells Was the Quiet Culprit

Testing the pack was straightforward. Each cell group should have been near 3.7V. Three groups read about 3.2V, which is low but not catastrophic. The fourth read 1.8V—essentially dead.

A single weak cell in a series pack drags everything down with it. But here's what made it worse: the charger module on the rail next to it was a hobby-grade battery charger for 18650 cells, not an industrial one. It had no per-cell balancing, so it kept pumping current into the whole pack, overcharging the healthy cells while the dead one stayed dead. That's how a “backup” system becomes a liability—it doesn't just fail, it actively sabotages the bus it's supposed to support.

The most frustrating part: the plant had spent real money on this upgrade. New battery pack, new charger, even a little label that said “LINE CRITICAL POWER.” You'd think a backup system would fail loudly, but it failed quietly. No alarms, no status indicators—just a slow decline of a single 18650 cell, until the pack's voltage collapsed the first time the line drew real current.

The Rush Fix

By now it was 5:45 PM. The plant manager was pacing the floor, and the night shift foreman had started texting me question marks.

The correct repair was straightforward: replace the charger with a proper balancing unit and swap in fresh cells. I called a local electronics supplier we use, and they had one in stock—a real industrial module for $210 plus a $115 rush delivery fee. Standard delivery would have been next morning. The fee stung, but the alternative was a halted weekend line, and the client's own numbers put the cost of that at several thousand dollars in lost throughput plus a late penalty from their retail customer. Paying the rush fee was the obvious call.

We swapped the charger, installed fresh 18650 cells, and measured the panel PC power at 24.0V under load. The Modbus TCP connection to the Mitsubishi PLC came up clean—port 502 started responding immediately and stayed up. At 6:52 PM—I want to say 6:52, though I might be misremembering by a minute—the line restarted. Eight minutes before shift change. We made it.

What This Night Taught Me

That evening reshaped how I run every emergency call since. Some lessons that stuck:

• Bottom line: power before software. If a Mitsubishi PLC has healthy diagnostics and something else keeps losing the connection, load-test the power feeding that other device first. Voltage at rest is a lie.
• Intermittent Modbus failures traced back to the other end of the wire in every case I've chased. A communication module failure on a Q or FX series will typically show in the PLC's diagnostics. If the PLC is quiet, look at the other end of the connection.
• Batteries need load testing, not just a voltage read. Same principle as testing a car battery with a multimeter: check at rest, then under real draw. A sag beyond 10% means trouble.
• Hobby-grade chargers don't belong in critical control panels. If you have a battery charger for 18650 cells anywhere a failure would cost real money, make sure it balances individual cells. The $30 savings will cost you a production day eventually.

We now keep a proper balancing battery charger for 18650 cell packs in every service vehicle. It costs about $400, and it's already saved a client from what would have been a very bad Tuesday. That's the kind of efficiency that doesn't show up on a dashboard—until the line stops and someone needs an answer in the next ten minutes.

So, if you're staring at a Mitsubishi PLC Modbus timeout and the PLC looks innocent, it probably is. Check the control panel. Check the power. Check the battery. And when you grab the multimeter, remember to put a load on it.