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:
Objective 1 (Cognitive/Understanding): Identify the major industrial network families — EtherNet/IP, Modbus (RTU and TCP), and Profibus/Profinet — by their physical media, connectors, and addressing schemes, and state where each is typically found.
Objective 2 (Diagnostic/Analytical): Diagnose network problems by layer — physical medium first, then addressing, then configuration — using status LEDs, fault tables, and the distinctive failure signatures of each family.
Objective 3 (Field/Practical): Apply industrial network craft: termination rules on RS-485/Profibus trunks, address uniqueness audits, cable hygiene around noise sources, and the discipline boundary around network configuration changes.
§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.
Addressing: IP addresses — every device needs a unique address on a properly planned subnet. Duplicate IPs are the family's classic self-inflicted wound (the solid-red network LED of Lesson 7.2): symptoms include two devices alternately falling off the network, and they appear when a replacement device ships with a default address already in use.
Topology: star (through switches), linear (devices with embedded 2-port switches), or ring (DLR) for fault tolerance. Know which one the drawings claim, because diagnosis differs: a broken linear chain cuts off everything downstream; a broken DLR ring keeps running and quietly flags a ring fault that must be found before the second break hurts.
Field realities: office-grade unmanaged switches and consumer cables creep into panels during emergencies and become permanent intermittents; industrial-rated, managed switches and bend-radius-respected, noise-separated cable (Lesson 6.9 — Ethernet near VFD output leads is a classic) are not luxuries. A plant network is not the office network — connecting plant Ethernet to IT's network, adding devices, or changing addresses without the controls/IT coordination process is how production stops mysteriously at 2 a.m. (and increasingly a cybersecurity boundary as well).
Modbus — RTU and TCP
The lingua franca of meters, simple devices, and cross-vendor integration; ancient, simple, everywhere.
Modbus RTU: serial, usually over RS-485 twisted pair: a daisy-chained multi-drop trunk, one master polling up to 32 typical slaves, each with a unique station address (1–247). Field rules that decide whether it works: daisy-chain topology (no long stubs), 120 Ω termination at the two physical ends only, biasing per the master's documentation, A/B polarity consistent end to end (the polarity flip is the "everything installed, nothing talks" classic), and shield grounding discipline per Lesson 6.9.
Modbus TCP: the same register-based protocol carried over Ethernet — inherits Ethernet's physical layer and IP addressing, keeps Modbus's data model.
The data model: devices expose numbered registers (holding registers, input registers, coils). Integration problems are usually mapping problems — the PLC reading register 40021 when the meter publishes at 40011, or word-order/byte-order (endianness) mismatches that turn sensible values into garbage numbers. Symptom signature: communication healthy, values insane → mapping/format; communication dead → physical/addressing.
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:
Everything on one segment down → trunk break, switch/power failure, or termination disaster (Field Scenario).
Everything downstream of a point down (linear/daisy-chain) → break at that point. The boundary device's location is the diagnosis.
One device down → its drop: cable, connector, port, device power.
Intermittent, vibration- or temperature-correlated → connector seating, flexing cable (Lesson 7.1's turret), cable damage, noise coupling (Lesson 6.9 — check the cable route against VFD leads and welders).
Status LEDs (Lesson 7.2's network conventions: flashing green idle, solid green connected, flashing red timeout, solid red duplicate/hard fault) localize the layer fast.
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.
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.
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.
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.
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.
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).
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.
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.
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?
Detailed Explanation
Every element of the symptom is in the duplicate-address textbook: two specific devices (not a segment, not everything downstream — ruling out medium and switch-wide faults), alternating outages (the address fight see-saws as each device defends the identity), each fine alone (no conflict when the rival is absent), and solid red status — the LED convention this module assigns to duplicate address/hard fault, distinct from flashing red's timeout (Lesson 7.2). The timing seals it: the behavior began with a device replacement, the exact moment addressing gotchas enter (Section 5's replacement row). Answer C condemns hardware for a configuration collision — and the "defective" replacement works perfectly alone, which a defective unit wouldn't. Answer D can't explain why unplugging the adapter heals the vision system. Answer B invents a load problem to explain a pattern load doesn't produce (oversubscription degrades under traffic peaks; it doesn't alternate two victims in a clean rhythm). The fix is administrative and disciplined: the documented address table is the source of truth, the address assignment goes through authorized configuration (layer 3's change boundary), and the closure test is both devices online together — the only condition the conflict could never survive.
§08 — Source List
Source List
ODVA — EtherNet/IP specifications and Media Planning & Installation Guide (topology, DLR, status indicators)
Modbus Organization — Modbus over Serial Line Specification & Implementation Guide (RS-485 rules: termination, biasing, addressing)
PROFIBUS & PROFINET International (PI) — installation and commissioning guidelines (segment rules, connectors, device naming)
Rockwell Automation — EtherNet/IP design and installation publications (industrial vs. commercial hardware, addressing practice)
TIA-485 / industrial cabling standards — RS-485 electrical characteristics; with Lesson 6.9's noise and routing discipline