Christipher Barnes Engineering Systems

Project Detail

Decanter Control System

An industrial control-architecture case study focused on layered C# system design, multi-drive Modbus TCP integration, operator clarity, and fault recovery that remains understandable under real operating conditions.

Industrial Controls C# Architecture Modbus TCP VFD Coordination Fault Handling

Control Profile

HMI

System Class

Industrial operator-facing control platform for coordinated process equipment

Architecture Boundary

UI shell, control engine, communications services, and diagnostics layers kept intentionally separate

Operating Goal

Make machine state, command effect, and fault response understandable to operators and maintainers

System Overview

A layered control platform built for machine legibility and controlled recovery

This system is more than an HMI shell around a few device registers. It is the coordination boundary between operator intent, state-machine behavior, multi-drive VFD integration, device communications, alarms, and the evidence needed to diagnose the machine when something goes wrong. That matters because decanter-oriented equipment becomes difficult to operate and support as soon as state ownership turns ambiguous.

  • What it is A structured control application for decanter-oriented equipment where the HMI, control engine, communications services, and diagnostics model all reflect the same machine story.
  • Why it matters Industrial HMIs often fail when screens expose values without explaining state, sequence, consequence, or why a command is being rejected.
  • Core engineering problem The challenge is to coordinate bowl, scroll, and feed-side behavior while keeping drive integration, polling ownership, alarms, and recovery logic reviewable.
  • Design center The software should stay understandable during commissioning, degraded communications, trip recovery, and later device expansion rather than only during ideal runtime.

Runtime ownership from HMI to coordinated drive feedback

01 HMI Layer commands, alarms, and diagnostics access
02 Control Engine modes, interlocks, profiles, and command validity
03 Comms Service Modbus polls, timeouts, reconnects, and write guards
04 Device Layer typed speed, torque, current, ready, and trip signals
05 Drive Set bowl, scroll, feed drives, permissives, runtime feedback

Ownership flow: HMI → Control Engine → Comms Service → Device Layer → Drive Set

Figure 1 — Runtime ownership from operator interface through coordinated drive feedback.

Technical Scope

Subsystem boundaries, operating signals, and deployment realities

The scope is intentionally broad enough to support real machine behavior, but structured so each concern can be reasoned about independently during implementation and troubleshooting.

UI Surface

Overview screens, command surfaces, profile selection, alarm visibility, and one-step access to diagnostics

Control Engine

Mode handling, start and stop sequencing, interlocks, derived machine state, and protective transitions

Communication Layer

Modbus TCP polling, write guards, VFD feedback normalization, timeout detection, and quality-state tracking

Process Signals

Differential speed, current and torque feedback, readiness state, alarm conditions, and profile-dependent limits

Diagnostics Model

Alarm aggregation, stale-data visibility, device health context, and fault history useful during service work

Deployment Context

Industrial hardware variation, network instability, commissioning constraints, and equipment expansion

System Architecture

Layered software structure instead of screen-driven device control

The defining architecture decision is explicit ownership. The HMI does not own direct register reads, the control engine does not parse raw device maps, and the diagnostics layer does not guess at machine consequence after the fact. Those boundaries keep VFD integration, state-machine behavior, polling ownership, and service reasoning understandable as the system grows.

Layer Model

Responsibilities are assigned to layers that can evolve without collapsing together

  • HMI layer Presents machine state, command availability, profile context, and alarms without becoming the place where device behavior is decided.
  • Control engine Owns modes, state transitions, startup or shutdown sequencing, interlocks, and the derived machine state exposed to the operator.
  • Communications service Owns poll groups, read cadence, write discipline, timeout behavior, reconnect handling, and the difference between fresh and stale data.
  • Device abstraction layer Converts bowl, scroll, feed, and sensor integration into typed engineering signals instead of leaking vendor register detail upward.
  • Diagnostics / alarm layer Aggregates consequence, severity, chronology, and recovery requirements so machine faults, communication faults, and command conflicts stay distinguishable.

