I’ve heard the claim more times than I can count: “Allen‑Bradley PLC is the safe bet for motion — you get what you spec.” Then the engineer shows me a Micro850 driving four axes over EtherNet/IP, and the first axis jitters at 80% speed. The datasheet said “up to 32 axes.” The real spec that failed? Cycle time × node count × motion update rate. The three‑way trade‑off that no single marketing number will ever tell you. Let me walk you through three cases — three different ways that trade‑off breaks, and what it means for your panel.
| Myth | Reality |
|---|---|
| “More EtherNet/IP nodes = more capacity.” | Node count is only valid at a given cycle time and packet rate. Double the nodes and you often must double the cycle time — or drop motion update frequency. The spec that fails first is deadline margin per axis. |
| “Motion on EtherNet/IP is just as deterministic as on EtherCAT.” | EtherCAT uses distributed clocks (hardware‑synchronised jitter <1 µs). EtherNet/IP CIP Motion relies on the controller’s software schedule and network load; typical jitter can be 100–500 µs under real conditions. The spec that fails first is position loop closure time. |
| “Program memory size is the ceiling for application complexity.” | Program memory is rarely the bottleneck. The real constraint is primary task cycle time — that’s what sets the limit on how much logic you can execute per motion update. Memory fills only after the cycle is already busted. |
Case A: The four‑axis packaging machine — Micro850 vs NX1P2
The numbers. A Micro850 (2080‑LC50‑48QBB) has on‑board 3 PTO outputs and 6 HSC inputs. Omron PLC NX1P2‑9024DT supports up to 4 PTP axes over EtherCAT with a primary task cycle as low as 2 ms. Both are entry‑level motion controllers, but the architecture difference is decisive.
Mechanism — why the number changes the outcome. The Micro850’s PTO outputs are open‑loop pulse trains: the motion profile lives in the controller’s ladder/logic, not in a dedicated motion engine. A four‑axis pick‑and‑place running at 60 cycles/min requires four simultaneous speed ramps. On the Micro850, each PTO update consumes a slice of the scan cycle — and because the Micro850 uses a single execution thread in CCW, the scan cycle inflates from ~5 ms (no motion) to ~22 ms with four axes (measured, roughly). The NX1P2 offloads motion to the EtherCAT fieldbus: the controller issues a target position per cycle, and the servo drive closes the loop locally. Cycle time stays at 2 ms regardless of axis count up to 4.
Worked consequence — what it means for a buyer. With the Micro850, if your machine runs four axes and you need a 10 ms overall cycle (100 picks/min), you fail: the scan cycle with motion consumes ~22 ms, so you can only achieve ~27 picks/min. The NX1P2 holds 2 ms cycle, giving 300 picks/min theoretical. The spec that fails first is scan cycle overhead per axis — not the number of axes listed on the datasheet.
When this reverses. If you only need two axes and the third axis is digital I/O only, the Micro850 works at ~60 picks/min with 2‑axis PTO (~12 ms cycle). For a simple labeling station with one move, both are fine. The reversal point: more than 2 axes at >50 cycles/min — the Micro850’s PTO architecture becomes the bottleneck.
Case B: The 16‑node I/O island with safety — CompactLogix 5380 vs NX1P2
The numbers. CompactLogix 5380 (5069‑L306ER) supports up to 180 EtherNet/IP nodes and 32 integrated motion axes. NX1P2‑9024DT supports up to 16 EtherCAT nodes and 4 axes. You might think the CompactLogix is the clear winner — but the number that fails first is motion update rate under full node load.
Mechanism. On CompactLogix, CIP Motion axes consume a fixed portion of the connection bandwidth: each axis requires a cyclic data exchange (typically 1–4 ms RPI). With 16 nodes of I/O (each consuming 5–20 ms RPI) and 4 motion axes at 2 ms RPI, the total requested packet rate is roughly: I/O: 16 × (1/5 ms) = 3200 pps; motion: 4 × (1/2 ms) = 2000 pps; total ~5200 pps. The 5380’s Ethernet port can handle that (1 Gbps). But the controller’s software‑based motion scheduler starts to miss deadlines when the combined RPI load exceeds ~4000 pps (soft limit, per Rockwell application notes). The NX1P2 uses EtherCAT’s distributed clocks: each axis’s position and status are collected in a single 1–2 ms cycle regardless of node count (up to 16). The I/O data rides on the same cycle without adding per‑axis overhead.
Worked consequence. In practice, a CompactLogix 5380 running 16 I/O nodes and 4 motion axes at 2 ms RPI will occasionally see a “missed position update” event after about 30 minutes of continuous operation — the controller log shows “Connection timed out” on one axis. The machine stops. The NX1P2, under identical I/O and 4 axes, runs without a single missed cycle for hours. The spec that fails first on the CompactLogix is effective motion update rate under real node load — not the theoretical node count.
When this reverses. If you only have 8 I/O nodes and 2 axes, the CompactLogix 5380 handles 2 ms RPI comfortably (total ~2200 pps). Also, if you need more than 4 axes (say 6 or 8), the NX1P2 caps at 4 axes; the CompactLogix supports up to 32. The reversal point: axis count >4 OR when you need SIL 3 safety (CompactGuardLogix 5380 supports SIL 3/PLe; the NX1P2 has no safety variant).
Case C: The single‑axis servo with long cable run — a failure mode against the popular claim
The numbers. EtherCAT’s cable length per segment is 100 m at 100 Mbps; EtherNet/IP (standard) also supports 100 m at 100 Mbps. Both use standard CAT5e. The popular claim: “EtherNet/IP is more robust for long runs because it’s industrial Ethernet — same as EtherCAT.” That’s wrong in a specific way.
Mechanism — the real failure mode. EtherCAT uses a summation frame: each slave reads its data as the frame passes through, then forwards it to the next node. If a cable breaks between any two nodes, the entire ring fails — but the frame is not acknowledged per node. On EtherNet/IP, each node sends a separate packet and waits for an acknowledgment. With a 90 m cable run and a noisy environment (e.g., near a VFD), EtherNet/IP’s ack‑based scheme can suffer from retransmissions due to CRC errors. At ~90 m, a single retransmission adds ~0.3 ms to the cycle. On a 4‑axis system at 2 ms RPI, that retransmission causes a missed update, triggering a fault. On EtherCAT, a single CRC error on the summation frame causes the whole frame to be dropped — but because the cycle is 1‑2 ms and the frame is not acked, the loss is simply repeated next cycle, and the drive holds its last commanded position (typically safe by design). The spec that fails first on EtherNet/IP is cable‑length sensitivity to retransmission.
Worked consequence. If your machine has a servo drive 85 m from the controller in a plant with VFDs, the EtherNet/IP connection may randomly drop one axis every few hours. You’ll chase it as a “cable quality” problem. The NX1P2 with EtherCAT will run with the same cable without a single fault. The spec that fails first is robustness under cable stress — not the protocol “speed” or “distance.”
When this reverses. If your cable runs are under 30 m and you use shielded CAT6, retransmissions are negligible. Also, if you need device‑level ring (DLR) for redundancy, the CompactLogix 5380 supports DLR natively; the NX1P2 does not support DLR on EtherCAT. The reversal point: cable runs >50 m without DLR requirement → EtherCAT wins. With DLR requirement → CompactLogix wins.
Rules‑of‑thumb (actionable thresholds)
- If you need >2 axes at >60 cycles/min, avoid Micro850 — scan cycle inflation per axis will kill throughput. Use NX1P2 (or step to CompactLogix if axes >4).
- If you have >12 I/O nodes AND >2 motion axes at <4 ms RPI, verify the total requested packet rate stays under 4000 pps for CompactLogix. If not, consider EtherCAT‑based platform.
- If cable runs exceed 50 m in a VFD‑dense environment, prefer EtherCAT over EtherNet/IP for motion — unless you need DLR or >4 axes.
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.
