Omron’s NJ and NX series machine automation controllers, and the older CJ line, run a lot of the packaging, assembly, and material handling equipment that never gets a CNC style guide of its own. They speak EtherNet/IP, and unlike a lot of Rockwell field installs, Omron programs (written in Sysmac Studio) are symbolically named by default, no bare address fallback to worry about. This guide covers the setup on the controller side and the connection to Spall.
Before you start You’ll need the controller’s IP address, the exact tag names for the values you want (from the Sysmac Studio project or a live variable table), an Ethernet drop, a fixed IP, and the Spall gateway on the same network. The gateway reads only. It never writes to the controller.
1. Confirm the controller’s EtherNet/IP port is active
On an NJ/NX controller, EtherNet/IP runs over the built in port by default, no separate option to buy or enable, this is baseline functionality on the family. Confirm the IP address under the controller’s network settings in Sysmac Studio, or on the unit’s own display if it has one, and make sure it’s a static address on the same subnet as the Spall gateway.
2. Confirm the tag names
Open the project in Sysmac Studio and check the Global Variables table for the values you want, run state, cycle complete, part count, fault. Omron’s naming convention typically keeps these as plain, human readable names already, RunStatus, PartCount, CycleComplete, write down the exact spelling and case, EtherNet/IP tag lookups are case sensitive.
3. Confirm the port answers
EtherNet/IP explicit messaging listens on the industry standard port 44818. From a PC on the same network:
nc -vz 10.0.5.20 44818
-> Connection to 10.0.5.20 44818 succeeded!
A refused connection here usually means a firewall or VLAN boundary, or the controller’s Ethernet port is on a different subnet, not a Spall problem, this test doesn’t touch Spall yet.
4. Add the source in Spall
In Spall, add the machine, choose Omron (EtherNet/IP) as the source, and enter the controller’s address:
10.0.5.20
Assign the Spall gateway on that network and save.
5. Add a tag per variable
For every point you want, add a tag with its exact global variable name from Step 2. Spall reads it by symbolic name straight from the controller, no separate offset or address to calculate.
What Spall does with this data
Availability. A tag mapped to run status splits every hour into running, idle, and down.
Downtime and reasons. Each stop is caught the instant the mapped signal changes, ranked into a Pareto.
Production. A tag mapped to part count drives target-vs-actual by shift and job, the actual side of the takt time versus cycle time math a packaging or assembly line usually cares about most.
Quality and OEE. Availability, performance, and quality roll into one OEE view, dollar-ranked, the same OEE calculation covered for every other connection method in this series.
One thing worth repeating Spall issues EtherNet/IP read requests only. It never writes a variable back to the controller. The gateway reads on your network and sends what it reads outbound over encrypted MQTT. No inbound port opens on your firewall, no VPN, no changes to the running program.
Quick recap
- NJ/NX/CJ speak EtherNet/IP over the built in port, nothing extra to enable
- Sysmac Studio’s Global Variables table gives you the tag names directly, usually already human readable
- Port 44818 is the standard EtherNet/IP port, confirm it answers before touching Spall’s side
- Add the controller’s address, then a tag per variable name, exact spelling and case
- Every new tag lands in the Signal inbox unclassified until someone tells Spall what it means
Reads by symbolic tag, no address mapping, no named setup cost, on this one the harder part is usually just getting the project file in front of you.