Architecture Review

Boundaries that keep multi-drive behavior reviewable

Command Path Operator requests become validated control actions first; only approved actions cross into device-write behavior.
Polling Ownership One communications service owns poll cadence, timeout budgets, freshness state, and reconnect behavior for the full device set.
VFD Integration Bowl, scroll, and feed-drive feedback are normalized into ready, running, speed, torque, current, and trip signals that the control engine can trust.
State-Machine Behavior Startup, acceleration, steady-state operation, upset handling, safe-stop, and recovery transitions are modeled above protocol detail.
Diagnostics Ownership The alarm model preserves source, consequence, chronology, and recovery guidance instead of treating faults as flat text.

Layer 01

HMI Layer

Shows readiness, active mode, profile context, blockers, alarms, and command availability without forcing operators to interpret raw device words.

Layer 02

Control Engine

Accepts operator intent, validates it against state and interlocks, and turns it into controlled transitions instead of immediate device-side writes.

Layer 03

Communications Service

Owns Modbus TCP sessions, grouped polling, stale-data handling, and write gating so device access remains deterministic under load.

Layer 04

Device Abstraction

Normalizes VFD and sensor detail into engineering signals so higher layers consume meaning rather than register maps.

Layer 05

Diagnostics / Alarm Layer

Preserves chronology, severity, recovery rules, and communication-quality evidence so service work starts from traceable system behavior.

Industrial Communication

Modbus TCP as a disciplined integration boundary, not just a register list

Industrial communications become fragile when raw register access leaks into every part of the application. The better pattern is to treat communications as a service boundary with explicit poll ownership, grouped runtime reads, guarded writes, normalized VFD feedback, and quality-state handling that prevents stale data from masquerading as healthy machine behavior.

Communication Strategy

Polling, feedback interpretation, and write behavior need predictable rules

  • Group by operational importance Fast-changing drive-state, speed, current, and trip signals deserve different poll cadence than configuration values or static metadata.
  • Keep the UI out of raw polling Operator screens should consume state published by the communications service rather than issuing direct device reads of their own.
  • Separate reads from writes Operator requests and control-engine decisions should flow through validated write guards instead of ad hoc register writes from the HMI.
  • Normalize VFD feedback and communication quality together Current, torque, speed, ready state, fault state, timeouts, and stale reads all need typed meaning before the rest of the system can reason about them.

Communication Rules

Practical considerations that matter in the field

Fast Poll Group Runtime drive-state, speed, current, torque, and trip-condition signals deserve the most responsive cadence because they affect machine-state interpretation directly.
Slow Poll Group Configuration values, noncritical diagnostics, and static metadata can be read more conservatively to preserve bandwidth and reviewability.
VFD Integration Command words, ready state, current, torque, actual speed, and fault codes need to be interpreted as one device contract rather than isolated registers.
Reliability Handling Timeout budgets, retry policy, stale-data marking, reconnect logic, and inhibited writes during degraded communications prevent false confidence.
Diagnostics Exposure Communication health belongs on the HMI and in service diagnostics so operators can separate process trouble from network trouble.

Operator Interface Philosophy

Operator clarity is a control concern, not a cosmetic one

Industrial HMIs often fail by forcing operators to infer machine state from scattered values, unclear modes, and alarms that read like internal PLC or drive terminology. The interface should shorten that interpretation gap, not widen it.

Design Principles

The screen model should match the machine model

  • Overview before detail Operators should first see whether the machine is ready, running, faulted, or waiting on a condition before they ever need to inspect lower-level values.
  • State visibility before parameter density More numbers do not create clarity if the operator still cannot tell which subsystem is blocking progress.
  • Command availability tied to context Start, stop, reset, and profile actions should reflect real state and interlock conditions rather than always appearing equally available.
  • Diagnostics close to the operating surface Service information should be one step away from the primary view, not buried behind a separate mental model.

Failure Patterns To Avoid

