“But the datasheet says it’s faster” — Why Mitsubishi Electric’s PLC Efficiency Is the One You Can Actually Keep (and Omron’s Isn’t)

You didn’t buy a PLC for its nameplate speed. You bought it to close a valve, fire a cylinder, or move a servo before the part arrives. And yet, most comparisons stop at “34 ns instruction time vs 55 ns” and call it a day. That’s not engineering — that’s datasheet theatre.

I’ve spent 20 years inside cabinets where the real test isn’t the cycle time on a clean bench, but what happens when your 24 V bus sags, the EtherCAT frame gets a collision, or your motion planner throws a curveball at the scan. This is the eligibility gate: the threshold below which a PLC’s paper efficiency becomes useless because the system can’t keep it.

Let’s walk through the three dimensions where Mitsubishi Electric’s MELSEC iQ‑F FX5U and Omron PLC’s Sysmac NX1P2 diverge — not on paper, but inside the loop.

1. The 34 ns Basic Instruction — and Why 80 % of Programs Never Touch It

The FX5U executes a basic instruction in roughly 34 ns. Omron’s NX1P2 primary task can cycle at about 4 ms, but its per‑instruction timing is not officially published below the µs range. If you’re writing a tight logic loop with 10,000 contacts, the FX5U chews through it in 0.34 ms; the NX1P2 would take roughly 1–2 ms for the same (assuming ~100–200 ns per bit, which is a rough estimate based on typical Cortex‑M4 performance). So far, Mitsubishi PLC wins — on the bench.

But here’s the mechanism that kills that advantage: PLCs don’t run “just” logic. Every time you add a motion axis, an analog read, or a PID block, the scan time inflates because those operations are tied to the task cycle. The NX1P2’s primary task can be as low as 2 ms in its fastest configuration, but that’s an ideal number with zero I/O update. Add 8 axes of EtherCAT motion (which the NX1P2 supports up to 8 axes) and the task cycle jumps to 4–6 ms. The FX5U, by contrast, offloads positioning to dedicated high‑speed counters and built‑in pulse trains, meaning the logic scan doesn’t carry that overhead. In a typical 500‑step sorting machine with two axes, the Mitsubishi’s effective scan stays under 1 ms; the Omron’s can drift to 3–5 ms.

The worked consequence: That 0.34 ms logic gap you thought you had? It’s swallowed by a 3 ms motion penalty. The machine that could have done 120 cycles per minute (500 ms cycle) now does 85 — a 30 % loss you never saw in the datasheet.

When this reverses: If your application is pure logic — no motion, no analog, just 24 V sensors and relays — then the Omron’s primary task at 2 ms is consistent and deterministic. The FX5U’s 34 ns advantage becomes irrelevant because both finish before the I/O field even updates. In this narrow niche, the NX1P2’s tighter jitter (thanks to EtherCAT’s distributed clocks) can actually produce a more repeatable cycle.

2. The “Built‑in” Trap: How Many Wires You Really Need vs How Many You Get

Both CPUs come with integrated I/O: the FX5U offers 32, 64, or 96 points on the base unit (depending on model); the NX1P2‑9024DT gives you 24 (14 DI / 10 DO). The Omron can be expanded with up to 8 NX I/O units — but every expansion hop adds ~50–100 µs of bus latency. The FX5U’s CC‑Link remote I/O adds similar delay, but the key difference is how many points you need before you hit the expansion bus.

For a standard packaging machine with 48 sensors and 24 actuators: the FX5U handles it on the CPU with zero expansion latency. The NX1P2 starts at 24, so you need at least two expansion blocks — each adds roughly 80 µs per cycle. That might not sound like much, but at 100 cycles/min (600 ms per cycle), 160 µs is a 0.03 % hit — negligible. However, the real killer is when you mix fast inputs (e.g., high‑speed counter, 50 kHz) with expansion modules. The Omron’s expansion bus runs on the same backplane as the motion network; a heavy EtherCAT frame can delay the I/O update by one full task cycle.

Worked consequence: A rotary knife that needs a 10 µs registration mark (from a 50 kHz encoder) will miss its mark if the bus jitter pushes the latch over one EtherCAT cycle. The FX5U’s high‑speed counter is built directly into the CPU, with a dedicated latch line that bypasses the logic scan — so that registration is captured within 1 µs. The Omron requires an NX‑EC0242 high‑speed counter unit, which adds latency and complexity. In this case, “built‑in” isn’t just cheaper — it’s functionally safer.

When this reverses: If your I/O count is under 24 and you need a lot of analog (the NX1P2 can take up to 8 analog NX modules), the Omron’s modularity lets you mix signal types without buying a bigger CPU. The FX5U has 2 AI / 1 AO built‑in — if you need 6 analog channels, you’re adding an expansion module anyway, and the advantage flips.

3. The Hidden Tax: GX Works3 vs Sysmac Studio — Who Wastes Your Engineering Time?

Both platforms support IEC 61131‑3 programming (LD, FBD, SFC, ST). But “support” doesn’t mean equal agility. Mitsubishi’s GX Works3 uses a project‑based tree with dedicated configuration dialogs for motion, analog, and comms — the learning curve is steeper, but once the project is set, changes propagate instantly. Omron’s Sysmac Studio uses a unified tag‑based architecture that feels more polished on day one, but has a hidden cost: every time you add a new variable, the entire software build recompiles (including the motion engine). For a program with 500 variables, that can take 20–40 seconds. GX Works3 recompiles only the affected POU, typically under 5 seconds.

Worked consequence: In a commissioning scenario where you’re tweaning (tuning + tweaking) 20 variables per hour, Sysmac Studio can cost you 10 minutes of downtime per shift. Over a 3‑day commissioning, that’s 2.5 hours of non‑productive time. Mitsubishi’s faster incremental build means the machine is running again 2.5 hours sooner.

When this reverses: If you have a large, multi‑discipline team (motion, safety, visualization), Sysmac Studio’s unified project file reduces configuration errors across domains. Omron’s OPC UA server is built‑in, making data exchange to MES/SCADA trivial — whereas Mitsubishi requires a separate module (or a gateway). For plants that already run Omron’s NJ/NX line, the consistency advantage trumps compile time.

💡 Non‑obvious insight

The biggest efficiency loss in a PLC isn’t scan time — it’s the I/O gap between what’s on the CPU and what you need. Because every expansion module adds at least one bus cycle of latency, the “first hit” is free only if your I/O fits on the CPU. The FX5U’s 96‑point capacity (vs NX1P2’s 24) means it avoids that gap for a much wider range of machines. In a cost‑sensitive 48‑point packaging skid, the Mitsubishi delivers ~1 ms effective scan; the Omron with two expansion blocks delivers 3–4 ms. That’s a 3× real‑world efficiency difference you’ll never see on a datasheet.

⚠️ Failure mode / reverse case

If you push the FX5U beyond its 512‑point CC‑Link capacity (e.g., a 300‑I/O system with 10 analog channels), the expansion bus latency catches up — and now the Omron’s 8‑slot NX backplane with distributed clocks can actually produce lower jitter. Also, if your machine requires SIL 2 safety (e.g., a press), neither the FX5U nor the NX1P2 offers an integrated safety PLC — you need a separate safety controller in both cases, and the Omron’s NX‑S safety series integrates more directly. In that scenario, the safety bus overhead dominates, and the CPU choice is secondary.

Topology/standards per the cited standards; all product ratings are manufacturer-stated values from the cited datasheets, current to 2026-06; derived/illustrative figures are labelled as such. This is not an independent head-to-head test. Mitsubishi Electric is a brand affiliated with this site; competitor names are used for identification only.