14
Process Control, Network Systems, and SCADA
Chapter 13 taught you to deploy and troubleshoot a single PLC. Chapter 14 puts that PLC into the larger universe it lives in: a plant where dozens of controllers talk to each other over networks, a control room where SCADA servers aggregate everything into operator screens, and processes whose dynamics demand more sophistication than on/off can deliver. This is a tour of that universe — process types, control structures, the PID instruction at the heart of continuous control, the motion instructions for moving things accurately, the protocol stack that lets a Rockwell PLC talk to a Siemens VFD, and the SCADA architecture that ties hundreds of devices into one operator console. Eight programs walk you from bang-bang heater control all the way to a SCADA alarm publish-and-acknowledge pattern.
What you’ll be able to do after this chapter
Your goals for this chapter:
- Distinguish continuous, batch, and discrete processes and recognise which control techniques fit each.
- Read a control system as a block diagram with sensors, controller, actuators, and feedback path.
- Implement on/off (bang-bang) control with deadband for the simple cases where it’s the right tool.
- Configure a PID instruction with appropriate proportional, integral, and derivative gains, and recognise common tuning failures.
- Combine PID loops in a cascade structure for processes that need both responsiveness and stability.
- Generate a setpoint ramp so that PID transitions don’t slam the process around.
- Implement basic single-axis position control with proportional velocity output.
- Send and receive data over industrial networks — Modbus RTU, Modbus TCP, EtherNet/IP — using the MSG instruction.
- Recognise the role of legacy networks (Data Highway, DeviceNet, ControlNet, PROFIBUS-DP, Fieldbus) and the trend toward Ethernet-based industrial protocols.
- Build a SCADA-friendly alarm structure with publish-and-acknowledge semantics that the HMI/SCADA layer can use directly.
Key Concepts & Terms
Types of Industrial Processes
Before choosing a control strategy, you have to recognise the kind of process you’re controlling. Industry sorts processes into three broad families, and each family suits a different toolkit.
Continuous processes
A continuous process runs without natural start or stop points — material flows steadily through equipment that’s always operating at (ideally) a steady state. Petroleum refineries, paper mills, electricity-generating plants, and water-treatment plants are textbook continuous processes. The control problem is to keep variables (temperature, pressure, flow, level, composition) at their setpoints as disturbances try to push them away. PID is the workhorse for continuous control.
Batch processes
A batch process produces discrete quantities by running through a recipe of sequenced steps. Pharmaceutical manufacturing, brewing, food production, and specialty chemicals are typical batch operations. Each batch has a defined beginning and end; the control system has to drive the equipment through the recipe (load → mix → heat → react → cool → drain) and handle batch-specific data (batch ID, lot number, ingredient quantities). Sequencer instructions from Chapter 12 anchor batch logic; PID handles each step’s continuous variables.
Discrete processes
A discrete process manufactures countable, identical items — bottles on a filling line, cars on an assembly line, circuit boards through a pick-and-place machine. The control task is to coordinate machines, track parts (Chapter 12’s shift registers), and verify quality. PID matters less here; logic, sequencing, and motion control dominate.
| Process type | Example | Primary controls | Time scale of disturbances |
|---|---|---|---|
| Continuous | Refinery, power plant, water treatment | PID loops, cascade, ratio | Seconds to minutes |
| Batch | Brewery, pharmaceutical reactor, chemical kettle | Sequencer + PID per step | Minutes to hours per batch |
| Discrete | Bottling line, assembly line, packaging cell | Logic + motion + tracking | Sub-second to seconds per part |
Most real plants are mixtures
A modern food-processing plant is a beautiful illustration of all three: continuous water and gas utilities run in the background; the cooking step is batch (recipe-driven); the packaging line is discrete (one bottle, one bottle, one bottle). The PLC controls all three side by side. Recognising which family each part of the plant belongs to tells you which Chapters of this book apply where — Chapter 12 sequencers for batch, this chapter’s PID for continuous, the entire logic-and-tracking toolkit from earlier chapters for discrete.
Structure of Control Systems
Every control system, whatever its sophistication, is built from the same five elements: setpoint, sensor, controller, actuator, and process. The arrangement of these elements determines whether the system is open-loop or closed-loop — and that single distinction shapes everything else about how the system behaves.
Open-loop control
An open-loop system applies an action and hopes for the best — there’s no feedback from the process to tell the controller whether the action achieved its intent. Turn a heater ON for 5 minutes; turn it off. Whether the room actually got warm depends on outside temperature, door openings, the heater’s actual output. The controller doesn’t know and can’t compensate. Open-loop is simple, cheap, and fine when the process is highly predictable — but useless when disturbances matter.
Closed-loop (feedback) control
A closed-loop system measures the process variable, compares it to the setpoint, computes an error, and applies a correction. The cycle repeats continuously, so the system self-corrects against disturbances. This is what the rest of this chapter is about. The price you pay for closed-loop is added complexity (sensor, signal conditioning, controller tuning) and the possibility of instability — a badly-tuned closed loop can oscillate, where the open-loop system would just sit there.
Figure 14.1 — Open-loop vs closed-loop controlThe open-loop system (top) applies an action and hopes; the closed-loop system (bottom) measures the process variable, subtracts it from the setpoint to compute an error, and the controller drives the actuator to make that error zero. The single feedback arrow is the difference between “wishing” and “controlling”.
Hierarchy of control
Real plants stack control loops in layers. At the bottom: device-level loops controlling individual valves, motors, and heaters. Above those: supervisory loops that set the device-level setpoints based on plant-wide objectives. Above those: scheduling systems that decide what to make and when. PLCs typically operate at the bottom and middle layers; SCADA and MES systems handle the top layers. We’ll see this hierarchy again in Section 14.7.
On/Off (Bang-Bang) Control
The simplest closed-loop strategy is on/off control: the actuator has only two states (fully on, fully off), and the controller switches between them based on whether the process variable is below or above the setpoint. Your home thermostat is the textbook example — heater on when room is cold, off when warm.
The deadband — why hysteresis is mandatory
A naïve on/off controller (heater on when PV < SP, off when PV ≥ SP) will switch thousands of times per minute as the PV oscillates noisily around the setpoint. That destroys contactors, wastes energy, and creates electrical noise (which we now know to take seriously after Chapter 13).
The fix is a deadband (also called hysteresis): two thresholds instead of one. The heater turns ON only when PV drops below SP − ½DB, and turns OFF only when PV rises above SP + ½DB. Inside the deadband, the controller leaves the actuator alone. The deadband makes the controller deliberately “lazy” near the setpoint, accepting some PV variation in exchange for not chattering.
When on/off is the right choice — and when it isn’t
- Right choice for slow processes with significant thermal mass (room heating, water heaters, large ovens). The deadband variation is tolerable; the simplicity is welcome.
- Right choice when the actuator only has two states anyway — pump-on/pump-off, heater-on/heater-off, valve-open/valve-closed. There’s nothing in between to use.
- Wrong choice for fast processes where the deadband would cause unacceptable variation (precision temperature control, flow regulation in a refinery).
- Wrong choice when the actuator is variable (modulating valve, VFD-driven motor) — you’d waste the actuator’s capability and use only its extremes.
Worked Example 1 implements an on/off heater controller with deadband, end-to-end.
PID Control
PID — Proportional, Integral, Derivative — is the single most-used control algorithm in industrial automation. It’s the answer to “I want continuous, smooth control of an analog process variable using an analog actuator.” If on/off is a hammer, PID is the surgeon’s scalpel — and 95 % of continuous-process control loops in the world are PID loops.
The three terms
PID computes its output as the sum of three terms, each computed from the error e = SP − PV:
- Proportional (P). Output proportional to the present error. Big error → big correction. Small error → small correction. Tuning gain:
Kp. P alone never quite reaches the setpoint (it leaves a steady-state offset called droop), because as the error shrinks, so does the correction. - Integral (I). Output proportional to the accumulated error over time. Even a small persistent error eventually builds a big integral correction, eliminating the droop that pure-P leaves behind. Tuning gain:
Ki(or reset, sometimes specified as integral timeTi). I is what gets PID actually at setpoint. - Derivative (D). Output proportional to the rate of change of error. Anticipatory — if the error is rising fast, D adds extra correction even before the error gets large. Tuning gain:
Kd(or derivative time). D is what makes PID respond quickly to disturbances. Often turned off (Kd = 0) in noisy processes because D amplifies noise.
The standard PID equation
CV(t) = Kp · e(t) + Ki · ∫e(t)dt + Kd · de(t)/dt
The PLC implements this in discrete time — every scan, it computes the new error, updates the integral by adding e × Δt, computes the derivative by differencing the previous error, and sums the three terms to produce the new control output.
Tuning — the engineering art
PID tuning is the process of selecting Kp, Ki, and Kd that produce stable, responsive control of a particular process. There’s a science (Ziegler-Nichols method, Cohen-Coon, lambda tuning) and an art (intuition built from many tunings). Common pathologies and their fixes:
| Symptom | Likely cause | Fix |
|---|---|---|
| PV oscillates around SP and won’t settle | Kp too high (gain margin too low) | Reduce Kp |
| PV approaches SP slowly, never reaches it | No integral term, or Ki too low | Add or increase Ki |
| PV overshoots SP, slowly settles back | Ki too high (integral windup) | Reduce Ki, add anti-windup |
| PV jitters with noise, CV jumps wildly | Kd too high in noisy process | Reduce Kd, often to 0 |
| PV slams when SP is changed manually | Step change in SP causes derivative kick | Use setpoint ramp (Worked Ex 4) |
A practical tuning starting point
If you don’t have the time or instrumentation for formal Ziegler-Nichols tuning, a working starting point for most temperature loops is: Kp = 1.0, Ki = 0.05 (roughly 20-second integral time), Kd = 0. Watch the loop’s response to a step change in setpoint. If it oscillates, halve Kp; if it’s sluggish, double Kp. Iterate. Most loops settle into a workable tune within 20 minutes of patient observation. Tune in manual mode first if possible — drive the actuator directly and watch how the process responds, before you let the PID close the loop. Understanding the open-loop response makes tuning the closed loop much easier.
Worked Examples 2, 3, and 4 build through PID step by step: a basic loop, a cascade structure, and a setpoint ramp generator that protects the process from sudden setpoint changes.
Motion Control
Motion control is the family of techniques that move things to specific positions, at specific velocities, with specific acceleration profiles. Where logic control answers “is the bottle present?” and PID answers “is the temperature 80 °C?”, motion control answers “is the spindle exactly at 127.452 mm, decelerating at 200 mm/s², ready to plunge?”
The motion-control family of variables
- Position — where the moving part currently is (encoder feedback, in counts, mm, or degrees).
- Velocity — how fast it’s moving and in which direction (the derivative of position).
- Acceleration — how fast velocity is changing (the second derivative of position).
- Jerk — how fast acceleration is changing (used in S-curve profiles to eliminate mechanical jolts).
Two layers of motion control
A simple PLC application controls motion from outside the drive: the PLC outputs a velocity command (typically a 0–10 V analog signal or a digital command via network), and the drive itself closes the velocity and current loops. The PLC’s job is to generate the right velocity command based on where the part is and where it should be. This is sometimes called “soft” motion control.
“Hard” motion control uses a dedicated motion controller (or a PLC with motion-axis support like Studio 5000’s Motion module) that closes the position, velocity, and current loops at the controller. The application program sends high-level commands (“move to 200 mm at 50 mm/s with 100 mm/s² accel”) and the motion module handles the rest. This is what most industrial servo systems do today.
Common motion patterns
- Indexer / single-axis position move. Move from current position to a commanded position, decelerating smoothly to a stop. Worked Example 5 implements a simple version of this.
- Coordinated multi-axis moves. Two or more axes move together so the tool follows a path (CNC machining, 3D printing). Each axis must arrive at the right position at the right moment.
- Electronic gearing. One axis follows another at a fixed ratio (e.g. paper-cutting blade synchronised to web speed).
- Cam profiling. One axis follows another according to a non-linear profile stored in a table.
Motion control is its own deep specialty
Real motion engineering — servo tuning, multi-axis interpolation, feedforward control, mechanical-resonance compensation — is a career in itself. The treatment here covers the basics every PLC engineer needs: what motion controllers do, when you need one rather than just PID, and how a basic position move is structured. Worked Example 5 implements a simplified position controller that demonstrates the pattern; a real motion application would use vendor motion-axis instructions on a controller with hardware support for fast encoder feedback.
Data Communications and Industrial Networks
A modern plant has anywhere from a handful to several thousand intelligent devices that need to talk to each other — PLCs, drives, sensors, instruments, HMIs, SCADA servers, MES systems. The protocol stack that lets them all communicate is one of industry’s most fragmented and historically-layered topics, and any PLC engineer working today needs at least a working familiarity with the major players.
The three-tier industrial network hierarchy
Industrial networks are conventionally arranged in three tiers, distinguished by the speed/determinism trade-off:
Figure 14.2 — The three-tier industrial network hierarchyInformation-tier networks carry large but non-time-critical data (databases, reports). Control-tier networks carry deterministic peer-to-peer messages between PLCs. Device-tier networks carry tiny but very fast messages between PLC and field instruments.
The protocols you’ll meet — a working tour
Serial fundamentals — RS-232, RS-422, RS-485
Beneath everything is serial communication. RS-232 is the original PC serial port — point-to-point, short distances (15 m), simple. RS-422 is differential, longer distances (1200 m), one transmitter and multiple receivers. RS-485 is the industrial workhorse — differential, multi-drop (up to 32 nodes), 1200 m, half-duplex. Most device-tier protocols ride on RS-485 physical layer.
Allen-Bradley legacy — Data Highway
Data Highway (DH-485, DH+, ControlNet) is Rockwell’s family of proprietary industrial networks dating from the 1980s and 1990s. DH-485 is a multi-drop network for SLC-500-class controllers. DH+ is the higher-speed version for PLC-5. These networks are still common in older installations but new projects almost always use EtherNet/IP today.
Modbus RTU and Modbus TCP — the universal language
Modbus is the lingua franca of industrial networks. Created by Modicon in 1979, ridiculously simple compared to its competitors, and supported by virtually every industrial device made since 1990. Modbus RTU runs over RS-485 (or RS-232) at the device tier; Modbus TCP runs over standard Ethernet at the control tier. Master/slave architecture: a master polls slaves for register values; slaves never volunteer data. The simplicity is what made it ubiquitous — even cheap meters and drives speak Modbus, and any PLC can be a Modbus master with a simple MSG instruction (Worked Example 6).
DeviceNet
DeviceNet is Rockwell/ODVA’s CAN-bus-based device-tier network. Deterministic, multi-master, supports up to 64 devices on a single segment. DeviceNet was the dominant device network for Rockwell installations through the 2000s; it’s now being slowly displaced by EtherNet/IP at the device level.
ControlNet
ControlNet is Rockwell/ODVA’s deterministic high-speed control-tier network. Coaxial cable, scheduled cyclic communication, designed to provide hard real-time guarantees that standard Ethernet couldn’t (in the late 1990s). Largely superseded by EtherNet/IP today, but still found in legacy ControlLogix installations.
EtherNet/IP — the modern dominant protocol
EtherNet/IP is Rockwell/ODVA’s industrial protocol layered on top of standard Ethernet. The “IP” stands for Industrial Protocol (not Internet Protocol — coincidentally the same letters, often confusing). EtherNet/IP uses standard Ethernet hardware, switches, and cables, layered with the Common Industrial Protocol (CIP) on top to provide industrial-quality services. This is the most common protocol on new Rockwell installations today. Worked Example 7 demonstrates an EtherNet/IP MSG between two ControlLogix processors.
PROFIBUS-DP and PROFINET
PROFIBUS-DP (Decentralised Peripherals) is Siemens’s RS-485-based device-tier network — the European equivalent of DeviceNet, dominant in Siemens-heavy markets (most of Europe, much of Asia). PROFINET is Siemens’s Ethernet-based industrial protocol — the equivalent of EtherNet/IP. Like the Rockwell stack, the trend is toward PROFINET on new installations.
Foundation Fieldbus
Foundation Fieldbus (H1, HSE) is a process-industry-focused protocol — common in oil refineries, petrochemical plants, and other process industries. Distinguished by the fact that function blocks (including PID) can run distributed in the field instruments themselves, not just in central PLCs/DCS controllers.
The trend everyone agrees on: Ethernet is winning
Industrial communication has spent 30 years inventing and reinventing specialised protocols, but the market is converging on Ethernet-based solutions across the board: EtherNet/IP for Rockwell, PROFINET for Siemens, EtherCAT for high-speed motion, Modbus TCP for everyone else. The advantages are simple: standard hardware (any Cisco switch works), standard tools (any laptop can sniff packets), bigger pool of trained engineers, and direct integration with IT systems. Specialised protocols (DeviceNet, PROFIBUS-DP, ControlNet) still exist in legacy installations and will for decades, but new installations almost always start with Ethernet. Bet on Ethernet for new work.
SCADA — Supervisory Control and Data Acquisition
SCADA is the layer that sits above the PLCs and gives operators a unified view of the plant — graphical screens showing every tank, valve, motor, and trend; alarm management; historical data trending; reporting. SCADA isn’t a single product; it’s a category of software systems (Wonderware/AVEVA, Ignition, Rockwell FactoryTalk View, Siemens WinCC, GE iFIX) that all do roughly the same job using PLC tags as their data source.
The classic SCADA architecture — four layers
Figure 14.3 — Classic SCADA architectureThe bottom layer is the PLCs and field devices we’ve been programming all along. The communication layer (OPC, native drivers) bridges them to the SCADA server, which stores the live tag database and historical data. Operators see only the top layer — graphical screens that read from and write to tags. Commands flow down; data flows up.
What the PLC programmer owes the SCADA system
From the PLC programmer’s perspective, the SCADA layer is “just another consumer of my tags”. Good practice is to design your PLC program with SCADA integration in mind:
- Group SCADA tags into named structures. Every motor has a standardised set of tags — Run, Stop, Fault, Speed, Current, Hours_Run — packaged into a Motor structure. SCADA can then drop a single “motor faceplate” graphic and bind it to the Motor structure once, regardless of which physical motor it represents.
- Provide latched alarms with publish-and-acknowledge semantics. An alarm bit goes ON when the condition is true, stays ON until both the condition is gone AND the operator has acknowledged it from SCADA. Worked Example 8 implements this pattern.
- Keep raw and engineering values both available. The raw 0–32767 ADC value is for diagnostics; the scaled engineering value (in °C, in psi, in litres) is for SCADA display. Provide both — the SCADA layer will use the engineering value 99 % of the time but the raw value is invaluable for troubleshooting.
- Update at sensible rates. A flow value updated every PLC scan (10 ms) but only displayed once per second on SCADA wastes bandwidth. Many platforms support deadband-based update suppression — only publish a value when it changes by more than a configurable threshold.
The historian — every value is a memory
Modern SCADA systems include a historian — a time-series database that stores every change of every tag, with timestamps. Historians make it possible to look at last Tuesday’s overnight excursion, plot a year of pump-running hours, or correlate a quality drop in March with a controller change in February. The historian is often the single most-valuable asset in the SCADA system — and the most-overlooked. Engineers come back to it again and again to answer questions that would otherwise be unanswerable.
Worked PLC Programs
Eight Programs — From Bang-Bang to SCADA Alarms
The eight programs span the chapter’s full topic space: on/off heater control with deadband, a basic PID temperature loop, cascade PID for level + flow, a setpoint ramp generator, a single-axis position indexer, a Modbus RTU MSG read, an EtherNet/IP peer-to-peer MSG, and a SCADA-friendly alarm publish-and-acknowledge pattern.
The problem: a process tank has an immersion heater that’s either ON or OFF — there’s no modulating valve, no SCR power controller, just a contactor. The setpoint is 75.0 °C, but the heater takes 5–10 seconds of continuous operation to make a measurable temperature change. Without hysteresis, the contactor would chatter thousands of times a minute as the PV fluctuates around the setpoint. We need a deadband of ±0.5 °C: heater ON when PV drops below 74.5 °C, OFF when PV rises above 75.5 °C, untouched in between.
Inputs & Outputs
INPUTS
F8:0 — PV: tank temperature (°C, scaled engineering units)
F8:1 — SP: setpoint (75.0 °C)
F8:2 — DB: deadband width (1.0 °C, so ±0.5 either side)
I:1/0 — System enable
OUTPUTS
F8:3 — Lower threshold = SP − DB/2 (74.5 °C)
F8:4 — Upper threshold = SP + DB/2 (75.5 °C)
O:2/0 — Heater contactor (latched)
Ladder Diagram (Four Rungs)
Four rungs. Rungs 0 and 1 compute the upper and lower thresholds from SP and DB. Rung 2 latches the heater ON when PV drops below the lower threshold. Rung 3 unlatches the heater when PV rises above the upper threshold. Between the thresholds (the deadband), neither rung does anything, so the heater stays in whatever state it was last commanded to.
A walk-through of one heating cycle
| PV (°C) | Compared to thresholds | Heater action |
|---|---|---|
| 72.0 (cold) | Below 74.5 → LES rung true | LATCH ON |
| 73.5 (rising) | Below 74.5 → LES still true | Heater on (latched) |
| 74.5 (at lower) | Above 74.5 but below 75.5 | Heater on (latched, in deadband) |
| 75.0 (at SP) | In deadband | Heater on (still latched) |
| 75.6 (rising past upper) | Above 75.5 → GRT rung true | UNLATCH OFF |
| 75.0 (cooling) | In deadband | Heater off (still unlatched) |
| 74.5 (at lower again) | In deadband | Heater off (still unlatched) |
| 74.4 (drops below lower) | Below 74.5 → LES rung true | LATCH ON again |
Notice the cycle: heater turns on, drives PV up past upper threshold (75.5), turns off, PV slowly cools back down past lower threshold (74.5), turns on again. The natural period of the on/off cycle is determined by the process’s thermal time constant — slower processes give longer, gentler cycles. With ±0.5 °C deadband, you might see the heater cycle once every 2–5 minutes for a typical tank — gentle on the contactor, fine for the process.
The problem: a heat exchanger uses steam to heat process fluid to 80.0 °C. Unlike Program 1’s bang-bang heater, this system has a modulating steam valve that can be partially open — anywhere from 0 % (closed) to 100 % (fully open). PID is the natural fit: continuously compute the steam-valve opening (the Control Variable, CV) that drives the temperature (PV) to setpoint (SP).
Inputs & Outputs
INPUTS
F8:0 — PV: process temperature (°C from scaled RTD)
F8:1 — SP: setpoint (80.0 °C, set by operator/SCADA)
I:1/0 — Auto/Manual mode (1 = AUTO, 0 = MANUAL)
F8:2 — Manual CV (operator’s manual valve command)
OUTPUTS
F8:5 — CV: control variable (0–100 % steam valve)
O:5 — Analog output to steam valve (0–32767 = 0–100 %)
PD9:0 — PID control block (gains, modes, working values)
PID configuration block (PD9:0 settings)
| Parameter | Setting | Meaning |
|---|---|---|
| Mode | AUTO (driven by I:1/0) | Auto = PID computes CV; Manual = operator controls CV directly |
| Forward/Reverse | Reverse-acting | When PV < SP, CV increases (open valve more = heat more) |
| Kp (P-gain) | 2.0 | Proportional gain — 1 °C error → 2 % CV change |
| Ti (Integral time) | 30 s | Integral time — moderate reset action, suits slow thermal process |
| Td (Derivative time) | 0 s | Derivative off — RTD signal is slightly noisy, D would amplify |
| CV Min / CV Max | 0 % / 100 % | Output limits — also used for anti-windup |
| Loop Update | 1.0 s | Loop run period — PID computes 1×/sec (sufficient for thermal) |
| PV Scaling | 0–32767 → 0–200 °C | Raw analog count to engineering units |
Ladder Diagram (One Rung)
A single PID instruction does the entire job. The instruction reads PV from F8:0, compares to SP at F8:1, applies Kp/Ti/Td from the PD9:0 block, and writes the computed CV to F8:5. A separate “scaled output” rung (not shown) converts F8:5 percent to the 0–32767 raw analog count for the output module.
The PID instruction is sophisticated software in a tiny package
Behind that single rung lives several hundred lines of carefully-engineered code: gain scaling, integral accumulation with anti-windup, derivative filtering, mode switching (auto/manual/cascade), bumpless transfer, alarm checking. The PD9:0 block is a 23-element data structure where each element holds one of those parameters. You almost never need to write the PID equation yourself — the vendor’s PID instruction handles it correctly; your job is just to configure it appropriately and tune it. That’s the deal: trust the instruction, focus your effort on tuning.
The problem: a feed tank’s level must be held at 60 % full. The inlet is controlled by a flow valve, but the upstream supply pressure varies — so a constant valve position gives variable flow, which gives variable level. The classic cascade control solution: an outer loop on level whose CV becomes the setpoint of an inner loop on flow. The inner loop quickly compensates for upstream pressure variations to maintain the commanded flow rate; the outer loop slowly adjusts the commanded flow rate to maintain the level. Two PID instructions in series.
Inputs & Outputs
INPUTS
F8:10 — Level PV (% full)
F8:11 — Level SP (60 %)
F8:20 — Flow PV (litres/min, scaled from flow meter)
OUTPUTS
F8:15 — Outer (level) CV → also Flow SP for inner loop
F8:25 — Inner (flow) CV → valve position 0–100%
PD9:0 — Outer level PID block (slow, low gain)
PD9:1 — Inner flow PID block (fast, high gain)
Why cascade is better than a single loop on level alone
- Without cascade, the level loop tries to hold level by directly commanding the valve. When upstream pressure drops, the valve sends less flow, the level falls, the loop opens the valve — but with delay, because level is a slow integrator of flow. The level loop never gets timely feedback that its flow command isn’t being honoured.
- With cascade, the inner flow loop sees the pressure drop immediately (as a flow drop), and opens the valve to compensate before the level even moves. The outer level loop never has to know that anything happened. Disturbance rejection is dramatically faster.
Ladder Diagram (Two Rungs — One Per PID)
Two PID instructions stacked. The outer (level) loop’s CV (F8:15) is the inner (flow) loop’s SP. Notice the gain difference: outer loop is slow and gentle (Kp=0.5, Ti=120s) because level is a slow integrator; inner loop is fast and aggressive (Kp=2.0, Ti=10s) because flow responds quickly to valve changes. Inner must be at least 5× faster than outer for cascade to be stable.
The cascade tuning rule — inner first, outer second
Get the order wrong and the system will oscillate forever.
- Tune the inner loop first. Set the outer loop to manual, manually drive its CV (the inner SP), and tune the inner loop until it tracks setpoint changes cleanly.
- Then tune the outer loop with the inner already tuned. The outer loop sees the inner as part of “the process” — make sure inner is fast and stable before you start playing with outer gains.
- Inner must be at least 5× faster than outer. If the inner loop’s settling time isn’t significantly faster than the outer’s, the cascade structure offers no benefit and may go unstable.
- Watch for inner saturation. When the outer CV demands more flow than the valve can deliver (valve at 100 %), the inner can’t track, the outer thinks “more please”, outer integral winds up — when conditions normalise, severe overshoot. Use anti-windup feedback from the inner to the outer.
The problem: an operator changes the temperature setpoint from 60 °C to 90 °C with a single click on the SCADA screen. The PID sees a 30 °C step error and responds aggressively — drives the steam valve to 100 %, the temperature overshoots to 95 °C, integral term winds up, the loop oscillates for several minutes before settling. The fix: don’t let the PID see a step change in setpoint. Instead, generate a ramped setpoint that smoothly interpolates from the current value to the new commanded value over many seconds. The PID sees only a slow drift, responds gently, and the process tracks cleanly.
Inputs & Outputs
INPUTS
F8:30 — Target SP (operator/SCADA writes this)
F8:31 — Ramp rate (°C/second; e.g. 0.5)
T4:5 — Periodic timer that ticks every 100 ms
OUTPUTS
F8:32 — Working SP (sent to PID — this is what changes slowly)
F8:33 — Per-tick ramp step = ramp_rate × 0.1 sec
The pattern
- Operator writes new target to F8:30 (e.g. 90.0).
- Working SP F8:32 currently equals 60.0 (the previous target).
- Every 100 ms (driven by T4:5/DN), the ramp logic compares F8:32 to F8:30.
- If F8:32 < F8:30, add the per-tick step:
F8:32 := F8:32 + F8:33. - If F8:32 > F8:30, subtract the per-tick step:
F8:32 := F8:32 − F8:33. - If they’re within one step’s worth, snap to target:
F8:32 := F8:30.
- If F8:32 < F8:30, add the per-tick step:
- The PID’s setpoint input is F8:32, not F8:30. The PID sees a smooth ramp from 60 to 90 over 60 seconds (at 0.5 °C/s × 60 s = 30 °C). No step, no overshoot, no integral windup.
Ladder Diagram (Three Rungs)
Three rungs. Rung 0 ramps F8:32 up toward target when below. Rung 1 ramps it down when above. Rung 2 snaps F8:32 to target when within one step’s distance, preventing endless jitter at ±half-step around the target. The PID instruction (not shown) reads F8:32 as its SP — never the operator’s raw F8:30.
The problem: a stepper-driven indexer must move a part to one of three preset positions (Position 1 = 50 mm, Position 2 = 150 mm, Position 3 = 280 mm) on operator command. The drive accepts a 0–10 V analog velocity command (with sign for direction); the encoder feedback is in mm. We’ll implement a simple proportional position controller: velocity = Kp × position_error, with limits. When error is large, drive at full speed; as error shrinks, decelerate; when error is within tolerance, stop. This is the building block of every motion controller.
Inputs & Outputs
INPUTS
I:1/0..2 — Position select buttons (1, 2, 3)
F8:40 — Encoder feedback (current position, mm)
F8:41..43 — Preset positions (50, 150, 280 mm)
F8:44 — Position gain Kp (e.g. 50.0 mm/s per mm error)
F8:45 — Max velocity (mm/s, e.g. 200)
F8:46 — In-position tolerance (mm, e.g. 0.5)
OUTPUTS
F8:50 — Target position (selected)
F8:51 — Position error = target − current
F8:52 — Velocity command (mm/s, signed)
O:5 — Analog output to drive (−10 to +10 V)
O:2/0 — In-position lamp
The control law
| Step | Calculation |
|---|---|
| 1. Select target | If button 1 pressed → F8:50 := F8:41 (50 mm). Same for 2, 3. |
| 2. Compute error | F8:51 := F8:50 − F8:40 (target − current) |
| 3. Compute velocity | F8:52 := F8:51 × F8:44 (error × Kp) |
| 4. Limit velocity | If |F8:52| > F8:45, clamp to ±F8:45 (max velocity) |
| 5. Stop when in tolerance | If |F8:51| < F8:46, set F8:52 := 0 and light O:2/0 |
| 6. Send to drive | Scale F8:52 to ±10 V analog output O:5 |
Ladder Diagram (Selected Rungs)
Selected rungs from a longer program. Rung 1 selects the target preset on button press. Rung 4 computes position error and proportional velocity. Rung 6 zeros the velocity and lights the in-position lamp when within tolerance. Velocity-clamping rungs (between 4 and 6) and the analog scaling rung (after 6) complete the program but are omitted here for clarity.
A walk-through of one move from 80 mm to Position 2 (150 mm)
| Time (s) | Position (F8:40) | Error (F8:51) | Velocity command (F8:52) | State |
|---|---|---|---|---|
| 0.0 | 80.0 | +70.0 | +200 (clamped to max) | Full speed forward |
| 0.5 | 180.0 | −30.0 | −200 (clamped, too far!) | Reversed direction (overshoot) |
Wait — that table reveals a problem. With pure proportional control and no deceleration profile, the indexer overshoots because the velocity is constant at maximum until error suddenly flips sign. Real motion controllers solve this with velocity profiling: a controlled deceleration ramp that begins early enough to bring velocity to zero exactly at the target. The simple proportional law shown here works for slow systems with low inertia; high-speed motion always wants a profiled deceleration.
When proportional position control is enough — and when it isn’t
The simple “velocity = Kp × error” law is enough for systems where the actuator can decelerate quickly relative to the inertia of what’s moving — small servos, light loads, slow speeds. It overshoots and oscillates for systems with significant inertia at high velocity, because by the time the controller commands zero velocity, momentum carries the load past the target. Real motion controllers add a deceleration profile: they precompute the deceleration distance from the current velocity and the maximum decel rate, and start ramping velocity down before reaching the target. This is the difference between Worked Example 5’s simplified pedagogical version and a Studio 5000 motion-axis MAJ instruction in production.
The problem: a Coriolis flow meter is installed on a pipe 50 m from the panel. The meter speaks Modbus RTU over RS-485 at 9600 baud. We need to read the meter’s “instantaneous flow rate” register every second, scale it into engineering units, and make it available to the rest of the program for control and SCADA. The instrument is Modbus slave address 17; the flow value is at holding register 40005 (a 32-bit IEEE float spread across two consecutive registers).
Inputs & Outputs
NETWORK
RS-485 channel: PLC’s Channel 0 in Modbus RTU master mode
Slave address: 17
Function code: 03 (Read Holding Registers)
Starting register: 40005
Quantity: 2 registers (32-bit IEEE float)
LOCAL
N7:200..201 — Raw Modbus response (2 words = 32 bits)
F8:60 — Decoded float: flow rate in L/min
MG10:0 — Modbus message control block
T4:6 — 1-second poll timer
Ladder Diagram (Three Rungs)
Three rungs. The 1-second timer ticks the poll request; the MSG fires only when the previous message has finished (XIO of the EN bit guards against pile-up); the COP instruction reinterprets the 2-word raw response as a single 32-bit IEEE float. Modbus byte-order may need swapping (some vendors send big-endian, some little-endian) — most platforms have a “Modbus byte order” toggle in the channel configuration.
Modbus is everywhere — and almost embarrassingly simple
Modbus’s whole specification fits in 30 pages. There are 8 standard function codes (read coils, read inputs, read holding registers, write single coil, write single register, write multiple, read/write multiple, mask write); the request and response messages are 8 bytes plus payload; the CRC is a 16-bit polynomial that’s been used since 1979. This radical simplicity is exactly why Modbus has outlived every clever competitor. Every PLC speaks it. Every drive speaks it. Every meter speaks it. When in doubt, Modbus your way out.
The problem: two ControlLogix processors run side-by-side on the plant’s EtherNet/IP backbone — PLC-A controls the packaging line, PLC-B controls the upstream filler. Every 500 ms, PLC-A needs the filler’s current production count from PLC-B’s ProductionCount tag so it can stay synchronised with upstream output. The MSG instruction handles this peer-to-peer read with a single rung. Unlike Modbus’s register-number addressing, EtherNet/IP uses tag names directly — far more readable, and resilient to memory-map changes on the target.
Inputs & Outputs
NETWORK
Channel: PLC-A’s Ethernet port (Channel 1)
Target IP: 192.168.1.20 (PLC-B)
Target slot: 0 (processor in slot 0)
Target tag: ProductionCount (DINT)
Update rate: 500 ms via T4:7
LOCAL (PLC-A)
UpstreamCount — local DINT receiving the value
UpstreamCount_MSG — MESSAGE control structure
UpstreamComm_OK — communication health bit
T4:7 — 500 ms poll timer
Why MSG — and why it’s so different from Modbus
- Tag-based addressing. Instead of “read register 40005 of slave 17”, you say “read the tag named
ProductionCountfrom the processor at 192.168.1.20, slot 0″. If PLC-B’s programmer reorganises memory tomorrow, your MSG still works — the tag name is a contract between the two programmers, not a memory address. - Native datatypes. The MSG transfers a DINT as a DINT, a REAL as a REAL, a UDT as a UDT. No byte-order surprises, no manual reinterpretation. The destination just shows up correctly.
- CIP under the hood. EtherNet/IP layers the Common Industrial Protocol on top of standard Ethernet. CIP gives you object-oriented services (read tag, write tag, read assembly, etc.) that are richer than Modbus’s eight function codes.
- Standard Ethernet hardware. Any managed switch, any laptop on the network can sniff packets, and the IT department’s tooling all works.
Ladder Diagram (Three Rungs)
Three rungs. The 500 ms timer paces the polling. The MSG fires only when the previous one has finished (XIO of EN — the message-pile-up guard). The third rung publishes a health bit: ON when the last MSG completed (DN) without error (XIO ER), OFF otherwise. SCADA reads UpstreamComm_OK to indicate “online” status with a green/red icon on the screen.
Read the CIP path one element at a time
The MSG path “1, 192.168.1.20, 1, 0” reads as: “From this processor’s port 1 (the Ethernet card), to IP 192.168.1.20, then through that processor’s port 1 (its backplane), to slot 0 (the destination processor in the chassis).” CIP paths can be longer for multi-hop messages — bridging through ControlNet to ControlLogix, for example. The path is a tour through the network from your processor to the target processor. Once you internalise that mental model, configuring the MSG path becomes mechanical.
The problem: a vessel’s pressure must never exceed 10 bar. We need an alarm bit that (a) goes ON the moment pressure exceeds 10 bar, (b) stays ON even after pressure drops back below 10 bar (so the operator can see what happened), (c) clears only when both the condition is gone and the operator has clicked “ACK” on the SCADA screen, and (d) publishes a timestamp the moment the alarm first fires (so SCADA can show “Alarm at 14:32:07”). This is the classic latched alarm with publish-and-acknowledge pattern — the foundation of every well-engineered SCADA alarm system.
Inputs & Outputs
INPUTS
F8:80 — PV: vessel pressure (bar)
F8:81 — Alarm threshold (10.0 bar)
B3:11/0 — ACK from HMI/SCADA (operator clicked Acknowledge)
S:6 — System time-of-day (writable to SCADA)
OUTPUTS
B3:10/0 — Alarm latch (the SCADA-published alarm bit)
B3:12/0 — Alarm “new” flag (one-scan pulse on first detection)
N7:300..303 — Alarm timestamp (HH:MM:SS captured at first fire)
O:2/0 — Local audible alarm (siren)
The four-rung pattern
- Rung 0 — Latch the alarm. When PV exceeds threshold AND alarm not already latched, OTL B3:10/0. The “not already latched” guard makes the latch one-shot, so the timestamp rung (next) only fires once per alarm event.
- Rung 1 — Capture timestamp. When alarm just latched (one-scan B3:12/0 pulse), COP the system time-of-day registers into N7:300..303. SCADA reads these to display the alarm time.
- Rung 2 — Clear the alarm. When pressure has dropped back below threshold AND the operator has clicked ACK, OTU B3:10/0 and OTU B3:11/0 (also clear the ACK bit so it’s ready for next time).
- Rung 3 — Drive the local siren. While alarm is latched (B3:10/0 ON), drive the local audible siren. Many designs add a second condition that lets the operator silence the siren via a separate button while leaving the visual alarm latched.
Ladder Diagram (Four Rungs)
Four rungs implementing the canonical SCADA alarm pattern. Rung 0 latches the alarm and pulses the “new alarm” flag through a one-shot. Rung 1 captures the system timestamp into N7:300..303 the instant the alarm fires. Rung 2 clears both the alarm and the ACK bit when pressure has returned and the operator has acknowledged. Rung 3 drives a local siren while latched. SCADA polls B3:10/0 (alarm state), N7:300..303 (alarm time), and writes B3:11/0 when the operator clicks Acknowledge.
Three orderings of the truth table that all fail subtly
Get the alarm-clear logic wrong and the operator loses trust in the system.
- “Clear on ACK alone.” Operator can ACK while the dangerous condition is still present, and the alarm vanishes from the screen even though pressure is still over limit. The alarm must require condition-gone AND ACK to clear.
- “Clear when condition gone alone.” Pressure spikes briefly then returns to normal; the alarm flickers ON for one scan and is gone before anyone sees it. The operator never knows it happened. Latching is what guarantees the operator gets to see the event.
- “Don’t clear the ACK bit when alarm clears.” Next time the alarm fires, ACK is already TRUE from the last event, so condition-gone alone is enough to clear it again — which collapses behaviour back to the failure mode above. Clear the ACK bit alongside the alarm so each new alarm requires its own acknowledge.
Active, Ack, Time, etc.) so SCADA can drop one alarm faceplate against the structure and bind to dozens of instances. The pattern stays the same; only the indexing changes.
Common Mistakes
The traps that catch process-control and networking engineers
- On/off control without a deadband. The contactor chatters thousands of times per minute, destroys itself, and floods the panel with electrical noise. Always add hysteresis — even a small deadband (±0.1 °C) makes a vast difference.
- Tuning Kp too aggressively. The PV oscillates around the setpoint and never settles. Symptoms: rhythmic ±5 % swings forever. Fix: halve Kp until it stops oscillating, then bring it back up gently.
- Leaving derivative action on in a noisy loop. D differentiates the noise, not just the signal — CV jumps wildly, valve slams open and shut. Default Kd to zero; only add D if the loop genuinely needs anticipatory action and you’ve filtered the PV signal.
- Allowing the integral to wind up. When the actuator saturates (valve fully open or closed), the integral keeps accumulating despite the CV being clamped. When conditions normalise, severe overshoot. Fix: enable anti-windup in the PID block (most vendors expose this as a configuration bit).
- Tuning cascade loops in the wrong order. Tuning the outer loop first while the inner is sloppy is a recipe for a system that oscillates forever. Inner loop first, with outer in manual. Then outer.
- Operator-driven step changes in setpoint. The PID sees a 30 °C step error, slams the valve, the process overshoots violently. Always feed PID through a setpoint ramp (Worked Example 4) so the loop sees only smooth setpoint motion.
- Modbus byte-order swap. A 32-bit float arrives as nonsense (huge or tiny values that don’t make physical sense). The two 16-bit words are arranged differently than the device sent them. Most platforms have a “byte/word swap” toggle in the channel configuration — try the four combinations until the value matches reality.
- MSG instructions piling up. Triggering an MSG every scan without checking that the previous one finished overflows the comm buffer and crashes communications. Always gate the MSG with XIO of its EN bit so a new message can’t fire until the previous one is done.
- Reverse vs direct acting confusion. A heating loop configured direct-acting closes the valve when temperature drops — exactly backwards. Reverse-acting for processes where “more PV” needs “less CV” (heating, level fill); direct-acting for the opposite (cooling, level drain).
- SCADA alarms that clear on condition-gone alone. Brief excursions flash ON for a scan and vanish before the operator sees them. Latch the alarm bit, require operator ACK to clear it. The whole point of an alarm system is that the operator sees what happened.
Quick Recap
The takeaways from Chapter 14
- Three process families. Continuous (refineries, power plants → PID), batch (brewery, pharmaceutical → sequencer + PID per step), discrete (assembly lines → logic + motion + tracking). Real plants mix all three.
- Open-loop applies and hopes; closed-loop measures and corrects. The feedback path is the difference between wishing and controlling.
- On/off control needs a deadband. Two thresholds (lower = SP − DB/2, upper = SP + DB/2). Latch ON below lower, unlatch above upper, leave alone in between. Wider DB = less wear, more PV variation.
- PID = P + I + D. P responds to present error, I removes the steady-state offset that pure-P leaves behind, D anticipates rapid changes. Most loops do fine with just P and I; default D to zero.
- Cascade puts a fast inner loop inside a slow outer loop. Outer’s CV becomes inner’s SP. Inner rejects disturbances at the actuator before they reach the outer process variable. Tune inner first, outer second; inner must be 5× faster than outer.
- Setpoint ramp protects PID from step changes. Operator writes target; ramp logic walks working SP toward target at a defined rate; PID reads working SP only. No more violent overshoot on operator-initiated SP changes.
- Motion control basics. Velocity proportional to position error, with limits and an in-position tolerance. Real motion adds deceleration profiling, S-curve smoothing, feedforward, and dedicated hardware.
- The three-tier industrial network hierarchy. Information (high bandwidth, slow), Control (deterministic, peer-to-peer), Device (fast, small messages, sensor-level).
- Modbus is the universal industrial language. Stupendously simple, ubiquitous since 1979, supported by every device that matters. RTU over RS-485, TCP over Ethernet. Master polls slaves; slaves never volunteer.
- EtherNet/IP is the modern dominant Rockwell protocol. Tag-based addressing, native datatypes, standard Ethernet hardware. PROFINET is the Siemens equivalent. Bet on Ethernet for new installations.
- SCADA stacks on top of PLC tags. Group tags into structures, latch alarms with publish-and-acknowledge semantics, provide raw and engineering values, throttle update rates by deadband.
- The historian is often the most-valuable SCADA asset. Time-series database of every tag change with timestamps. Engineers come back to it again and again to answer questions that would otherwise be unanswerable.
Review Questions
Test Your Understanding
Click any question to reveal the answer. Twelve questions covering process families, control structures, PID, cascade, motion, networks, and SCADA alarm patterns.
1Distinguish continuous, batch, and discrete processes with one industrial example each, and name the dominant control technique for each family.+
Continuous: petroleum refinery — material flows steadily, PID is dominant. Batch: brewery — recipe-driven sequence of steps, sequencer plus PID per step. Discrete: bottling line — countable identical items, logic plus motion plus part tracking. Real plants are usually mixtures of all three (continuous utilities, batch cooking, discrete packaging).
2What single feature distinguishes open-loop from closed-loop control, and why does its absence matter?+
The feedback path from sensor back to controller. Without it, the controller applies an action and has no way of knowing whether the action achieved its intent — disturbances are uncompensated, and the system can’t self-correct. Open-loop is fine for highly predictable processes; closed-loop is necessary whenever disturbances matter. The price of closed-loop is added complexity (sensor, signal conditioning, controller tuning) and the possibility of instability.
3Why does on/off control require a deadband (hysteresis), and what trade-off does the deadband width represent?+
Without a deadband, the actuator chatters thousands of times per minute as the PV fluctuates around the setpoint — destroying contactors, wasting energy, generating noise. The deadband uses two thresholds (typically SP ± DB/2) so the controller is “lazy” near the setpoint. The trade-off: wider deadband → less actuator wear, more PV variation; narrower deadband → tighter PV control, more wear. Choose based on the process’s tolerance to variation.
4In a PID loop, what is each term contributing? Why is integral usually necessary even though proportional alone seems intuitive?+
P contributes correction proportional to the present error — but as error shrinks, so does the correction, so pure P leaves a steady-state offset (called droop). I integrates the error over time, so even a small persistent offset eventually builds enough integral correction to close to zero error. Without I, the PV approaches but never reaches the setpoint. D anticipates rapid changes (proportional to rate of error change) — useful for fast disturbance response, but amplifies noise; often left at zero for noisy signals.
5A temperature loop is responding sluggishly — it takes 10 minutes to reach setpoint. Walk through how you’d diagnose and fix the tuning, in order.+
First check whether integral action is enabled — pure P with low gain produces exactly this slow approach. If Ki is zero, add some (start with Ti = 30 s). If integral is on but the response is still slow, increase Kp (try doubling); watch for oscillation. If oscillation appears, you’ve gone too far — back off to half. If the loop oscillates at lower Kp than expected, check whether derivative is amplifying noise on the PV signal; turn D off (Kd = 0). Iterate Kp/Ti until response is brisk without oscillation.
6Explain how a cascade control structure works and why it improves disturbance rejection. What’s the cardinal rule for tuning order?+
Cascade nests a fast inner loop inside a slow outer loop. The outer loop’s CV becomes the inner loop’s SP. The inner loop sees disturbances at the actuator (e.g. supply pressure variations affecting flow) immediately and corrects them before they propagate into the outer process variable. Disturbance rejection is dramatically faster than a single loop. Cardinal rule: tune the inner loop first with the outer loop in manual; only when the inner is fast and stable, tune the outer. Inner must be at least 5× faster than outer for cascade to be worthwhile.
7Why does a step change in setpoint cause overshoot in a PID loop, and how does a setpoint ramp eliminate the problem?+
A step change in setpoint produces a sudden large error, which the proportional term immediately translates into a large CV — slamming the actuator. The integral term then accumulates rapidly and may wind up while the actuator saturates, leading to violent overshoot when the PV finally catches up. A setpoint ramp generator interpolates a working setpoint smoothly from current value to target value at a defined rate; the PID sees only a slow drift, responds gently, and the process tracks cleanly without overshoot. Operator writes target; ramp walks working SP; PID reads working SP only.
8In Worked Example 5’s simple proportional position controller, why does the indexer overshoot at high speeds, and what do real motion controllers add to fix it?+
With pure proportional control, velocity is constant at the maximum (clamped) until error suddenly flips sign — by which time momentum has carried the load past the target. The fix is a deceleration profile: precompute the deceleration distance from current velocity and maximum decel rate, and start ramping velocity down before reaching the target. Real motion controllers add velocity profiling (trapezoidal or S-curve), feedforward terms, and high-speed encoder feedback in dedicated hardware. The proportional kernel shown in Example 5 is the heart of motion control; production systems wrap it in profile generation.
9Describe the three-tier industrial network hierarchy. Where does each tier sit in terms of speed vs bandwidth?+
Information tier at the top: SCADA, MES, ERP, historians. Standard Ethernet, OPC UA, MQTT. High bandwidth (100+ Mbit), high latency tolerance (1 second is fine). Control tier in the middle: PLC-to-PLC peer messages, ControlNet, EtherNet/IP, DH+. Deterministic, scan-rate latency (~10 ms), peer-to-peer. Device tier at the bottom: PLC-to-instrument and PLC-to-drive. DeviceNet, PROFIBUS-DP, Modbus RTU, AS-i. Very fast (~1 ms), small messages, sensor/actuator level. As you go up the tiers, latency relaxes but bandwidth grows; as you go down, the opposite.
10Compare Modbus RTU and EtherNet/IP — what makes each the right choice for different applications?+
Modbus RTU: ridiculously simple, ubiquitous, runs over RS-485, master/slave, register-based addressing. Right choice when you need to talk to a wide variety of third-party devices (meters, drives, instruments) cheaply. EtherNet/IP: tag-based addressing, native datatypes, standard Ethernet hardware, peer-to-peer with CIP services. Right choice for new Rockwell installations, peer-to-peer between ControlLogix processors, integration with IT systems. Modbus for “talk to anything”; EtherNet/IP for “talk to Rockwell with rich datatypes”. The trend industry-wide is toward Ethernet-based protocols (EtherNet/IP, PROFINET, Modbus TCP) for new installations.
11What does it mean for an alarm to “publish-and-acknowledge”, and what failure modes does this pattern protect against?+
Publish: PLC latches an alarm bit when the condition is true and exposes that bit (plus a timestamp captured at first detection) for SCADA to read. Acknowledge: SCADA writes a separate ACK bit when the operator clicks the Acknowledge button; the alarm clears only when both the condition is gone and ACK has been received. This protects against (a) brief excursions that flash on for one scan and vanish unseen, (b) operators dismissing alarms while the dangerous condition is still present, and (c) loss of audit trail (the timestamp records exactly when each alarm fired).
12A SCADA system polls 5,000 tags every second from a single PLC and the network is overloaded. Without changing hardware, what design changes can you make to the PLC program to reduce SCADA load?+
Several techniques: (1) Group related tags into structures (UDTs) so SCADA can read one structured tag instead of dozens of individual atomic tags — fewer requests for the same data. (2) Use deadband-based update suppression — only publish a value when it changes by more than a configured threshold; static tags consume no bandwidth. (3) Categorise tags by update rate — fast-changing analog values at 1 Hz, status bits at 5 Hz, configuration values at 0.1 Hz. (4) For peer-to-peer between PLCs, prefer Produced/Consumed tags over repeated MSGs — the network handles the optimisation automatically. (5) Use a historian to absorb historical queries, so SCADA isn’t the only source of past data. The PLC itself doesn’t change; the SCADA-facing tag organisation does.
Building or troubleshooting a process control or SCADA system?
If you have a PID loop that won’t tune, a Modbus/EtherNet/IP integration that won’t talk, a cascade structure that’s oscillating, or a SCADA architecture you’d like a second pair of eyes on — happy to help.