Why many industrial HMIs create confusion

Hidden State Operators should not have to infer mode, readiness, or sequence position from secondary values.
Alarm Without Context An alarm should indicate source, effect, and the practical meaning of the condition, not just expose an internal code.
Diagnostics As A Separate World The service view should complement the operator view, not feel like a different application with different terminology.
Cognitive Load When the machine is already under stress, the interface should narrow the next decision instead of multiplying possibilities.

Diagnostics And Fault Handling

Fault behavior should be observable, classifiable, and recoverable

Good fault handling is not just about stopping the machine. It is about preserving enough context that the operator knows what happened and the maintainer can understand why. That requires a structured alarm model instead of a flat list of messages fired directly from low-level events.

Fault Strategy

Alarm aggregation needs hierarchy, machine-state context, and recovery boundaries

  • Separate source from consequence Faults can originate from drive status, communications degradation, process thresholds, invalid sequence states, or blocked operator commands, but the alarm layer still has to express what each one means operationally.
  • Use machine state as context A drive trip during acceleration, a stale-data condition during steady run, and a blocked start command while stopped should not be surfaced as interchangeable problems.
  • Preserve chronology The order of warnings, transitions, communication loss, and escalation often matters as much as the final alarm itself.
  • Handle communication loss explicitly Stale data should invalidate dependent conclusions, inhibit risky commands, and surface which subsystem can no longer be trusted.
  • Design for recoverability The path back to service should be intentional, with explicit reset eligibility and enough visibility to avoid blind restarts.

Fault Model

What the diagnostics layer is responsible for

Alarm Aggregation Rolls low-level events into operator-relevant alarm states without losing the drive, sensor, or communication detail needed for service work.
State Awareness Records whether a condition occurred during startup, acceleration, steady operation, fault recovery, or maintenance activity.
Visibility Keeps machine state, active blockers, communication quality, and recent event history visible enough that troubleshooting starts from evidence rather than memory.
Recovery Boundary Supports acknowledgement, reset eligibility, and controlled return-to-service behavior instead of leaving recovery as an improvised operator sequence.

Fault recovery path with reset and restart gating

01 Fault Detected drive, process, communication, or interlock condition
02 Safe State collapse unsafe commands and stabilize machine context
03 Classify Source drive fault, stale data, interlock, or command conflict
04 Review Context machine state, chronology, and device evidence
05 Reset Eligible? condition cleared, interlocks satisfied, and communications trustworthy
06 Restart Permitted? machine-level permission after controlled recovery review

Recovery flow: Fault → Safe State → Classify → Review → Reset Eligibility → Restart Permission

If reset eligibility or restart permissives fail, hold the machine in a protected state until the blocking condition, stale-data issue, or unresolved drive fault is actually cleared.
Restart Inhibited lockout, unresolved root cause, or unsafe machine context remains active
Figure 2 — Fault recovery path with reset eligibility and restart permission gates.

Operational Engineering

Degraded communications, restart safety, and commissioning pressure all shape the design

The architecture is judged under abnormal conditions as much as under normal runtime. The useful question is not whether the machine runs when everything is healthy, but whether the control platform still tells the truth when data goes stale, devices trip, interlocks drop, or the system is being commissioned one boundary at a time.

Degraded Communications And Restart Safety

Recovery logic starts by refusing to trust ambiguous machine state

  • Stale data is not healthy data When communication freshness is lost, the system should mark the affected device state as degraded instead of allowing the last received values to continue impersonating current truth.
  • Uncertain device state should inhibit writes Resets, restarts, and profile-changing commands should not proceed when drive readiness or communication quality is uncertain.
  • Restart permission is machine-level, not drive-local A single VFD may clear its own trip while the broader machine still lacks interlocks, safe-state confirmation, or operator acknowledgement.
  • Operators need explicit blocked-state language The HMI should show whether recovery is waiting on a fault clear, communication restoration, safety condition, or command-sequence prerequisite.

