Automation & drive: the paper machine's "nerve" and "joint"

I. DCS / QCS architecture

The paper machine's "brain" has two layers: DCS (Distributed Control System) manages plant-wide process control (stock preparation, wire section, press, dryer, finishing), QCS (Quality Control System) manages sheet quality (scanner measures moisture, basis weight, thickness, ash, and feeds back to adjust headbox lip, steam, calender). The two exchange data via a communication bus; QCS setpoints come from DCS process targets.

The communication bus is an easily underestimated vulnerability: fieldbuses such as Profibus/Profinet/Modbus/Ethernet/IP, once they drop packets or lose termination resistors, show as "a section intermittently loses link, speed jumps". For troubleshooting, first check the bus status lights and error rate, then termination resistors and grounding — far more useful than blindly swapping cards.

From an O&M perspective, DCS/QCS is not a "black box" but a decomposable object: control cabinet (power, CPU, communication), field IO station, sensors, actuators, HMI and configuration software. Any "control anomaly" should first be located to which of the four layers, rather than vaguely saying "the system is broken".

II. Drive sections and speed chain

A paper machine consists of dozens of drive sections (wire section, each press, each dryer group, carrier rolls, size press, calender, reel, rewinder), each driven by one or more motors through VFDs/drive cabinets. They must maintain a strict speed ratio, otherwise the sheet is stretched or folded.

The core of the speed chain is "reference section + relative speed ratio": one section is the reference, the rest follow at set ratios. Speed-ratio drift shows as abnormal sheet tension, wrinkles, web breaks. Load sharing in the drive cabinet (multiple motors sharing torque proportionally when driving one roll) also relies on this mechanism. Modern drives synchronize each section's encoder via fiber or bus, with millisecond-level sync accuracy; once communication jitters, the inter-section speed ratio instantly mismatches and the sheet wrinkles immediately.

Empirical criterion: speed-ratio drift beyond 0.1% — first check encoders (dirty, loose, broken wire) and communication; multi-motor load sharing imbalance beyond 10% — check mechanical jam (bearing, lubrication) not the motor itself. After roll change or overhaul, the first speed-up must verify each section's speed-ratio setting matches the nameplate.

III. Web-break detection and auto-slowdown

Web break is the most common "unplanned event" on a paper machine. Detection relies on photoelectric/ultrasonic/scanner sensing of sheet presence at key positions; once a break is detected, the system automatically executes a slowdown or emergency-stop sequence: first slow to protect equipment, then stop related sections, interlock stock and vacuum, reducing scrap and re-ramp time.

Pitfalls of web-break detection: false alarm (water vapor, lint interference) → innocent slowdown; missed alarm → break not isolated in time, broke accumulates. Maintenance points: sensor window cleanliness, mounting angle, signal filter parameters, and interlock-logic testing with DCS (periodic "simulated break" drill).

Auto-slowdown settings must be graded: minor breaks (e.g., small dry-end break) only slow without stopping, aiming to rejoin without rupture; only severe breaks emergency-stop. Logic written too "sensitive" causes frequent false slowdowns (lost capacity), too "sluggish" enlarges broke. This threshold must be tuned by grade and machine speed, not set once and forever.

IV. How to read the IO list

The field IO list (or IO table) is the O&M "map": each signal has tag number, type (AI/AO/DI/DO), range, terminal, loop drawing number. Three steps to read: ① reverse-look-up the alarm tag in the list to determine its signal type; ② read range and unit to judge what process extreme "full scale" corresponds to; ③ follow the terminal to the field sensor and confirm power and loop.

Signal-type quick notes: AI analog input (4–20 mA temperature/pressure/flow, 0–10 V), AO analog output (to valve positioner), DI digital input (interlock/status), DO digital output (start-stop/alarm). A 4–20 mA "broken wire" shows as signal dropping below 3.8 mA or going full-scale, which must be distinguished from a process extreme. Two-wire transmitters are loop-powered; losing one 24 V supply disables the whole segment.

V. Control loop tuning (PID)

Many paper-machine loops are PID control (steam pressure, level, consistency, dryer temperature). Three tuning parameters: P proportional (response speed, too large oscillates), I integral (eliminates steady-state error, too large overshoots), D derivative (suppresses rate of change, too sensitive to noise). Randomly tuning parameters is worse than not tuning.

