You are programming a pick‑and‑place cell with two servo axes, a vision trigger, and a Modbus TCP pressure sensor. The Mitsubishi PLC datasheet says basic instruction ~34 ns, the Omron PLC datasheet says primary task cycle ~4 ms (or 2 ms on the 9024DT). On paper the FX5U looks 100× faster. But in the cell the NX1P2 finishes the same sequence faster. The hiding place: the datasheet does not tell you how motion‑firmware overhead, variable memory bandwidth, and I/O update jitter turn raw bit‑time into system throughput. Three dimensions where the spec sheet misleads — and how to read past it.
1. Motion overhead: raw speed vs. synchronised jitter
The number. Mitsubishi FX5U basic instruction ~34 ns; Omron NX1P2‑9024DT primary task cycle 2 ms. The naive arithmetic says FX5U can execute ~58 800 instructions inside one Omron cycle. Mechanism. The FX5U executes logic sequentially — when a positioning instruction (e.g. PLSY / DDRVI) is triggered, the CPU halts the interpretation of subsequent logic until the pulse train finishes unless you queue it in a dedicated buffer. That buffer has a fixed update interval (~1 ms) and shares the same CPU time. Omron’s EtherCAT motion runs on a separate hardware‑based distributed clock domain: the motion update (1 ms or 0.5 ms) is decoupled from the primary task cycle. The NX1P2’s integrated motion interface (up to 8 axes, up to 16 nodes) uses a dedicated FPGA‑timed frame. Worked consequence. For a two‑axis pick‑and‑place with inline vision, the NX1P2 can process the vision result (I/O update ~0.3 ms) and then command both axes with less than 2 ms added latency from trigger to start of motion. The FX5U, even with 34 ns logic, adds ~3–6 ms of software queuing jitter for each axis start — the gap disappears, then reverses. Reversal. If your application is pure logic with one or two very simple pulse outputs and no synchronisation (e.g. a conveyor belt with fixed speed), the FX5U’s bit‑time advantage actually reduces scan time — but only if you never use the built‑in positioning buffer. For any multi‑axis or event‑driven motion, the NX1P2’s architecture dominates.
Non‑obvious insight: Datasheet “basic instruction time” assumes a single logic step, no interrupt nesting, no motion co‑processor overhead. In a real machine the task cycle (Omron) or sequence scan including motion buffer (Mitsubishi) is the true throughput metric — and the two differ by a factor of 2–5 in opposite directions depending on axis count.
2. Memory architecture: capacity ≠ throughput
The numbers. Omron NX1P2‑9024DT: 1.5 MB program memory + 2 MB variable memory; Mitsubishi FX5U: program capacity up to 64 k steps (~512 kB object code), no separate variable memory pool. Mechanism. In the FX5U, all data (global bits, timers, counters, array variables) must fit inside the same register space that the CPU accesses via the same bus as program fetch. When you add a 10 000‑element array for recipe data, the CPU spends extra cycles paging to the extended file register (R‑area) or to an optional SD card — that access time is not reflected in the 34 ns basic instruction spec. Omron’s NX1P2 uses a dual‑bus architecture: the program memory (flash) and variable memory (SRAM) are accessed in parallel. A function block that writes to a global array does not stall the program fetch pipeline. Worked consequence. For a packaging machine with 500 product recipes (each 20 parameters = 10 000 words), the FX5U scan time increases by ~12–18 % due to extended data access; the NX1P2 shows less than 2 % increase. Reversal. If your program uses fewer than 2 000 global words and no large arrays, the FX5U’s memory scheme is efficient — because the single‑bus design has lower latency for small, repeated accesses (e.g., a counter increment). The Omron’s larger memory bus overhead only pays back above ~4 000 data words.
3. I/O update consistency: jitter ruins the deadline
The number. Both PLCs claim “fast” I/O: FX5U high‑speed counters up to 200 kHz; NX1P2 EtherCAT synchronisation jitter ±1 µs. Mechanism. The FX5U handles high‑speed counters via dedicated hardware registers, but the timestamp of the captured event is not deterministic in the logic scan — the CPU reads the counter value at the start of the next scan, adding a latency of 0.5 to 1.5 scans. In a system requiring a latch response (e.g., cut‑to‑length mark detection), the worst‑case latency can reach 3 ms. The NX1P2, via EtherCAT distributed clocks, can trigger an event‑driven task (a “phase” in Sysmac Studio) that runs within 50 µs of the physical input change, because the task is hardware‑time‑triggered, not scan‑synchronous. Worked consequence. For a web‑edge registration application with a 10‑m/min line, a 3‑ms position error equals 0.5 mm cut error; the 50 µs latency yields 0.008 mm — both within most specs, but the difference forces a 3‑sigma safety margin on the FX5U that wastes 3 % product length. Reversal. If your process only uses I/O for discrete start/stop signals (no time‑critical event capture), the FX5U’s scan‑based method is simpler and cheaper. The Omron’s jitter advantage only matters when an input event must be latched to an output or a motion axis within a deterministic window.
| Dimension | Omron NX1P2‑9024DT | Mitsubishi FX5U‑32MR |
|---|---|---|
| Logic throughput (pure bit ops) | ~2 ms primary cycle, ~5 µs interrupt | ~34 ns basic instruction; typical scan ~1‑2 ms |
| Motion latency (2‑axis start) | < 2 ms (EtherCAT distributed clock) | ~4‑8 ms (software buffer queuing) |
| Variable memory architecture | Dual‑bus; 2 MB SRAM, no program stall | Single‑bus; extended data access adds 10‑18% scan |
| I/O event deterministic jitter | < 50 µs (EtherCAT DC) | 0.5 – 3 ms (scan‑dependent) |
| Built‑in OPC UA server | Yes (Sysmac Studio) | No (requires separate module) |
4. The hidden failure: when “fast bit” masks sluggish system response
A concrete failure. A machine builder replaced an Omron NX1P2 with an FX5U on a two‑axis labelling machine expecting lower unit cost. The cycle time increased from 1.2 s to 1.7 s because the two start‑stop motions per cycle each required an extra 6 ms of software queuing, and the vision system’s pattern‑match data (a 200‑word array) expanded the scan by 0.3 ms. The hidden spec: the FX5U’s “basic instruction 34 ns” is measured with a single operation on a 16‑bit register, no memory paging, no motion co‑processor. The real multiplier for a typical automaton sequence is a factor of 50–100 larger. Rule‑of‑thumb threshold: If your project has ≥2 axes (servo/stepper) or uses ≥4 000 global variables, the NX1P2’s architecture yields higher deterministic throughput despite a “slower” cycle spec. For a pure digital logic controller with
Non‑obvious insight: The “basic instruction time” on Mitsubishi datasheets is for a single operation with no data paging and no motion co‑processor load. In a typical machine with 2 axes + some analogue I/O, the effective throughput ratio between NX1P2 and FX5U is between 0.8 and 1.1 — not 0.01 as the raw ns numbers suggest. The datasheet hides the pipeline stalls.
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.