Commissioning And Service

Operational visibility has to survive startup, tuning, and later expansion

Commissioning Poll groups, scaling, device readiness, state transitions, and recovery boundaries should be proven in stages before the full machine sequence is trusted.
Diagnostics Visibility Timestamps, counters, active blockers, and quality flags reduce guesswork when startup or recovery behavior does not match expectations.
Maintainability Clean layer boundaries make it easier to determine whether a problem is device-side, network-side, or control-side during later service work.
Scaling Additional sensors, auxiliary pumps, conveyors, or alternate drive packages should be absorbed through adapters and configuration rather than HMI rewrites.

Process Control Philosophy

Control logic should express machine relationships, not just expose setpoints

Decanter process equipment is typically governed by relationships between subsystems rather than isolated numbers. The operator needs a controllable process model, not a raw bucket of device parameters. That means profile structure, monitored signals, and protective logic should reflect how the machine actually responds.

Control Model

Differential speed, load feedback, and profile structure

  • Differential speed as a relationship The control problem is not a single numeric setpoint. It is the relationship between rotating elements and process conditions as loading changes.
  • Coordinated drive behavior Bowl, scroll, and feed-drive behavior need to be interpreted as one machine relationship rather than three unrelated devices operating in parallel.
  • Current and torque as operational signals Drive feedback is useful not only for protection, but for understanding process loading, upset conditions, and whether the machine is approaching limits.
  • Configurable profiles Known-good operating modes, ramp behavior, and threshold sets should be configurable so the application can support multiple process contexts without code churn.
  • Protected flexibility Operators may need range and responsiveness, but adjustments should still pass through interlocks, ramp limits, and sanity checks tied to actual machine state.

Operational Reasoning

Signals and behaviors worth treating explicitly

Profile Parameters Speed relationships, ramp timing, threshold values, and permissive conditions should be grouped as coherent operating profiles.
Drive Coordination Bowl speed, scroll differential, feed behavior, and any associated permissives need one machine-level coordination model instead of separate screen-side adjustments.
Observed Signals Current, torque, ready state, fault state, and runtime trends help the operator see process response before a hard trip occurs.
Protective Logic Commands should be bounded by interlocks, device readiness, and any process conditions that make an action unsafe or misleading.
Operational Flexibility The architecture should support tuning and profile variation without turning every commissioning adjustment into a code change.

Implementation And Commissioning Methodology

Build the machine model first, then prove it under staged field conditions

A control system like this becomes difficult to maintain when screens, device access, and sequencing logic grow together without boundaries. A more durable approach is to define the machine model first, keep communications behind typed services, instrument diagnostics early, and commission the layers in a deliberate order instead of discovering ownership problems under production pressure.

Step 01

Define the machine state model

Identify modes, permissives, interlocks, fault classes, and the derived states the operator actually needs to reason about.

Step 02

Abstract device communication

Build typed adapters around Modbus TCP so the rest of the system works with machine signals instead of scattered register addresses.

Step 03

Implement sequencing through a coordinator

Route operator commands through one control boundary that validates readiness, applies profiles, and handles transitions consistently.

Step 04

Instrument diagnostics early

Add alarm context, communication health, and event chronology before commissioning pressure pushes them into an afterthought.

Step 05

Commission by layer

Prove device communication, scaling, state transitions, interlocks, and restart boundaries in stages so later problems can be traced to a known architectural boundary.

Engineering Constraints And Tradeoffs

Field-ready control software is built by managing competing priorities explicitly

Industrial deployment changes the definition of a good application. The software has to survive noisy networks, imperfect startup conditions, hardware variation, and later service work by someone who did not author the original code. That means the architecture is shaped by explicit tradeoffs rather than abstract software elegance alone.

Tradeoff Set