A practical tuning discipline: first stabilize the loop in manual mode, record the step response (apply a setpoint change, observe output behavior), then set P/I/D by the critical-ratio method or empirical formula. Any parameter change must keep a "old value + reason + date" record — many loops were tuned by several engineers; no record means no one is accountable. Steam-pressure loops with too-large P oscillate, too-small I leave large offset; level loops fear too-large I causing frequent pump start-stop.

VI. Network security and backup

Industrial control systems are increasingly networked, but the paper-machine control network must never connect directly to the office network / internet. Baseline protection: physical/logical isolation of controllers and configuration machines, USB control (many viruses enter via configuration-machine USB), tiered operation permissions (engineer/operator/visitor), all configuration changes via approval and version management.

The most fatal is not hackers but "changed without backup, backup not verified". Configuration, recipes, and parameter tables must be backed up offline regularly, and a recovery drill performed periodically — backing up without drilling equals no backup (when truly needed the backup is corrupt or incomplete). Recommend three backups: local, remote, offline media, and verify recoverability at least quarterly.

VII. Maintenance points and criteria

• Daily: review the alarm list; check new alarms and "in-service rate" (how many loops are auto, how many forced manual).
• Weekly: spot-check trends of key loops (steam pressure, dryer temperature); see if oscillating or long-term manual.
• Monthly: random calibration check of sensors (especially pressure and flow used for trade / critical control).
• Quarterly: IO cabinet dusting, terminal tightening, UPS discharge test, bus status and termination-resistor check.
• Each change: keep a record (old/new value / reason / date), and do a recovery-drill backup after the change.

VIII. Linkage with other Part-B lectures

Automation is not isolated: press line-pressure "setpoint" comes from DCS and is executed by M07's hydraulics; hood damper opening command comes from DCS and is executed by M08's fans and valves; web-break detection interlocks the whole line's drive and stock. So the three Part-B lectures (hydraulics & pneumatics, air & ventilation, automation & drive) together form the "utility systems" — they do not directly make paper, but any one failing stops the line immediately. These three are also the "cross-grade base" for the later Part-C grade volumes: grade differences in utility systems are far smaller than differences in wet-end and dry-end equipment forms.

IX. Availability design and redundancy

