Learning Objectives

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

• Objective 1 (Cognitive/Understanding): Identify the hardware blocks of a PLC system — processor (CPU), chassis/rack, power supply, I/O modules, and communication interfaces — and explain each block's role in the scan-based control model.
• Objective 2 (Diagnostic/Analytical): Explain the PLC scan cycle (read inputs → execute logic → write outputs) and use it to reason about where a field symptom can and cannot originate in the hardware chain.
• Objective 3 (Field/Practical): Trace a single field device from its terminal point through wiring, I/O module channel, and rack slot to its logical address — building the physical-to-logical map every PLC diagnosis depends on.

Field Scenario

Half a Machine Goes Dark: A palletizer stops mid-cycle. The operator reports "everything on the back half is dead" — back-half sensors show nothing on the HMI, and none of the back-half solenoids fire. The front half runs normally. A part-swapper hears "PLC problem" and starts pricing a new processor.

You reason from architecture instead. The front half works — so the processor is executing logic, the program is running, and the front-half I/O is being scanned. Whatever failed serves the back half specifically. The electrical drawings show the machine's I/O split across two racks: the main chassis at the panel, and a remote I/O rack mounted on the back frame, linked by a communication adapter. One look at the remote rack tells the story: every module status LED is dark. The rack's power supply has failed — the input fuse is open, and the supply's DC output reads zero.

The processor never failed; it lost contact with one neighborhood of its I/O, and its fault table says exactly that ("I/O connection fault, rack 2") to anyone who reads it. One power supply later, the back half wakes up. Architecture knowledge converted "the PLC is dead, call the integrator" into a thirty-minute fix — because the symptom's shape (one rack's worth of I/O, all dead together) pointed at the one component all those points share.

Concept Overview

A PLC is a hardened industrial computer whose entire purpose is reading field inputs, executing logic, and driving field outputs — deterministically, every few milliseconds, for decades. Its hardware blocks:

The Processor (CPU)

Executes the control program, holds the data tables (the memory images of every input, output, and internal value), and manages communications. Key technician-facing facts:

• The CPU runs a scan cycle (Section 4) — understanding it is the foundation of every PLC diagnosis.
• The CPU has modes — RUN, PROGRAM, REMOTE — controlled by a keyswitch or software. In PROGRAM mode, logic stops executing and outputs de-energize. Mode changes on a running machine are consequential acts, governed by the boundary rules below.
• The CPU stores fault tables/diagnostic logs — timestamped records of what the controller detected (I/O faults, power events, program errors). Reading the fault table is step one of any PLC service call (Lesson 7.2 covers indicators and fault interpretation in depth).
• Most CPUs carry a battery or energy-storage module preserving program/data through outages on older platforms — a dead battery plus a power cycle equals a wiped program on legacy systems, which is why program backups are a maintenance deliverable, not an IT nicety.

The Chassis/Rack and Slot Addressing

The backplane that modules plug into — it carries power and data between the CPU and modules. Every module lives in a numbered slot, and slot position is part of every I/O address: "the input at rack 1, slot 3, point 07." Remote racks (the Field Scenario) extend I/O to distant machine sections over an adapter and network/cable, trading wiring runs for a communications dependency.

The Power Supply

Converts plant power (120/240 VAC or 24 VDC) into the backplane's logic power. Two facts prevent classic confusion:

1. The rack supply powers the modules' electronics — not the field devices. Field sensors and solenoids are powered by separate field power supplies through the wiring and module channels.
2. A failed rack supply takes down everything in that rack at once — the most recognizable architecture-level failure signature there is.

I/O Modules — the Plant Interface

• Discrete input modules: read ON/OFF field states (24 VDC typical; sinking/sourcing pairing with sensors per Lesson 6.2).
• Discrete output modules: switch field loads — by transistor (DC, fast, the solid-state default), triac (AC), or relay contacts (either, with mechanical isolation and wear). Output channels have ratings; a welded or burned output channel from an overloaded solenoid is a routine field failure.
• Analog input/output modules: digitize 4–20 mA / 0–10 V signals and generate them (Lessons 6.1/6.3 — resolution, scaling, and loop behavior all land here).
• Specialty modules: high-speed counters, RTD/thermocouple direct inputs (Lesson 6.4), motion, and communication modules.

