“My motion axis jitters every 3 seconds — the datasheet says 2 ms cycle, but Omron NX1P2 can’t hold it. Is Mitsubishi FX5U the gate I missed?”

You read the spec sheet right. Omron NX1P2-9024DT claims primary task cycle as low as 2 ms and integrated EtherCAT motion up to 8 axes. That sounds like a green light for a four-axis pick‑and‑place running at 60 cycles per minute. But the jitter you're seeing isn't broken hardware — it's an eligibility gate the datasheet didn't put in bold. The Mitsubishi MELSEC iQ‑F FX5U, with a slower‑looking ~34 ns basic instruction time, will hold that axis steady. Why? Because the gate isn't raw cycle time; it's deterministic work‑budget under mixed workload. That’s what we’re going to dig into — three dimensions where the number on the page changes whether you pass or fail the application.

1. Motion task budget: what “2 ms primary task” really means

Omron NX1P2‑9024DT lists primary task cycle as 2 ms and can handle up to 8 axes of EtherCAT motion. That combination feels generous. But here’s the part they don’t put in a callout: the 2 ms is the minimum achievable when the controller runs only the primary motion task — no I/O refresh, no serial communication, no HMI background polling. The moment you add a single analog‑input read (the NX1P2 has no on‑board analog; you’d add an NX‑AD3604, which introduces bus‑cycle overhead), the usable task budget shrinks.

In contrast, the Mitsubishi FX5U dedicates a separate hardware acceleration block for positioning and high‑speed counters on the CPU. That means the CPU’s ~34 ns instruction time doesn’t get pre‑empted by a motion interrupt — the motion runs on a dedicated co‑processor inside the same die, leaving the main scan free for logic. The worked consequence: a real 4‑axis application that also reads two analog channels (FX5U has 2‑channel 12‑bit analog input built into the CPU) will see the FX5U hold its axis steady while the NX1P2’s primary task overruns by roughly 20–30% on an illustrative worst‑case scan, causing the “jitter every 3 seconds” pattern.

When this reverses: If your entire control is pure digital I/O (no analog, no serial, no HMI) and you only need 2 axes, the NX1P2’s dedicated EtherCAT hardware gives cleaner latency than the FX5U’s built‑in PTO‑style positioning. The gate doesn’t apply — Omron PLC wins on motion + EtherCAT simplicity.

2. Programming environment lock‑in: what the “IEC 61131‑3” label hides

Both Mitsubishi PLC (GX Works3) and Omron (Sysmac Studio) support IEC 61131‑3 languages. That fact alone is a non‑differentiator — every serious PLC vendor does. But the eligibility gate is not language support; it’s whether the software environment forces you into a single project model that blocks reuse of legacy code.

Sysmac Studio, for the NX1P2, treats the whole automation as one “project” — motion, safety, logic, HMI tags are in a single database. That’s great for greenfield. But if you’re migrating from an older Omron CP/CJ series, you cannot import a function block from CX‑Programmer without rewriting it in ST or FBD. The NX1P2 has no backward‑compatible instruction set — you’re starting from zero. Mitsubishi GX Works3, by contrast, retains the MELSEC instruction set from the FX3U family (the FX5U runs ~2× the speed of FX3U but at the same instruction mnemonics), so a machine‑builder with a library of 40 ladder‑logic macros from the last decade can import them with trivial edits. The datasheet says “IEC 61131‑3” for both, but that says nothing about portability from your installed base.

The worked consequence: a plant that standardised on FX3U can drop an FX5U into the same panel and reuse 80–90 % of the program (illustrative estimate based on instruction‑set continuity). A plant migrating from Omron CJ2 to NX1P2 will face a full rewrite of every FB. That rewrite cost easily dwarfs the hardware price difference and introduces risk of logic errors in the re‑coded motion sequences.

3. I/O expansion and real‑world isolation: the connector that matters

The FX5U CPU offers up to 96 I/O on the CPU alone (512 with CC‑Link remote stations). The NX1P2‑9024DT has 24 digital I/O on‑board, expandable with up to 8 NX I/O units. On paper, the Mitsubishi raw count is larger. But that’s not the gate.

The gate is galvanic isolation between the CPU and the field wiring. On the NX1P2, the 24 on‑board I/O are not optically isolated from the CPU logic — they share a common ground plane with the controller. If you’re wiring a sensor that runs on a different 24 V supply (common in retrofits where an old panel has a floating DC bus), you risk ground‑loop injection that resets the CPU or corrupts EtherCAT frames. The FX5U, by contrast, has opto‑isolated inputs on the base unit (the standard FX5U‑32MR/ES uses photocoupler isolation on all digital inputs). That’s a published electrical spec, not a marketing claim — it’s in the isolation ratings.

The worked consequence: in a retrofitted conveyor line where three different 24 V supplies are already wired (one for sensors, one for actuators, one for the panel), the FX5U will run without ground‑fault errors. The NX1P2 will fault intermittently — sometimes once per shift, sometimes only when a motor drive kicks in — because the non‑isolated I/O bus picks up the ground offset. No datasheet tells you “this PLC faults when ground differential exceeds 7 V DC.” But the isolation spec tells you it can happen.

When this reverses: If you are building a fresh, single‑supply panel with star‑ground topology (all 0 V returns to one point), the NX1P2’s non‑isolated I/O is fine and you save the 8 mm width per channel that an isolated module would cost. The gate only applies to retrofit or multi‑supply environments.

4. OPC UA as a gate‑opener, not a spec‑sheet bullet

The Omron NX1P2 includes a built‑in OPC UA server. The Mitsubishi FX5U does not list native OPC UA in its base spec (it requires a separate MELSEC‑OPCUA module or a gateway). That looks like a clear Omron advantage. And it is — if you need IT/OT integration at the controller level without extra hardware.

But here’s the gate: OPC UA on the NX1P2 shares the same CPU that runs the 2 ms primary task. When the OPC UA server publishes a data set (say 50 variables at 100 ms publish rate), it consumes scan time. On an illustrative 50‑variable node set, the OPC UA overhead can push the NX1P2 primary task cycle from 2 ms to ~4–5 ms. That is still within spec, but now the motion jitter margin disappears. The FX5U, with its separate co‑processor for motion, doesn’t suffer that same coupling — even if you add a gateway, the motion timing is isolated.

The worked consequence: a packaging machine that needs OPC UA data to a SCADA and four synchronized servo axes will see the NX1P2’s motion degrade as soon as the OPC UA subscription is active. The FX5U with an external gateway keeps the motion isolated. The gate: if OPC UA is required at the same time as deterministic motion, the NX1P2 may need a separate OPC UA edge gateway anyway, negating its built‑in advantage.

When this reverses: If your motion axes are 0–1 (no coordinated servo), or if you can accept 5 ms+ cycle jitter, the NX1P2 with built‑in OPC UA eliminates one extra box in the panel. The gate is only a barrier for sub‑3 ms motion requirements.

Eligibility gate summary

The datasheet for each controller is truthful. But every number lives inside a use context — and context is what the datasheet leaves out. The Mitsubishi FX5U doesn’t win on raw speed or EtherCAT flash; it wins on architectural isolation (motion co‑processor, opto‑isolated I/O, instruction‑set continuity). The Omron NX1P2 wins on integration and pure EtherCAT elegance when the environment is controlled. The eligibility gate is three questions:

1. Does my workload mix motion with analog/serial/HMI? → FX5U.
2. Do I have legacy code to port? → FX5U (unless zero legacy, then NX1P2).
3. Are my field supplies isolated from each other? → FX5U (unless you use remote isolated I/O on NX1P2).

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.