Modern paper-machine control and drive are generally designed for "high availability": critical drives use redundant power and controllers, the control network is a ring (one break doesn't affect the whole chain), control cabinets have UPS to preserve state on power loss, engineer stations are dual hot-standby. Two availability metrics are MTBF (mean time between failures, longer is better) and MTTR (mean time to repair, shorter is better) — availability = MTBF / (MTBF + MTTR). Redundancy mainly lengthens MTBF, but what truly compresses MTTR is "switchover drill" and "spare parts on hand".

The O&M misconception about redundancy is "set and forget". The opposite is true: once a redundant configuration is changed without authorization (e.g., pointing both primary and backup to the same power supply for convenience), it creates a single point; and if switchover is never drilled, it often fails at the real fault. Three iron rules for O&M: never change redundancy config without authorization, periodically drill primary/backup switchover, UPS discharge test quarterly. Redundancy is not "maintenance-free"; switchover testing is its maintenance.

X. Change management and knowledge management of the control system

Control-system degradation is mostly not hardware failure but the accumulation of "countless small changes": someone changed a PID parameter without a record, a maintenance mixed up an IO terminal, a config upgrade left old loops unreviewed. Three defenses against degradation: change control — configuration/recipe/parameter changes go through approval + version + offline backup; parameter trail — any number change records "old/new value / reason / date"; knowledge retention — who tuned it and why written into loop comments, not only in someone's head.

This is of the same line as the maintenance methodology of M01: control anomalies also need RCFA (root-cause analysis), and their root cause is nine times out of ten at the terminal sensor/actuator and IO wiring, not in control logic. Listing "number of manually-run loops", "alarm repeat rate", "number of unclosed changes" as control-system health indicators warns earlier than "any big fault today". The essence of control-system health is "traceable, reproducible, take-over-able".

XI. Control commissioning sequence at start-up

At start-up of a new machine or after a major overhaul, control system commissioning follows a sequence; out-of-order commissioning leads to "full-screen alarms as soon as it runs". Standard order: first calibrate sensors (point-by-point compare IO list with field true values, confirm range and unit) → then commission single loops (each PID first manual-stabilized, then auto, confirm no oscillation) → then commission the speed chain (attach section by section from the reference, confirm speed ratio) → finally commission interlocks and auto-slowdown (web break, limit, emergency stop tested before enabling). Each step has "test → confirm → sign-off"; no skipping.

The essence of this order is "from terminal to top, from local to global". First ensure every sensor reads right, then every loop is stable, finally let them interlock — the reverse (interlock first, local later) amplifies any bad point globally. After a major overhaul it is especially easy to make the "eager to make paper" mistake: skip sensor calibration and go straight to auto, resulting in "auto" built on wrong readings, the more auto the worse. The first 72 hours after commissioning are the critical observation window: record all "forced-manual" loops, all alarms, all speed-ratio fine-tunes — these are the system's "birth record".

When performance degrades later, comparing with this record immediately distinguishes "always like this" from "recently worsened". Many machines run a year before someone wonders why a loop is often manual, and searching records finds it was manual from day one — the root cause was never fixed, just undocumented.

XII. 10-minute checklist for control anomalies

For control-related downtime or quality anomalies, follow the four-layer order "terminal → IO → controller → HMI" for troubleshooting; initial judgment is usually done within 10 minutes without waiting for an expert. Minute 1 check terminal: sensor power and signal, whether actuator moves; minutes 2–4 check IO station: terminal tightness, indicator status, bus error rate; minutes 5–7 check controller: loop in-service status, alarm list, any loop forced manual; only then HMI and communication. Experience: the vast majority are solved in the first two layers; rarely does controller logic need touching.

The discipline of this checklist is "no blind restart, no blind parameter change". The two most impulsive actions during a control anomaly — restarting the controller, changing PID parameters — precisely mask the true cause: restart hides intermittent faults temporarily, parameter change compensates the deviation, returning next time in a more hidden way. The correct approach: first freeze the scene (record alarms and trend curves), locate by layer, fix the terminal, verify, then restore auto. After fixing, backfill this anomaly into the "birth record", compare with the start-up record, distinguishing "always like this" from "recently worsened".

The underlying logic of this checklist matches the RCFA of M01 — locate the layer before talking repair, not "try restart". Control-system faults are rarely the controller miscalculating; overwhelmingly they are "signal didn't arrive" or "command didn't execute", so terminal and IO are the real battlefield. Classify and record each anomaly by these four layers; after half a year you can see which layer is weak and reinforce it in advance, instead of forever firefighting. The maturity mark of a control system is not "never fails" but "faults always appear in the same repairable layer, and handling time keeps shrinking".

Putting this troubleshooting discipline into daily practice, the hardest part is not technology but habit. Restarting the controller in the control room takes ten seconds; layer-by-layer troubleshooting takes ten minutes; in an emergency people instinctively pick the fast one. But the fast one resolves the immediate alarm, the slow one resolves the true root cause, and the difference shows only after half a year: machines with consistent layered troubleshooting see clearly lower recurrence of the same fault; machines that restart on every incident see the same problem recur in different guises. So half the value of this checklist is the technical plan, half is execution discipline. It demands making "first freeze the scene, then locate by layer, then backfill the record after fixing" into muscle memory, not panicking from scratch each time. A truly mature O&M team's fault-handling time keeps shrinking, not because equipment improves, but because every handling reinforces the system's diagnosability. When every anomaly of a paper machine can be quickly classified to a definite layer and resolved with a definite action, it truly moves from "human firefighting" to "system self-healing".

XIII. Mnemonics for this lecture

The pitfall of automation is not "miscalculation" but "signal didn't arrive, command didn't execute". Remember the four-layer order for fault location; it beats restart:

• Terminal → IO → controller → HMI; 80% of problems in the first two layers.
• Speed-ratio drift beyond 0.1% → check encoder; imbalance beyond 10% → check mechanical jam.
• 4–20 mA dropping below 3.8 or hitting full scale is mostly a broken wire; don't treat it as a process extreme.
• The count of "forced-manual" loops is the true health indicator, more honest than the alarm count.
• Three configuration backups, one drill per quarter; backup without drill equals no backup.
• Any parameter change must keep old value, reason, date; don't let loops survive on someone's feel.

Summary: the maturity mark of a control system is not "never fails" but "faults always appear in the same repairable layer, and handling time keeps shrinking". Classify each anomaly by the four layers and backfill the start-up record; after half a year you can see which layer is weak and reinforce it in advance, instead of forever firefighting. This is of the same line as the RCFA of M01 — locate the layer before talking repair, not "try restart".