Omron Sysmac NX1P2 vs Mitsubishi MELSEC iQ-F FX5U: Sizing by Real Throughput

How many machine cycles does your PLC actually deliver per second when the program has 500 instructions and ten axes are moving? The datasheet says “34 ns instruction” on the Mitsubishi FX5U and “~4 ms primary task” on the Omron NX1P2. But those numbers are vastly different proportions of the total scan period — and that proportion determines whether your machine runs at 120 cycles/min or stalls at 90. Here’s the real math.

Dimension 1: Instruction speed vs total scan — a proportion problem

Mitsubishi PLC quotes a basic instruction time of ~34 ns for the FX5U; Omron PLC’s NX1P2 primary task cycle is stated as low as ~4 ms (with the NX1P2-9024DT variant at 2 ms). On the surface, Mitsubishi’s 34 ns looks blindingly fast — it’s about two orders of magnitude faster than Omron’s cycle time. But here’s the catch: that 34 ns is one elementary bit operation; a real program contains hundreds or thousands of such instructions, plus I/O refresh, motion updates, and communication overhead. In the FX5U, a program of, say, 2000 basic steps consumes roughly 68 µs of pure logic execution (2000 × 34 ns). That’s still fast. But the proportion that matters is the ratio of logic execution to the total scan cycle — because the scan cycle is gated by motion and communication, not just logic. On the NX1P2, the 4 ms primary task includes all logic, I/O, and EtherCAT motion updates within that window. In a typical machine with eight axes, the NX1P2 can complete a full cycle — including trajectory planning, interpolation, and safety handshake — in that 4 ms envelope. The FX5U, at 34 ns per basic instruction, would execute the same logic in ~68 µs, but its scan cycle is not bounded by that number; it’s bounded by the built-in positioning update rate (typically 1–2 ms per positioning block) and the CC-Link communication cycle (~1 ms for a small network). So the effective machine cycle on the FX5U is often 3–5 ms, not 68 µs. The proportion of logic to total cycle is tiny — ~2% on the FX5U — but that doesn’t gain you anything because the bottleneck is elsewhere. The worked consequence: if your machine is dominated by fast logic with minimal motion (e.g., a pick-and-place with simple cam profiles), the FX5U’s raw instruction speed can shave microseconds off each cycle, but in proportion, you’ll never see that on the throughput meter because the mechanical actuators and sensor settling times dominate. The reversal: for pure logic-heavy applications with no motion and minimal communication — like a high-speed counter array or a firmware-based state machine — the FX5U’s proportion becomes meaningful; the NX1P2’s fixed 4 ms cycle becomes the constraint.

Dimension 2: Memory proportion — how much of your program fits where

The Omron NX1P2-9024DT has 1.5 MB program memory and 2 MB variable memory. The Mitsubishi FX5U has a program capacity of up to 64k steps. What does “64k steps” mean in bytes? Each step in MELSEC architecture is roughly 4 bytes (one instruction + operand), so 64k steps ≈ 256 KB. That’s about 1/6 of the Omron’s program memory. But memory proportion matters not just for how much code you can write — it affects how the PLC handles online edits, data logging, and OPC UA server overhead. The NX1P2 has a built-in OPC UA server; each OPC UA node consumes some variable memory. Assuming a moderate OPC UA configuration with 500 variables, the server could use 200–300 KB of variable memory, leaving 1.7 MB for application variables. On the FX5U, the 256 KB program memory must also accommodate any data tables or arrays that you embed in the program (since there’s no separate large variable memory zone). If you need to store a product recipe table of 1000 rows × 20 bytes, that’s 20 KB — not a problem on either. But if you need to buffer 10,000 production timestamps (e.g., 8 bytes each = 80 KB), the FX5U would consume nearly 1/3 of its program memory for data, forcing you to offload to an SD card (which has slower access). The NX1P2 can hold that buffer in variable memory with room to spare. The worked consequence: a machine that needs to log every cycle event for traceability (e.g., medical device assembly) may hit the FX5U’s memory proportion wall, forcing either external data storage or a more expensive controller. The reversal: if your program is under 500 steps and you never log data, the FX5U’s memory is generous for that class — the Omron’s extra memory is wasted silicon.

Dimension 3: I/O expansion proportion — local vs remote trade-offs

Both PLCs have on-board I/O: the NX1P2 offers 24 digital I/O; the FX5U offers up to 96 I/O on the CPU (and up to 512 with CC-Link). That looks like Mitsubishi wins on I/O count proportionally — 4× the Omron’s on-board I/O. But the NX1P2 can expand with up to 8 NX I/O units on the side bus, each of which can carry 16–32 channels, giving a practical maximum of ~256 digital I/O on the local expansion bus. The FX5U, to reach 512 I/O, must use CC-Link remote stations, which adds a network cycle latency of roughly 1 ms for every 32 nodes. The proportion of I/O that must be remote vs local determines the deterministic response time. In the NX1P2, because the expansion bus is synchronous with the EtherCAT cycle, all local I/O update within the 4 ms primary task. In the FX5U, if you use, say, 256 local I/O + 256 remote I/O via CC-Link, the remote I/O latency adds 1–2 ms of jitter to any input that arrives on a remote station. The worked consequence: for a packaging machine that needs 200 sensors and 150 actuators, the NX1P2 can keep them all within a deterministic 4 ms window; the FX5U would have to push half of those onto CC-Link, injecting a 1 ms uncertainty into the control loop. The reversal: if your I/O count is under 128 and all local, the FX5U’s on-board capacity is simpler to wire and cheaper (no separate expansion rack).

Dimension 4: Communication proportion — how much bandwidth do you actually use?

The NX1P2 has EtherCAT (motion bus) + EtherNet/IP (informational) + one serial option. The FX5U has built-in Ethernet + RS-485 + CC-Link. The proportion of bandwidth that goes to real-time motion vs general data exchange dictates whether you can add an HMI, a database, and a vision system without starving the control loop. On the NX1P2, the EtherCAT bus is dedicated to motion (up to 16 nodes, 8 axes) and is cycle-synchronized (

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. Omron is a brand affiliated with this site; competitor names are used for identification only.