Modules provide isolation between the field's electrical chaos and the backplane — which is why a field wiring fault usually kills a channel or a module, not a processor.

Communication Interfaces

Ports and modules connecting the PLC to HMIs, VFDs, remote racks, and other controllers — EtherNet/IP, Modbus, Profibus/Profinet and kin (network architectures are Lesson 7.9's subject). For architecture purposes: every communications link is a dependency, and a lost link has its own fault signature (one device or one rack unreachable, rest of the system alive).

How the Principle Works: The Scan Cycle

The PLC does not respond to inputs the way relay logic does — continuously. It works in a loop, typically every 1–20 ms:

1. Input scan: the CPU reads every input module and copies the states into the input image table — a memory snapshot.
2. Program scan: the logic executes top to bottom, left to right, using the snapshot — not the live terminals. Results are written to the output image table.
3. Output scan: the output image is written to the output modules, energizing/de-energizing field devices.
4. Housekeeping/communications, then the loop repeats.

Field consequences a technician reasons with:

• A pulse shorter than the scan time can be missed entirely — the classic "the sensor works on the bench but the PLC never sees the part at full line speed" problem (solved with high-speed counter modules or input latching, not sensor swaps).
• Everything in one scan sees the same snapshot — input changes mid-scan don't tear the logic's view.
• The image tables are the meeting point of diagnosis: a field problem shows up as terminal state ≠ image table state (wiring/module territory); a logic problem shows up as image correct, output decision wrong (program territory — read-only diagnostic monitoring per Lesson 7.6). This single distinction sorts most "PLC problems" into the right discipline in minutes.

PLC Hardware Block Reference Matrix

Field Application Checklist: Mapping a Field Device to Its PLC Address

This mapping exercise is the foundational skill for every later lesson — performed entirely with documentation and observation, no program changes:

1. Boundary first: this is a read-and-trace task. Cabinet access follows electrical safe-work rules (Lessons 1.5/5.1) — PLC racks share enclosures with line voltage. No forcing I/O, no mode changes, no program edits — those boundaries are absolute (Lesson 7.6 and site policy).
2. Start at the field device: record its tag (e.g., LS-204) and follow its cable to the panel.
3. At the panel, find the terminal block the conductor lands on; record the terminal number from the wire label/drawing.
4. Follow the panel wiring (or the I/O drawing list) from that terminal to a specific module, slot, and point — e.g., rack 1, slot 3, input point 07.
5. Translate to the platform's logical address using the drawings (formats vary: Local:3:I.Data.7, I:3/07, %I0.3.7 — the drawing set and platform documentation define the syntax).
6. Verify the mapping by observation: actuate the device safely (hand-trip the limit switch with the machine in a safe state, or watch a normal cycle) and confirm the corresponding module channel LED follows. Device → LED agreement proves the physical chain without touching software.
7. Record the verified mapping in your field notes and flag any drawing discrepancies for the controlled redline process (Lesson 10.9) — an I/O list that doesn't match the panel is a landmine for the next person.

Knowledge Check

Source List

• Rockwell Automation / Allen-Bradley — Logix5000 Controllers Quick Start and I/O module installation manuals (rack/slot addressing, status indicators, remote I/O)
• Siemens — SIMATIC S7 System Manuals (architecture, addressing conventions, diagnostics)
• IEC 61131-1/-2 — Programmable Controllers: General Information and Equipment Requirements (PLC hardware definitions and environmental ratings)
• NEMA ICS standards — industrial control equipment requirements
• Frank Petruzella, Programmable Logic Controllers (McGraw-Hill) — architecture and scan cycle fundamentals (widely used technician text)