The hardest design decisions sit between goals that all matter

  • Polling rate versus bandwidth Faster updates improve perceived responsiveness, but uncontrolled polling consumes bandwidth quickly and makes timeout behavior harder to interpret.
  • UI responsiveness versus determinism Operators need a responsive surface, but it should still consume published machine state rather than bypassing the control model for faster-looking reads or writes.
  • Fault sensitivity versus nuisance alarms Protective behavior matters, but oversensitive thresholds and unstable alarm handling can erode trust and encourage blind resets.
  • Abstraction flexibility versus complexity Rich device abstraction supports future hardware changes, but abstraction that outruns the real device set can make troubleshooting harder instead of easier.
  • Diagnostics depth versus operator overload The system should preserve rich evidence for engineering review without forcing operators to work through low-level details during routine runtime decisions.

Design Responses

How those tradeoffs show up in implementation

Poll Group Design Machine-critical signals are prioritized while slower configuration and static data are separated so bandwidth is spent where it changes control quality.
Command Discipline The HMI stays responsive by consuming state and sending intent, while the control engine and communications service keep device-side behavior deterministic.
Alarm Model Severity, machine-state context, debounce, and communication-quality handling reduce nuisance alarms without hiding real risk.
Abstraction Boundary Vendor-specific detail is isolated far enough to support future hardware variation without creating a second opaque system inside the adapters.
Service Visibility Operators see consequence and next action first, while maintainers can still reach the deeper diagnostics, counters, and device detail needed for repair.

System Evolution Strategy

Expand the platform by extending evidence, configuration, and device boundaries

The next generation of value should come from better evidence retention, cleaner expansion boundaries, and more reviewable operational judgment. Useful additions are the ones that strengthen deterministic local control instead of replacing it with opaque automation.

Path 01

Additional device integration

Bring in auxiliary pumps, sensors, conveyors, or alternate drive packages through typed adapters and configuration boundaries rather than through HMI-side exceptions.

Path 02

Configuration-driven behavior

Expand profiles, threshold sets, and device maps in a way that stays validated and reviewable rather than letting new commissioning needs become code-side shortcuts.

Path 03

Historical diagnostics retention

Persist state transitions, alarm chronology, communication-quality changes, and runtime evidence so recurring trouble can be reviewed with historical context instead of memory.

Path 04

AI-assisted diagnostics review

Use evidence-aware analysis to highlight likely fault paths, repeated communication issues, or profile-response patterns while keeping final engineering judgment with the maintainer or controls engineer.

Path 05

Remote engineering visibility

Expose secure observational views of state, alarms, device health, and trends so support staff can review machine behavior without undermining local control ownership.

Path 06

Structured reporting and archive exports

Package alarm history, device health, configuration context, and runtime snapshots into records that support escalation, service handoff, and long-term engineering traceability.

Reference Material

Architecture, alarms, HMI, and diagnostics references

These reference panels present representative operating visuals tied to the reasoning above: HMI states, layered architecture diagrams, alarm-sequence views, and diagnostics captures tied to actual machine behavior.

Reference Surface

HMI state and mode screens

Capture
Decanter control HMI showing equipment state, active mode, runtime status, and operator controls.

Representative HMI view showing machine state, mode, and command availability.

Diagram Reference

Layered control architecture maps

Diagram
Layered control architecture diagram showing operator, control-engine, diagnostics, and device communication boundaries for the decanter system.

Layered control-architecture map showing software boundaries and system responsibilities.

Alarm Reference

Alarm and recovery flow maps

Alarm
Alarm handling flow map for the decanter control system showing fault states, operator notification, and recovery paths.

Alarm and fault-recovery workflow showing classification, notification, and return-to-service logic.

Diagnostics Reference

Diagnostics traces and device feedback

Logs
Diagnostics view showing decanter system status traces, drive feedback, communication health, and fault context.

Diagnostics evidence tied to runtime behavior, VFD feedback, and communication quality.

Connected Work

Adjacent case studies, publication series, and exploratory engineering work

The Decanter Control System sits inside a broader set of architecture-led case studies, controls references, and engineering exploration around analytics, tooling, and complex technical systems.

