Module 7 — PLC, Controls & Automation · LEO Technical Academy
Lesson 7.9 — Industrial Networking Basics: EtherNet/IP, Modbus, and Profibus Layouts
Level 3 (2–3+ Years Experience) 🖥 Controls ⏱ 55 min Advanced LEO-ACE-07-009 v1.0 · 2026-11-02
📌 Training Use Only
This lesson builds knowledge. Completing it does not authorize field work, equipment servicing, LOTO, energized testing, or customer-site activity. Site rules, your supervisor, and required LEO Safety Training govern all work. Stop-Work Authority is absolute.
§01 — Learning Objectives

Learning Objectives

By the end of this lesson, the technician will be able to:

§02 — Field Scenario

Field Scenario

The Network That Died Every Time It Grew: A plant's Modbus RTU network polls twelve power meters over a twisted-pair RS-485 trunk. An electrician adds meter thirteen at the far end of a new MCC — wiring it exactly like the others — and the whole network goes sick: not just the new meter, but random meters across the trunk start timing out, recovering, timing out.

The "wired exactly like the others" claim is the clue, because the last device on an RS-485 trunk is not supposed to be wired like the others. The technician who diagnoses it walks the daisy chain and finds two violations stacked: the old end-of-line device still has its termination resistor switched in (it's no longer the end), and the new true end has no termination — plus the new drop was run as a 15-meter stub teed off the trunk rather than daisy-chained. Reflections from the unterminated end and the long stub are corrupting frames for everyone — which is why the symptom scattered across the network instead of staying at meter thirteen.

The repair is pure craft, no software: re-route the new meter into the daisy chain proper, termination at the two physical ends only, old mid-line terminator switched out. The network runs clean. Serial fieldbuses are transmission lines; they obey geometry and termination rules, and they punish "it's just two wires" thinking with exactly this kind of plant-wide flakiness.

§03 — Concept Overview

Concept Overview

Industrial networks carry the plant's conversations — PLC to remote I/O (Lesson 7.1), PLC to drives (7.8), PLC to HMI (7.10). Three families cover the overwhelming majority of installed base:

EtherNet/IP (and Industrial Ethernet Generally)

Standard Ethernet hardware (RJ45 or sealed M12 connectors, Cat5e/6 or fiber, switches) carrying the CIP protocol. The dominant network on Rockwell-centric machines and the direction almost everything is moving.

Modbus — RTU and TCP

The lingua franca of meters, simple devices, and cross-vendor integration; ancient, simple, everywhere.

Profibus and Profinet

The Siemens-world counterparts: Profibus DP — the purple-cable RS-485 fieldbus with its distinctive DB9/hooded connectors carrying built-in termination switches (the switch on the connector is the termination; a connector unplugged from a terminated end device can drop the whole segment), strict baud-rate-dependent segment lengths, and station addressing. Profinet — the Ethernet-based successor, with device naming/IP assignment conventions of its own. Diagnosis logic transfers directly from the other two families: RS-485 craft rules govern Profibus trunks; Ethernet craft rules govern Profinet.

§04 — How the Principle Works

How the Principle Works: Diagnosing by Layer

Network problems sort into three layers, and the discipline is to test them in order — physical, then addressing, then configuration — because the layers above cannot work when a layer below is broken, and because the lower layers are checked with eyes and meters rather than software:

Layer 1 — The Physical Medium (Most Faults Live Here)

Cables, connectors, termination, topology, power to network hardware. The tells:

Layer 2 — Addressing and Identity

Unique IP / station address / Profinet device name; correct subnet masks. The tells: two devices flapping in alternation (duplicate address fight); a replaced device that won't join (still wearing factory defaults — the address must be set as part of replacement, which is why the drawing set's address table is a maintenance document); everything fine until "the new device" arrived (address collision or, on RTU, the Field Scenario's physical sins).

Layer 3 — Configuration and Mapping

Connection sizes, RPI/update rates, register maps, data formats. The tells: communications statistically healthy but data wrong (mapping/endianness), connection faults only under load (oversubscribed network or undersized switch), one data block bad while others from the same device are good (per-block mapping error). Layer-3 fixes are configuration changes — engineering's lane through change control (the Lesson 7.5/7.6 boundary, applied to networks). The technician's deliverable at layer 3 is the documented finding: which device, which block, expected vs. received, with evidence.

§05 — Reference Matrix

Network Family Reference Matrix

Characteristic EtherNet/IP Modbus RTU Modbus TCP Profibus DP Profinet
Physical Cat5e/6, fiber; RJ45/M12; switches RS-485 twisted pair, daisy chain Ethernet RS-485, purple cable, DB9 hooded connectors Ethernet
Addressing IP address Station 1–247 IP address Station address Device name + IP
Topology Star/linear/DLR ring Trunk daisy chain, terminated both ends Star (switched) Trunk, termination in connectors Star/linear/ring
Classic failure Duplicate IP (solid red LED); office-grade hardware; cable near VFD leads Termination/stub violations; A/B polarity; mid-line terminator left in Duplicate IP; mapping errors Connector termination switch wrong; segment length vs. baud Name/IP assignment on replacement
Replacement gotcha Set the IP before/at install Set station address; mind termination role Set IP Set address; check terminator switch role Assign device name
Where you'll meet it Rockwell PLCs, remote I/O, drives Meters, legacy devices, cross-vendor Meters/SCADA over Ethernet Siemens-era machines Modern Siemens machines
§06 — Field Application Checklist

Field Application Checklist: Running Down a Network Fault

Boundaries: panel access per electrical safe-work rules (1.5/5.1). No address changes, configuration edits, or connecting/disconnecting devices on a running production network without authorization — unplugging the wrong trunk connector can stop a plant as surely as an E-stop (and on a terminated Profibus connector, unplugging one device can kill the segment). Network configuration changes are change-controlled engineering work; physical repair of identified medium faults is technician work under normal authorization.

  1. Map the blast radius first: exactly which devices are unreachable? One device, one segment's worth, everything downstream of a point, or scattered/intermittent? Section 4's tells convert the shape of the outage into a layer hypothesis before any tool comes out. The PLC's I/O fault table and HMI comm alarms (Lessons 7.1/7.2) are the census instruments.
  2. Survey LEDs along the path: device network-status LEDs, switch port link/activity lights, media converter status — walk from the controller toward the dead zone; the boundary between healthy and unhealthy indicators is the fault's address.
  3. Interrogate what changed: new devices added (Field Scenario), replacements installed (addressing gotchas), cabinets opened, cable pulled nearby, welding in the area last night (6.9). Network faults overwhelmingly correlate with human activity.
  4. Inspect the physical layer hands-on (within authorization): connector seating and strain, cable damage and bend radius, routing vs. noise sources, water in M12s outdoors, daisy-chain integrity and stub lengths (RTU/Profibus), termination present at exactly the two ends — and nowhere else.
  5. Audit addresses against the drawing's address table when the signature says layer 2 — and treat a missing/outdated address table as a finding in itself (it's the network's equivalent of the I/O list, Lesson 7.3).
  6. Escalate layer-3 signatures as documented findings: device, data block, expected vs. observed, comm statistics if available — to the controls engineer/integrator through the site process.
  7. After any repair, verify the whole segment, not just the complaining device — termination and topology fixes change conditions for every node (the Field Scenario's scattered victims all need confirming), and a DLR ring repair requires confirming the ring is actually closed again, not running on its tolerance.
  8. Document: outage shape, layer found, physical cause, repair, and any address-table/drawing corrections through the redline process (10.9).
§07 — Knowledge Check

Knowledge Check

After a weekend during which a failed remote I/O adapter was replaced on an EtherNet/IP machine network, two devices begin misbehaving in a strange rhythm: the new remote I/O adapter and the plant's vision system alternately drop offline and recover, each a few seconds at a time, all shift. Each device runs perfectly whenever the other is unplugged. Both show solid red network status LEDs when failing. The cabling tests clean. What is the most defensible diagnosis?
§08 — Source List

Source List

← Lesson 7.8 Academy Home Lesson 7.10 →