Related Case Study

AI PCB Designer

Another architecture-led system where rule interpretation, explainability, and maintainable separation of concerns matter more than automation theater.

View case study

Publication Index

Technical Articles

The controls series, PCB review series, and diagnostics methodology articles provide the reusable engineering context behind this case study.

Browse technical articles

Related Research Route

Engineering Lab

Analytics, remote monitoring concepts, and control-tooling studies fit naturally into the exploratory work collected in the lab.

Browse engineering lab

Related Engineering References

Technical articles that turn this case study into a reusable controls methodology hub

These controls references now split into three useful clusters: the runtime and operator-facing architecture that explains how the system is built, the decanter process-control strategy articles that explain how the machine stabilizes itself under load, and the retained-evidence plus integration-boundary articles that explain how that behavior is reviewed later and exposed responsibly beyond the local screen.

Controls Cluster 01

Runtime architecture, communications legitimacy, and operator visibility

These articles explain how state ownership, fail-safe communications, HMI visibility, and layer boundaries support the applied runtime model used by the decanter platform.

Runtime State Article

Deterministic State Machines for Industrial Equipment Control

Clarifies how explicit runtime states, blocked-action logic, and recovery-state ownership keep the machine understandable during startup, heavy load, and shutdown.

Read full article

Watchdog Article

Communication Watchdogs and Fail-Safe Design for Modbus Control Systems

Explains how heartbeat validation, stale-data handling, degraded-state legitimacy, and restart gating support safe multi-drive operation.

Read full article

HMI Article

Industrial HMI Design for Operator Visibility and Recovery State

Extends the case study into visible runtime state, active recovery explanation, diagnostics truthfulness, and confidence-preserving operator interaction.

Read full article

Architecture Article

Layered Architecture for Industrial Control Software

Clarifies why the HMI, control engine, polling layer, and diagnostics model need separate ownership in this kind of system.

Read full article

Controls Cluster 02

Applied decanter process-control strategy

These articles explain how the decanter stabilizes solids transport under load through differential authority, torque-limiting recovery, and coordinated feed behavior.

Process Strategy Article

Differential-Speed Strategy in Decanter Centrifuge Control

Explains why differential speed is the main operational transport variable and how it connects torque rise, feed behavior, and recovery margin.

Read full article

Recovery Strategy Article

Torque-Limiting Recovery Design for Solids-Handling Decanters

Shows how warning-level heavy-load behavior, staged mitigation, dwell periods, and shutdown escalation are organized as one deterministic protection path.

Read full article

Feed Strategy Article

Feed-Control Strategy and Solids-Transport Stability in Decanter Systems

Explains why inflow authority is a stabilization mechanism, how feed reduction supports recovery, and why restoration timing needs explicit runtime ownership.

Read full article

Controls Cluster 03

Retained review evidence, plant boundaries, and remote visibility

These articles explain how the decanter behavior stays reviewable after the event, how ancillary readiness and plant permissives interact with the machine, and how diagnostics visibility can extend beyond the local HMI without weakening local authority.

Diagnostics Review Article

Structured Trend Views and Runtime Statistics in Industrial HMIs

Closes the loop with retained trends, runtime counters, alarm history, and engineering review surfaces that explain what the machine actually did under load.

Read full article

Retention Article

Process Logging and Alarm History Retention in Industrial Control Systems

Extends the case study into retained alarm chronology, operator actions, communication-aware evidence, and the review workflows that make transient events supportable later.

Read full article

Integration Boundary Article

Plant Interlocks and Supervisory Integration Boundaries

Explains how ancillary readiness, plant permissives, and future supervisory requests can narrow machine authority without bypassing the local state model.

Read full article

Observability Article

Remote Observability for Industrial Control Platforms

Shows how retained alarms, trends, snapshots, and maintenance evidence can support remote diagnostics visibility while keeping deterministic local authority on the machine.

Read full article
Browse technical articles Back to Projects