Part 0 — The Whole Thing From Zero (read this first)

This part assumes you know nothing about the plant, the software, or the technology. By the end of it you'll understand what the plant makes, how it makes it, what the old system was, what Ring is, and — most importantly — the handful of sentences you must phrase carefully so a knowledgeable person in the room can't poke a hole in them. Everything after Part 0 explains the individual features; this part is the ground you stand on while doing it.

0.1 The whole story in one breath

The plant mixes industrial glue. It has run for ~20 years on a 2002-era operator screen called RS-360 that does the job but is blind and forgetful — it keeps no usable history, knows nothing about cost, shows cryptic alarm codes, and is spread across ~97 screens. We built Ring, a modern operator screen that runs on the same controller (we did not touch the machine that physically runs the plant) and closes those gaps: one command-center screen, a permanent searchable history, an owner cost view, plain-language alarms, and 13 operator languages. It already ran live on the real plant controller in a read-only mode and read every value correctly. That's the whole pitch; the rest is detail.

0.2 What the plant actually makes

The plant is a corrugating-adhesive kitchen — it makes the starch-based glue that holds corrugated cardboard together. (Corrugated board is the wavy-middle, flat-outside material that boxes are made of; the wavy layer is glued to the flat layers.) The glue is mixed from a few raw ingredients — starch, water, caustic (sodium hydroxide), and borax — in heated, stirred tanks, following a recipe. It is not food; nobody eats it. That matters because it changes which concerns are real: there is no food-safety or recall regime to satisfy, but the consistency of the glue (its thickness, or "viscosity") is the critical quality spec — too thin or too thick and the cardboard plant downstream has problems.

One honest technical note worth knowing before someone asks: the controller does not have a viscosity sensor wired in. So Ring cannot show a live viscosity number — it shows temperature, tank levels, and ingredient amounts, which are the things the controller actually measures. If anyone asks "does it read viscosity?", the answer is "the controller doesn't expose a viscometer signal, so neither system can; that was scoped out deliberately."

0.3 The physical process, from zero

A few plain-language terms you'll use all meeting:

• Tank — a vessel that holds liquid. This plant has 13 in service: one mix tank (where glue is made), six storage tanks (where finished glue waits to be used), and six doser/feed tanks (that meter ingredients in). The old system and an early version of Ring only showed a subset; the real plant runs all 13.
• Ingredient — a raw material added to the mix (starch, water, caustic, borax, steam for heat, etc.). Each ingredient addition is one step in the recipe.
• Recipe / formula — the ordered list of steps that makes one product: "add this much water, heat to this temperature, add this much starch, stir this long," and so on. The plant mostly runs default-named formulas; only one ("SF 1") is custom-named.
• Batch — one production run of one recipe. It is the plant's core unit of work. A batch has a start, a sequence of steps, and an end, and it produces a tank of glue. The plant has made roughly 1,404 batches of recorded history.
• Step / operation — one instruction inside a recipe, identified inside the controller by a numeric op-code (e.g. a code that means "add starch" or "turn the agitator on"). The old system showed operators these raw numbers; Ring translates them into words.
• Agitator — the motorized paddle that stirs a tank. Turning it on/off is itself a recipe step the controller sequences.

So a normal shift is: pick a recipe, start a batch, the controller runs the steps (open valves, dose ingredients, heat, stir) while the operator watches, and at the end you have a tank of glue and a record of what happened. Ring is the window the operator watches and controls that through — it is not the thing opening the valves.

0.4 The single most important distinction: the controller (PLC) vs. the operator screen (HMI)

If you remember one thing, remember this, because half the tough questions hinge on it:

• The PLC (Programmable Logic Controller) is the rugged industrial computer bolted in the plant that physically runs everything — it opens valves, starts pumps, drives the mixer, and enforces safety interlocks. Here it's an Allen-Bradley CompactLogix (model 1769-L36ERM). It runs its own control program. Ring does not replace it, change it, or reprogram it.
• The HMI (Human-Machine Interface) is the screen software an operator uses to see what the PLC is doing and send it requests ("start this batch," "put this on hold"). RS-360 is the old HMI. Ring is the new HMI. Replacing the HMI is like replacing a car's dashboard, gauges, and logbook while keeping the engine, transmission, and brakes exactly as they are.

The analogy to use out loud: "We kept the engine and replaced the dashboard." The engine (PLC) is proven and untouched; the dashboard (HMI) is what we modernized.

Why this matters for the meeting: every time someone worries "is this risky to the running plant?", the honest answer traces back to here — Ring is a screen on top of an unchanged controller, and during the live trial it was running in a read-only mode that suppresses every command to the controller (more on that in 0.7).

0.5 The old system (RS-360) and its four real gaps

RS-360 is a DOS-era application written in 2002 in Borland C++ (an obsolete toolset). It is not broken — it still runs the plant today — but it has four gaps that quietly cost money and time every shift. Ring exists to close all four:

1. It forgets. It has no usable, surviving on-screen memory — no continuous trend charts, no record of how long each step took, no shift summaries, no equipment-runtime history, no "best batch to compare against." Whatever scrolled off the screen was gone. (Careful phrasing — see 0.8: the legacy did keep some history in database files; what it lacked was a usable, living historian and trends. Don't say "it records nothing.")
2. It can't see cost. It never computed or kept a single number about money — not what a batch cost, not where ingredients were over-dosed (paid-for product given away), not what a scrapped batch or an hour of hold time was worth.
3. Its alarms are cryptic. When something went wrong, operators often saw a bare numeric code (in some cases a placeholder with no description at all) and had to decode it from a printed legend, mid-fault, under pressure.
4. It's hard to run. The plant is spread across ~97 separate screens, and the operator has to already know the map — which screen fixes which problem and how to get there. A new hire could take months to get fluent, so the plant leaned on a few veterans.

Underneath all four sits a fifth, structural problem: RS-360 runs on dead 2002 tools no one can support or hire for, and its data lives in an abandoned database format (Paradox/BDE) with no maintained driver. That's the "why now" — the risk grows every year the platform ages.

0.6 What Ring is (and what it deliberately doesn't change)

Ring is a modern Windows control-room application (built on current Microsoft .NET/WPF technology) that gives operators one screen to run the whole plant, keeps a permanent, searchable, exportable record of everything it makes, and turns plant data into decisions and dollars — all on the same untouched Allen-Bradley controller.

What Ring does not change, on purpose:

• It does not replace or reprogram the PLC.
• It does not change the physics, the recipes the controller runs, or the safety interlocks.
• During the live trial it did not send the controller a single command — it only read.

That "we changed the screen, not the controls" boundary is not a limitation to apologize for; it's the reason the upgrade is low-risk. You modernize the part operators touch, while the proven control logic keeps running.

0.7 How Ring talks to the controller — and the "read-only safety gate"

Two facts here defuse most safety questions:

• Modern, open connection. Ring talks to the controller over EtherNet/IP — a standard, open industrial protocol — using an open library, asking for values by name. The old system reached the controller through bespoke Borland helper components that have to be kept alive. Ring's path is the supportable, modern one, and it ships with on-screen diagnostics so the floor can see the connection's health without specialist tools.
• Read-only cutover gate. Ring ships with a setting (ReadOnlyMode = true) that suppresses every write to the controller. In that mode Ring can watch the live plant for as long as you like — days, weeks — and prove itself next to the old system without ever being able to change the process. Writes are turned on later, deliberately, only when you choose to go live. This is the single most reassuring thing you can say about risk.

When we say it "ran live on the real plant," we mean: plugged into the actual production controller, in read-only mode, and it read all 133 of the controller's live values correctly — proof it works on your real hardware, not just a demo. (Phrase this as "without issuing a single command that could change the process," not "without sending a single byte" — see 0.8.)

0.8 The five claims you must phrase carefully (this is your armor)

These are places where the short marketing wording is technically vulnerable. A controls engineer who knows the legacy could challenge them. Use the right-hand "say this" version and you're bulletproof; these are corrected against the plant's own data and code.

#	The risky wording	Why it's vulnerable	Say this instead
1	"The old system records nothing durable."	The legacy did keep history in database files — batch headers (1,404), step rows (16,776), shift and alarm records. A buyer can open those files.	"The legacy kept records locked in a dead, corruption-prone format with no living historian, no trends, no cost, no best-batch comparison, and no step-timing timeline. Ring keeps the same history usable, searchable, and exportable."
2	"Read the plant without sending a single byte."	Reading values over the network does send request packets; an engineer could see them on a network trace.	"Read all 133 values live without issuing a single command that could change the process — every write is suppressed by the read-only gate."
3	"0 bytes to the controller."	Same as #2 — it's about commands, not bytes.	"Zero write commands sent under the read-only safety gate."
4	Legacy "split batching wrote ambiguous indices."	That ambiguous-index issue was a Ring bug we found and fixed — not legacy behavior. The legacy actually supported splitting (the plant just never used it).	Don't attribute it to legacy. Say: "We found and fixed an internal split-batch addressing bug during our own review; it's pending a controls-engineer sign-off before live split batching."
5	"~70–80% parity" / "verified on-site."	The parity number is ~80% from a source-code audit (June 18); the on-site event was the separate live-PLC read. Mixing them invites "which is it?"	"~80% feature parity-or-better, per an engineering code audit; separately, we verified 133/133 live reads on-site on the real controller."

Two more numbers to keep honest:

• Tests: say "2,400+ automated tests, zero failures, on a zero-warning build" rather than quoting an exact count like 2,416 — the number moves with every build, and a stale exact figure looks wrong.
• "87 features": that's the count of distinct capabilities in our inventory across five themes. It's a fair headline; if pressed, it breaks down into the chapters that follow, and a portion are honestly labeled in-progress or roadmap (we never hide that).

0.9 How the rest of this document works

The remaining chapters walk through every one of the 87 capabilities, grouped into the themes below. For each feature you get the same five-part treatment, always in plain language:

1. What it is — explained as if you've never seen the screen.
2. Why it matters — the real problem on the floor it removes.
3. How it works — the mechanism, in plain terms (no jargon left undefined).
4. Versus the old RS-360 system — the honest before/after.
5. Status & honest caveats — is it live, in-progress, or roadmap; is it on a real screen or built-but-not-yet-wired; and anything you must be ready to defend.

…and then the part you specifically asked for:

6. Likely questions & how to answer them — the pointed questions a skeptical owner, controls engineer, or operator could ask, each with a crisp answer you can say out loud.

The five themes (and the chapters that carry them):

• Make or save money — the owner cost view, waste/giveaway, best-batch comparison, predictive drift. (Chapter: Turn Plant Memory Into Money.)
• Stay ahead of problems — live trends, tank time-to-empty, run-dry and equipment-drift warnings. (Chapters: Insight + Command Center.)
• Easier for operators — one command-center screen, guided batch start, the floor & onboarding tools, languages. (Chapters: Command Center, Run a Batch, On the Floor.)
• Smarter alarms — plain-language alarms, severity at a glance, first-response playbook, alarm-to-batch links. (Chapter: Faster, Safer Fault Triage.)
• Own your data — a modern open database, one-click export, the automatic historian, reliable connection, and the honest "why now." (Chapters: Own Your Data, Reliability, Why Now, Where the Work Stands.)

A glossary and a master "hardest questions" appendix sit at the very end. You can read cover to cover, or jump to a chapter from the contents.

Feature Status Scorecard — All 87 at a Glance

14 of 87 carry a “phrase carefully” flag; the other 73 are solid to state plainly.

Every feature, with the status confirmed by reading the source. ⚠ = phrase carefully (there is a per-feature "Watch-out" in its chapter). Everything else is solid to state plainly.

Chapter 1 — Run a Whole Shift From One Screen

Feature	Verified status
Walk up and know the whole plant in one glance	Live	✓
Spot trouble from across the control room in one glance	Live	✓
Catch a stalled step before the controller alarm does	Live	✓
Never act on a frozen reading that looks live	Live	✓
One tap from the number to the screen that fixes it	Live	✓
No fake '100% done' for the last 20 minutes of a batch	Live	✓
Step away and still see what just finished	Live	✓
Catch a developing tank problem the PLC can't even alarm on	Live	✓
Make production decisions on real history, not invented numbers	Live	✓
Let the floor self-troubleshoot without opening Studio 5000	Live	✓
End false 'PLC down' calls — know an outage from an idle controller	Live	✓

Chapter 2 — Running a Batch Without the Guesswork

Feature	Verified status
Stop losing 20 years of plant knowledge to a system that forgets on restart	Roadmap	⚠
Prevent a wrong batch before it arms the plant — confirm in plain language	Live	✓
See exactly where the batch is — progress that never lies through a network hiccup	Live	✓
Keep a searchable record of every batch — even one interrupted by a reboot	Live	✓
Edit a recipe once — the database, the controller, and the audit trail stay in sync	Live	✓
Catch a drifting batch early — overlaid against your own proven good runs	Live	✓
Tie tribal knowledge to the exact batch — for the next quality investigation	Live	✓
Re-run the usual recipe in one tap — by the name operators actually call it	In progress	✓
Split a batch to the right second tank — with overfill protection that follows it	In progress	✓

Chapter 3 — Turn Plant Memory Into Money

Feature	Verified status
See your spend and stop the leaks before they cost you	Live	✓
Make faster calls with decision screens the legacy never had	Live	✓
Watch trends live and review any tank's last 30 days	Live	✓
Catch a failing pump before it scraps a batch	Live	⚠
Get every report you rely on, from one database, with PDF	Live	✓
Answer 'show me our data' in one click — you own it	Live	⚠
Never trust a frozen number: live, stale, or off-target at a glance	Live	✓
Keep a true history — automatically, with zero extra load on the controller	Live	✓

Chapter 4 — Smarter Alarms, Faster Fixes

Feature	Verified status
No translation guesswork mid-fault - alarms read exactly like the controller	Live	✓
From alarm fires to fixing it in one tap - even for a new operator	Live	✓
A green operator gets expert first-response guidance the instant a covered alarm fires	Live	✓
Triage a live critical from a resolved warning across the room - color-blind safe	Live	✓
Catch a stalled batch before it costs you - BATCH ON HOLD shown right on the hero	Live	✓
Spot the fault that's been sitting too long - live age plus an oldest active callout	Live	✓
Reserve operator attention for real criticals - E-STOP front and center, calm for warnings	Live (partial)	⚠
An accidental tap cannot disrupt a live batch - confirm before every PLC write	Live	✓
Pin downtime to the exact batch and recipe that was running	Live	✓
Honest status: today's alarms are correct; 94 legacy legend rows are a tracked seed task	In progress	✓
On a 24/7 plant box, a live fault never silently disappears	Live	✓

Chapter 5 — On the Floor & Standing Up a New Site

Feature	Verified status
Stand up a new station in minutes - no developer, no INI archaeology	Live	✓
See your own equipment names on day one - imported from RS-360 in any language	Live	✓
Never miss a comms loss or a live alarm - safety is visible on every screen	Live	✓
Cut missed-context errors between crews with durable shift handoff	Live	✓
See every tank group live, by the plant's own names	Live (partial)	⚠
Rename, reconfigure, and back up yourself - no developer, no callout fee	Live	✓
Fix faster and stay informed off-site - alarm emails with the fix steps, scheduled reports	Live	✓
Turn the HMI into an owner's management tool - cost, alarm guidance, maintenance	Live	✓
Operators read the HMI in their own language and script from day one	In progress	✓
End the 'where am I / how do I get back' confusion of a deep menu tree	Live	✓
Root-cause faster and protect your data - tag inspector, snapshot, one-button backup	Live	✓
Get hand-logged readings off paper and into reports - with your own field labels	Live (partial)	⚠
Set agitators to cycle themselves instead of managing paddles by hand	In progress	⚠
Keep operators productive through the switch - manual a click away, F1 cheat-sheet	Live	✓
A home screen shaped by what operators actually glance at every hour	In progress	⚠

Chapter 6 — Own Your Data, Platform Built to Last

Feature	Verified status
Hand an auditor every record on day one, no vendor required	Live	✓
Self-service backups, a verified restore, and Excel exports on demand	Live	✓
Keep the batch you just finished through a power blip; never freeze under load	Live (under the hood)	✓
Upgrade without a DBA, and an interrupted upgrade never corrupts your history	Live (under the hood)	✓
Inventory totals you can trust, even after a controller reset	Live (under the hood)	✓
Your tank, ingredient, and recipe names (and language) stay put forever	Live	✓
A glance-from-15-feet look that re-skins as a config swap, not a rewrite	Live	✓
Your fixes and features arrive sooner, with a contained blast radius	Live (under the hood)	✓
A screen that never freezes, and data that holds up to a security audit	Live (under the hood)	✓
Faster, cheaper support and months of unattended 24/7 uptime	Live (under the hood)	✓
No second copy fighting for the PLC, and clear guidance when one is frozen	Live (under the hood)	✓
Any .NET contractor can build it, and every release is checksum-verifiable	In progress	✓

Chapter 7 — A Reliable, Honest Connection

Feature	Verified status
Stop chasing false 'PLC is down' calls - Ring knows unplugged vs frozen vs running	Live	⚠
A command never lands in a frozen controller - writes fire only into a provably-running PLC	Live (under the hood)	✓
Operators never decide on a frozen number that looks live	Live	✓
No more morning HMI restarts - it reconnects on its own after a power blip	Live	⚠
A frozen screen can't lie to your operators - it's caught and recorded	In progress	✓
See exactly what flows to the PLC - and never depend on a 2002 Borland driver again	Live	✓
No error storms, no network overload - it rides out an outage and snaps back	Live (under the hood)	✓

Chapter 8 — Why Replace It Now

Feature	Verified status
Buy out your single point of failure before it forces your hand	Live (under the hood)	✓
Own your recipes, batch history, and alarms — instead of holding them hostage in a dead engine	Live	✓
Make changes any .NET contractor can do — not a 2002 build wired to one retiring PC	Live (under the hood)	✓
Buy bounded, shrinking risk — and stop paying for unbounded, growing risk	Live (under the hood)	✓
Verify every claim against the code before you sign	Live (under the hood)	✓

Chapter 9 — Where the Work Honestly Stands

Feature	Verified status
You go live on evidence, not optimism: an audited GO-WITH-CONDITIONS with every condition named	In progress	✓
Your engineer can audit the whole decision: a dated NO-GO to GO-WITH-CONDITIONS to live read-only GO trail	Live (under the hood)	✓
Your operators keep what they know and gain what the old system never had: ~80% audited parity, gaps named	In progress	⚠
You hear it from us first: no per-operator named-user audit trail yet, scoped to your regulatory class	In progress	⚠
You troubleshoot on the floor without Studio 5000: self-service diagnostics and one-button DB backup	Live	✓
Your operators read the screen in their language today, switchable live: 13-language engine shipped	In progress	⚠
Nothing here blocks daily work: the gated-but-built follow-ups, listed plainly	In progress	⚠
You get a precise scoping conversation up front: the questions only your team can close	Roadmap	✓
Your floor adopts the new interface now while the control-logic port is scheduled separately	Roadmap	✓

Chapter 1 — Run a Whole Shift From One Screen

Before any of the features make sense, here is the plant in one breath. A PLC (Programmable Logic Controller) is the rugged industrial computer that actually runs the glue kitchen — it opens valves, starts pumps, and drives the mixer. The PLC does the work; nobody watches a PLC directly. To see what it is doing, an operator needs a screen — an HMI (Human-Machine Interface). The old screen was RS-360, a 2002 DOS-era program written in Borland C++. Ring is the new HMI. It is a modern Windows application that talks to the exact same Allen-Bradley CompactLogix PLC — Ring replaces the screen, not the controller. The recipes, valves, and safety logic in the PLC are untouched.

One more word you'll hear: a batch is a single production run of one glue recipe — fill a tank, dose in starch and the other ingredients step by step, mix, and finish. Each batch is made of numbered steps. A tag is just a named value living inside the PLC (for example, the mix-tank temperature). A KPI is a headline number worth watching ("Key Performance Indicator").

The floor problem this chapter solves: on the old system, an operator who walked up to the screen learned almost nothing at a glance. RS-360 opened to a splash screen and was organized one screen per area of the plant — one form for this storage tank, another for that mixer, another for alarms. To answer the simple question "is the plant healthy, and what's running?" the operator had to click through several screens and assemble the picture in their head. Ring opens to one dashboard that answers that question before anyone touches anything.

Two honesty points to carry into the meeting. First, on safety: Ring shipped to the live plant with a read-only gate turned on, which suppresses every command that could change the process. On-site it read all 133 live tags it needed and never issued a single command that could move a valve. Reading does put request packets on the network (it has to ask the PLC for each value), so the precise, defensible phrase is "zero write commands," not "zero bytes." Second, on the old system: RS-360 was not a system that recorded nothing — it did keep batch, step, shift, and alarm history. The catch is that it stored them in a dead Paradox/BDE database format with no living, searchable historian, no trends, no step-durations, and no cost. So the honest contrast is "the old data was locked away and unusable," never "the old system stored nothing."

Walk up and know the whole plant in one glance

What it is

When the operator opens Ring, the entire shift picture is already on the screen: the batch that's running, an overall plant-health verdict, the four numbers that drive the next decision, any active alarms, and the tanks. Nothing has to be clicked together — it's all on one scrolling page often called a "single pane of glass."

Why it matters

A shift starts with situational awareness instead of detective work. A new hire becomes useful faster because they don't have to memorize which menu holds which fact, and a veteran runs the whole shift from one surface. Less clicking means fewer missed conditions.

How it works

The dashboard is one tall page built from stacked rows — 15 in total: a small "names not imported yet" nudge for a fresh install, plus 14 content rows (the batch hero, the four-number KPI strip, the live recipe tracker, the active-alarms panel, the tank cards, recent completed batches, and several newer value cards). It does not re-poll the PLC on its own; a coordinator simply reuses the same live data the tank and alarm screens already read, so the home view and the detail screens always agree. The page is rebuilt fresh each time you navigate to it and cleans itself up when you leave, so you never see a stale leftover.

Versus the old RS-360 system

On RS-360, building this same picture cost several screen changes — it opened to a splash and was laid out one screen per plant area, so the crew navigated form by form to piece the state together. There was no consolidated command center at all. Ring opens straight to one always-live home view.

Status & honest caveats

Likely questions & how to answer them

Spot trouble from across the control room in one glance

What it is

A large plant-health verdict sits at the top of the alarms area. It reads "All systems normal" in a calm green when nothing is wrong, and flips to a red "Attention required" the instant a real alarm goes active — readable from across the control room without walking up to the screen.

Why it matters

Plant health becomes a glance, not a chore. Just as important, the red signal stays meaningful: a list full of already-resolved historical alarms will not falsely turn the panel red, so when it does go red, it means something is wrong right now.

How it works

The header color, the verdict text, and the count badge all key off one number — the count of active alarms. Zero active means green; one or more turns it red. Crucially it watches the active count, not the length of the list, so old resolved rows sitting in the history don't tint it. When there are genuinely no active alarms, a positive overlay shows a green check and "No active alarms."

Versus the old RS-360 system

On RS-360 the operator had to open a dedicated alarm form just to learn whether anything was wrong — there was no health verdict on a home screen. Ring puts an honest, distance-readable verdict on the home screen.

Status & honest caveats

Likely questions & how to answer them

Catch a stalled step before the controller alarm does

What it is

A live recipe tracker shows exactly which step of the batch is running and how long it has taken. Finished steps get a green check with their recorded time, the current step glows gold with a live ticking timer, and upcoming steps are dimmed. If a step runs unusually long, that row turns amber as a stall warning.

Why it matters

A hung step used to be invisible until something downstream went wrong. With a live per-step timer and an amber warning, the crew can see a stall developing and step in earlier, instead of discovering a silent stall after it has already cost the batch.

How it works

The tracker is a table tied to the running batch's step list, with columns for the step glyph, number, operation, preset, actual, mix time, and duration. Coloring is automatic: complete steps muted with a check, the in-progress step gold with a live minutes:seconds timer, pending steps faded. A step turns amber when its elapsed time passes a threshold of max(2 minutes, 3× the step's expected mix time). The whole card hides when the plant is idle and auto-scrolls so the active step is always in view.

Versus the old RS-360 system

RS-360 showed the current step but gave it no elapsed timer, no recorded durations on completed steps, and no stall indicator — so a step could hang with no visual feedback at all. Ring puts a live timer and a stall threshold on every step, so a hung step shows on the dashboard.

Status & honest caveats

Likely questions & how to answer them

Never act on a frozen reading that looks live

What it is

If a hiccup in the link to the PLC stops a value from updating, Ring doesn't keep showing it as if it were current. It dims the tile and stamps when the value was last fresh ("STALE · as of 14:07:32"), so a frozen number is never mistaken for a live one.

Why it matters

The single most dangerous thing on an operator screen is a stale number that still looks live — the operator makes a decision on data that stopped minutes ago. Communication drops are a real, observed failure mode at this plant, so this guard protects against the worst-case mistake directly.

How it works

Each guarded tile knows the timestamp of the last successful read from the PLC. A converter compares that to "now"; once the reading is more than 10 seconds old, the tile fades and its tooltip flips to a "STALE · as of …" stamp. The age is computed in a clock-immune way (in UTC), so a daylight-saving change or someone setting the clock backward can't trick a frozen value into looking fresh. The big batch hero and the recipe tracker dim the same way when their data goes stale.

Versus the old RS-360 system

On RS-360, fill graphics and readouts simply froze looking live during a comms drop — no dimming, no last-fresh stamp, no way for the operator to tell. Ring stamps every guarded live tile with its last-fresh time and dims it within about 10 seconds of a drop.

Status & honest caveats

Likely questions & how to answer them

One tap from the number to the screen that fixes it

What it is

Four color-coded numbers sit across the top of the dashboard — open alarms, mix-tank temperature, batch percent done, and which tank needs attention. Each is a button: tapping it jumps straight to the screen that handles that issue, so there's no hunting through menus to act on what you just saw.

Why it matters

Decisions land faster. The four numbers that actually drive an operator's next move are always on glass and color-coded (red when bad, green when fine), and each is one tap from the screen that resolves it — no navigating to find where to act.

How it works

The KPI strip is a four-column row. Tile 1 (open alarms) goes red above zero, green at zero. Tile 2 shows the mix-tank temperature. Tile 3 shows batch percent done, weighted by how much material has actually gone in. Tile 4 points at the tank needing attention, green only when nothing is flagged. Each tile is styled as a clickable shortcut with a little chevron, and tapping it navigates to the matching detail screen.

Versus the old RS-360 system

On RS-360 these numbers, where they existed at all, were raw readouts buried on per-area forms — no consolidated strip and no way to click a number to go act on it. Ring makes them a single color-coded strip where each tile is a shortcut.

Status & honest caveats

Likely questions & how to answer them

No fake "100% done" for the last 20 minutes of a batch

What it is

At the very end of a batch there are usually final steps that aren't metered by quantity (mixing, holding, finishing). On a naïve display those make the math read 100% while the batch is still running. Ring instead shows "99%" with a "Finishing — Step N of M" label, so the headline doesn't claim the batch is done when it isn't.

Why it matters

On a real ("golden") batch we captured at the plant, the un-guarded display read "100.0% / est. < 1 min" for about 21 minutes while the operator was still working the batch (15:08 to 15:30). An operator trusting that headline would have walked away too early. Ring keeps the headline honest right where the old math was most wrong.

How it works

When the batch enters its final un-metered steps, the percent math would naturally round to 100 while steps remain. Ring detects this "finishing phase" — defined honestly as the fraction has effectively hit full but we're still sitting on a recipe step — and caps the headline at 99%, swaps in a "Finishing — Step N of M" label, and changes "Time Left" to show elapsed-in-step instead of a fake countdown. Once the batch passes its truly last step, it shows an honest 100%.

Versus the old RS-360 system

This is a fix to an early Ring display flaw as much as a legacy contrast — the un-guarded hero read 100% for roughly 21 minutes on the documented golden batch. The guard caps the headline at 99% and labels the finishing phase explicitly, so the display stays honest exactly where it was previously wrong.

Status & honest caveats

Likely questions & how to answer them

Step away and still see what just finished

What it is

When a batch completes, the result doesn't vanish. The hero holds a one-line summary — "Batch complete — Formula 1 → Storage Tank 2, 12 steps, 2h 04m, completed 15:30" — until the next batch starts or the operator dismisses it.

Why it matters

A two-hour batch used to disappear in a three-second snap the instant it ended. An operator who stepped away for a moment came back to a blank "Idle" screen with no trace of what had just run. Holding the summary means they can still see exactly what finished.

How it works

When the running step count drops to zero (the batch ended), the code captures the recipe, target tank, step count, duration, and finish time that it recorded while the batch was running, and shows them in a hold panel instead of instantly flipping to "Idle." A "Dismiss" pill clears it. The refresh is driven by the completion event itself, not a polling timer that would erase it.

Versus the old RS-360 system

RS-360 had no held completion summary on a home screen — once a batch ended there was nothing waiting on the home view. Ring holds the completed-batch summary until the next batch or an explicit dismiss.

Status & honest caveats

Likely questions & how to answer them

Catch a developing tank problem before it stops the line

What it is

The fourth KPI tile points the operator straight at the next tank needing attention — including a developing temperature-control problem. The plant's temperature-control units (the jacket-water/heater units that hold a tank at temperature, called "TVC") can have a condition like low jacket water that, in a specific situation, the controller's own alarm won't raise.

Why it matters

At the live plant we found a real gap: a TVC unit was running low while the dashboard read "all systems normal," because that condition wasn't surfaced anywhere the operator was looking. This tile routes the operator to the developing problem before it grows into a line stoppage.

How it works

The attention tile reads the same TVC input bits the TVC detail screen shows and raises a plain-language flag like "TVC 1 — jacket water LOW." The temperature-control case is ranked first; otherwise the tile points at the most urgent flagged tank's screen. Importantly, it reads the live input directly rather than waiting on the controller's alarm logic — so it can flag the condition in the specific case where the controller's own alarm can't.

Versus the old RS-360 system

Legacy operators relied on a red TVC indicator on the main navigation. An early Ring build actually hid TVC behind a screen nobody opened, so the dashboard read "normal" while TVC 1 was low at the live plant. Ring now synthesizes that low-water condition into the attention tile and routes there on tap, recovering the legacy indicator's coverage and adding one-tap navigation.

Status & honest caveats

Likely questions & how to answer them

Make production decisions on real history, not invented numbers

What it is

The trends card plots genuine completed-batch data — real dates, with an "As of HH:mm" timestamp — so supervisors read actual production numbers. If there's no history yet, it shows an honest empty state instead of fake figures.

Why it matters

A trends chart is only useful if you can trust it. Supervisors and anyone evaluating the system should be basing decisions on real production numbers, not demo placeholders dressed up to look authoritative.

How it works

The chart reads completed batches from Ring's batch database for a date range and groups them by shift or by day. Labels are real calendar dates (like "Wed 4"), never hardcoded weekday names, and an "As of HH:mm" caption stamps every refresh. If the query fails or there's no data, it degrades to an honest "no history" message rather than throwing an error or showing nothing meaningful. An earlier Ring build had filled this card with random demo numbers — those were removed entirely.

Versus the old RS-360 system

RS-360 had limited-to-no on-glass trend visualization of this kind. Its "Graph" screen was a live-value mimic — a background diagram with up-to-eight live numeric readouts — not a chart plotting values over time. Ring sources the trend from the real batch repository with a visible "As of" caption.

Status & honest caveats

Likely questions & how to answer them

Let a tech self-troubleshoot on the floor without opening Studio 5000

What it is

A set of maintenance tools built into Ring so a password-holding technician can diagnose comms problems right on the floor — without a protocol analyzer or Allen-Bradley's engineering software, Studio 5000. It includes a Tag Inspector (read any PLC value), a read-only PLC Health drawer, a Diagnostic Console showing the raw network frames, a crash-dump pipeline, and a one-tap diagnostic bundle. The operator-facing touches — a numeric keypad for gloved hands, an F1 help overlay, and a Ctrl+B "go to batch" shortcut — round it out.

Why it matters

When comms act up, the usual answer is "call someone with Studio 5000 and a laptop." These built-in tools let a qualified tech answer "is the PLC link healthy, and what is this tag reading?" in place, on the same screen the crew already uses.

How it works

Ring talks to the PLC over EtherNet/IP (an open industrial-network standard) using an open library called libplctag, addressing tags by name. Because that's a direct, standards-based link, there are no separate bridge programs to keep running. The Tag Inspector and Diagnostic Console are password-gated dialogs; the PLC Health drawer shows the last-success time and recent link-state transitions; the Diagnostic Console shows the raw transmit/receive (TX/RX) frame tail. Poller startup is staggered so the controller's limited number of simultaneous network sessions doesn't get swamped at launch.

Versus the old RS-360 system

RS-360 logged comms to disk but offered no modern instrumentation — no tag inspector, no connection-state view, no one-tap bundle — and it reached the PLC through separate bespoke Borland "bridge" programs (an ASAB/TCP exe, DH+/TCP modules) that had to be kept alive alongside it. Ring talks EtherNet/IP directly with named tags and ships first-class diagnostics, so there are no sidecar bridge processes to babysit.

Status & honest caveats

Likely questions & how to answer them

End false "PLC down" calls — know an outage from an idle controller

What it is

Ring classifies the state of its connection to the PLC into clear categories, so the team can tell the difference between a controller that is genuinely down and one that is reachable but simply not running its program (idle). That stops the crew from chasing "the PLC is down!" calls when it isn't.

Why it matters

A reachable-but-idle controller and a true outage used to look identical — data just stopped. That ambiguity drives false escalations. Naming the difference means the team responds to real failures and ignores false alarms, and the very same signal drives the on-screen dimming the operator already sees.

How it works

A heartbeat tracker watches a value the PLC updates and resolves the link into states: Connecting, Connected, Stale, Starved, and Disconnected. "Starved" is the key one — it means the PLC is reachable but its heartbeat isn't advancing (the controller's main task is idle), i.e. reachable-but-idle, distinct from a true "Disconnected" outage. The same last-success timestamp that sets this state also feeds the dashboard's freshness dimming on a one-second tick, so connection state and on-glass staleness are one consistent signal.

Versus the old RS-360 system

RS-360 logged comms but had no connection-state classifier — it couldn't tell why data stopped, so a reachable-but-idle controller and a real outage looked the same to the operator. Ring's heartbeat classifier is the single source feeding both alerting and the dashboard's staleness dimming.

Status & honest caveats

Likely questions & how to answer them

Chapter 2 — Running a Batch Without the Guesswork

A "batch" is one production run of one glue recipe: the operator tells the plant which recipe to make and how much, and the plant doses each ingredient into a mixing tank in the right order and amount. This plant makes corrugating adhesive — the industrial starch glue that holds cardboard layers together — so a "recipe" here is a list of ingredients with target weights and mix times, not a food formula.

Two pieces of vocabulary you must be able to define on demand. The PLC (Programmable Logic Controller) is the rugged industrial computer that physically runs the valves, pumps and mixer. It is the thing that actually makes the glue. The HMI (Human-Machine Interface) is the operator's screen — the window a person uses to tell the PLC what to do and to watch what it is doing. Ring is the new HMI. It does not change the PLC. Same controller, same wiring, same physics — only the screen in front of the operator is new. The old screen was "RS-360", a 2002 DOS-era program written in Borland C++; Ring replaces that screen on the exact same untouched controller.

The old way of running a batch was guesswork dressed up as procedure. On RS-360 the operator typed numeric "op-codes" — short number codes that each stand for an ingredient or an action — against PLC "data-file addresses" (numbered memory slots). There was no plain-language "here is exactly what I'm about to send" check, the live picture of a running batch vanished on a restart, and the historical record was trapped in a dead 1990s database format nobody could search. This chapter is about removing that guesswork: a guided start with a plain-sentence safety check, a live step tracker that stays honest when the network hiccups, a searchable permanent history, and analytics that compare today's batch against your own proven good ones.

One frame to set before the feature list, because a skeptical buyer will test it: Ring currently ships with a "read-only gate" turned on (a setting called ReadOnlyMode=true). With that gate on, every command that could change the plant is suppressed — Ring reads the controller but issues no write commands. On-site it read all 133 live data points without sending a single command that could change the process. (Reading does put request packets on the network, so the honest line is "zero write commands," never "zero bytes.") Several features below are therefore built and validated but deliberately gated off until the owner flips that switch — and saying so plainly is the point.

Keep your plant's memory — and a roadmap of upgrades built on top of it

What it is

This is the "why switch at all" feature, and it has two halves. The first half is real and shipped: Ring keeps a durable record of what the plant makes — a record that survives a reboot — and on top of that record it already shows a small "when will this batch finish" estimate on the main dashboard. The second half is a plan: a vetted wish-list of bigger upgrades (the headliner is a "Batch Dagplanner" — Dutch for "day planner" — that would tell the operator when the batch will next need them, e.g. "hold around 07:12, ready around 08:05," so they can do other rounds instead of standing at the panel). The wish-list is documented and agreed, but the big items are not built yet.

Why it matters

Today the live, in-the-moment picture scrolls away. If the HMI restarts mid-batch, the running picture is gone, and there is no step-by-step timing kept that a supervisor could mine later. Keeping that record is what unlocks every downstream improvement — predictive timing, "is this batch running long," shift summaries. An owner should care because this is the difference between a screen that forgets and a system that accumulates 20 years of operating knowledge you can actually use.

How it works

The shipped foundation is a step-timing table (internally BatchStepEvent) that is written as each batch step transitions, plus a "Process Historian" that quietly samples tank temperature and level once a minute from data Ring already reads — so it adds no new load on the controller. A completion-estimate card on the dashboard reads the medians of that step-timing history (no controller reads or writes at all) and shows "Batch done in ~22 min," with honest "no active batch" and "collecting data" states. The larger Dagplanner timeline, a practice/replay mode, a legacy-look skin, and a few other items are written up as a scored design plan — proposed, not coded.

Versus the old RS-360 system

Be precise here, because this is the single most fact-checked claim in the deck. RS-360 did not record nothing — it kept roughly 1,404 batch headers, 16,776 ingredient step rows, and shift and alarm records too. The honest gap is not "no history"; it is that RS-360 kept all of it locked in a dead Paradox/BDE database format (a corruption-prone 1990s file format that needs a custom reader to open), with no step durations or timing, no continuous time-series historian or surviving trends, no equipment-runtime stats, no golden-batch profiles, no operator notes, and no way for an operator to search any of it. Ring keeps step timing, a persistent historian, and a searchable record — and surfaces the history the legacy wrote for two decades but never let anyone read.

Status & honest caveats

Likely questions & how to answer them

Confirm exactly what gets sent before the plant arms

What it is

A guided way to start a batch that ends in a plain-English safety check. The operator picks a recipe from a list, types the target fill level, chooses the batch mode, and presses Start — and before anything is sent to the controller, Ring shows one plain sentence of exactly what will be sent ("Formula 1, Single Batch, No splitting, 625 gallons") and asks them to confirm it.

Why it matters

On the floor, the danger is a fat-fingered code arming the plant without anyone seeing what they actually requested. This feature puts a human-readable checkpoint between the operator's keystrokes and the controller, so a wrong recipe or a wrong volume is caught before it reaches the equipment rather than discovered in a ruined batch.

How it works

Configuration is written first; arming happens last. When the operator confirms, Ring writes the recipe number, target level, and split settings to the controller in order, and only then writes the single "go" signal that arms the batch. If that final arm step fails, Ring makes a best-effort attempt to disarm so a half-configured batch can't sit there armed. A "heartbeat" check (a continuous are-you-alive ping to the controller) blocks the whole thing if the PLC link is down, and the read-only gate, when on, short-circuits to an honest "validated but NOT sent" message instead of touching the plant.

Versus the old RS-360 system

On RS-360 the operator keyed recipes and levels against numeric op-codes — the ingredient list itself doubled as the code legend — with only a plain Yes/No pop-up and no read-only safety gate, so a mistyped code could arm the plant unseen. Ring shows the request in plain language, arms last, disarms on failure, and can run the entire flow with writes suppressed for safe rehearsal.

Status & honest caveats

Likely questions & how to answer them

A live, honest checklist of where the batch stands

What it is

While a batch runs, Ring shows the recipe as a live checklist: every ingredient with its target ("preset") amount next to its actual amount, a Complete / In Progress / Pending status per step, an overall percent-done, and a current-step caption that highlights and scrolls itself into view.

Why it matters

Operators used to infer where a batch was by squinting at gauges. This shows it directly — including whether each ingredient landed on target — so the operator knows at a glance what's done, what's running, and what's left, without guessing.

How it works

A background reader checks the controller's "current step" every two seconds (off the screen's drawing thread, so the display never freezes), reads the whole array of step targets and actuals, and publishes a snapshot the screen redraws on a timer. It's deliberately hardened against network hiccups: a failed read keeps the last good picture instead of blanking, and ending a batch requires three confirmed "idle" reads in a row (about six seconds) so one momentary blip can't wrongly declare the batch finished. The percent-done is weighted by ingredient amount and explicitly flags the "finishing" phase, so the trailing zero-amount mix/transfer steps don't show a fake "100% / under a minute."

Versus the old RS-360 system

RS-360 did show a per-step target/actual table on the mixer screen — but with no amount-weighted overall percent and no "step N of M" or ETA strip. And on your own 2026-06-10 golden batch it read "100% / under 1 minute" for the entire 21-minute finishing phase. Ring gives an amount-weighted percent with an explicit "finishing" label, plus the keep-last-snapshot and three-confirmed-idle logic so the display stays truthful through a network flap.

Status & honest caveats

Likely questions & how to answer them

A searchable, permanent record of every batch

What it is

Every batch is recorded automatically — formula, tank, start and end time, target versus actual volume, and a status (Running, Complete, Cancelled, or Interrupted). Operators can browse, filter by date or tank, search by batch number or formula, and print or export a Batch History report as a PDF.

Why it matters

Quality questions and management questions both come down to "what exactly did we make, and when?" This gives a complete, queryable answer instead of reconstructing it from memory or paper. The dedicated "Interrupted" status is the honest touch: if the HMI rebooted mid-batch, the record says so rather than leaving a batch that looks like it ran forever.

How it works

Ring records a batch as "Running" the moment it arms, into an open SQLite database (a standard, single-file, industry-standard database — the same engine inside most phones and browsers). When the batch ends, Ring finalizes it together with its ingredient-usage rows and actual volume in one all-or-nothing transaction, guarded so two events can't race and corrupt it. A batch left "Running" after a crash or reboot is reconciled to "Interrupted" on the next startup. A global "Go to Batch" shortcut (Ctrl+B) searches every batch by number or formula.

Versus the old RS-360 system

RS-360 did keep batch history (roughly 1,404 batch headers and 16,776 step rows) and could print a report — that part is parity, and you should grant it. What it lacked: operator notes, any crash/reboot distinction, and full-text search; and the data was locked in Paradox .DB files that need a custom reader to extract. Ring adds full-text "Go to Batch" search, an honest "Interrupted" status, and one-transaction finalization on an open database anyone can read.

Status & honest caveats

Likely questions & how to answer them

Edit a recipe once — screen, controller, and audit trail stay in sync

What it is

Supervisors can edit any of the six recipes step by step — operation, amount, mix-time — with add, insert, delete and reorder, plus a live calculated batch weight and volume. One "Apply" saves the change to Ring's database and pushes it down to the matching recipe slot in the controller. Every save is snapshotted, so you can see what a recipe looked like at any past point.

Why it matters

The classic failure is drift: the recipe on the screen, the recipe in the controller, and the written record slowly disagree. A single Apply that writes all three at once keeps them in lockstep, and the version snapshots give you an audit trail — who changed what recipe, and when.

How it works

The editor is a spreadsheet-like grid of steps. When you open it, Ring reads the live recipe bank from the controller; when you Apply, it writes the steps to Ring's database and to the controller's recipe slots (recipes 1 through 6, up to 30 steps each), maps each operation name to its numeric op-code, and shows a live weight/volume estimate using the same calculation the legacy used. On a successful Apply it also serializes the step list to a dated version snapshot — done "best-effort" so that even if the snapshot fails, your save still succeeds.

Versus the old RS-360 system

On RS-360, recipe edits went against a Paradox Recipe.DB, then pushed to the controller through a scratch-tag plus a multi-step handshake with a five-PC "dirty-flag" sync. Crucially, Recipe.DB held only the current values — no versioning — so the only way to tell that operators had edited presets was to mine 16,776 historical step rows after the fact. Ring's one Apply does the database write, the explicit controller write, and an automatic dated version snapshot, with a clear per-result message.

Status & honest caveats

Likely questions & how to answer them

Spot a drifting batch against your own good runs

What it is

Ring builds a "golden" reference curve from past good batches of a recipe and overlays the current live batch on top of it, flagging when the temperature is wandering away from that proven profile — with honest "still collecting data" states until enough good batches exist to build the reference.

Why it matters

Today you find out a batch went bad after it's finished. This gives an early, visual "this run is drifting off the recipe" signal grounded in the plant's own history of good batches — and it does it without adding any load to the controller, because it reuses data Ring already reads.

How it works

The Process Historian samples the tank readings Ring already has in memory once a minute (no new controller reads) and keeps 30 days of it, self-pruning. The golden-batch screen slices that history into per-batch temperature traces, builds a median "golden" reference once it has at least three completed batches of that recipe, and draws golden-versus-live as two lines with current and maximum deviation and a drift flag when temperature strays past a five-degree band. The scope is temperature only — there is no viscosity sensor on this controller to read.

Versus the old RS-360 system

RS-360 had no process historian and no golden-batch comparison at all — only per-shift production totals and batch headers, never a time-series temperature trace per batch. So there was simply no way to overlay a live batch against historical good ones. Ring adds a self-pruning 30-day per-tank time-series, a median golden reference, and a live deviation flag — net-new analytics with no added controller traffic.

Status & honest caveats

Likely questions & how to answer them

Pin operator notes to the exact batch

What it is

An operator can attach a free-text note to any batch — "added extra borax, starch was clumping," or "stopped early, corrugator down" — edited from the batch report and saved with that batch forever.

Why it matters

The "why" behind a batch used to live on a paper log or in someone's head and was effectively lost. Tying that context to the exact batch it describes — searchable later, printed on the report — is invaluable when you're chasing a quality complaint or explaining a bad batch weeks later.

How it works

The batch record gained a notes field, added to the database safely so the schema can't drift, and shown on every screen where a batch appears. The operator types or clears the note on the Batch Report window and it saves straight to that batch; clearing it empties the field.

Versus the old RS-360 system

On RS-360 operator context simply wasn't captured — the batch table was fixed columns (PC ID, formula, tank, times, weights, status) with no free-text field, so the reasoning behind a batch was gone. Ring lets you attach a free-text note to every batch, searchable and printed on the batch report.

Status & honest caveats

Likely questions & how to answer them

Re-run the usual recipe by the name operators use

What it is

Two related conveniences. Ring is moving to show recipes and tanks by their real names — like the plant's own Dutch recipe name "SF 1" — instead of generic "Formula 1." And each tank's Batch Start screen offers one-tap buttons for that tank's most-used recipes, so re-running the usual batch is a single tap.

Why it matters

Operators think in the names they actually use, not in "Formula 3." Matching the screen to their language cuts mistakes and training time, and the recent-recipe buttons make the most common action — the same recipe on the same tank — a single tap instead of a fresh search every time.

How it works

A name resolver relabels the recipe picker in place using custom names stored in Ring's database (while keeping the underlying recipe number intact), and saved names hot-reload across the app. The Batch Start screen queries each tank's top three recipes from the last 30 days of history and shows them as quick-select buttons.

Versus the old RS-360 system

On RS-360, the recipe showed as an operator-entered name on the tank card and mixer panel ("Formula : "). So name display itself isn't brand new — this is a parity-plus-convenience improvement. Ring wires that resolver into the pickers and persists custom names, but the 2026-06-10 on-site audit still found literal "Formula N" on a couple of surfaces (two P1 mismatches — the storage tank card and the mixer panel). Later commits narrowed the gap, so present this as in-progress parity, not done.

Status & honest caveats

Likely questions & how to answer them

Split a batch to the right second tank, safely

What it is

"Splitting" means sending part of a batch into a second storage tank instead of all into one. Ring lets the operator pick that second tank by its real name ("Split with Storage Tank 2/3/4"), and the confirmation dialog names the actual target tank — not a position in a list.

Why it matters

If the operator picks a destination and the plant's overfill protection ends up guarding a different tank, you can overfill a tank with no high-level alarm watching it. Naming the real tank — and making the overfill protection follow that same tank — is a genuine safety fix, not a cosmetic one.

How it works

Each Batch Start screen has split radio buttons whose label (e.g. "Split with Storage Tank 3") is mapped to the absolute tank number (3), not the button's position in the list. That matters because the live controller program reads the written value as an absolute tank number, then drives that tank's fill valve and watches that tank's high-level alarm at the same absolute index. The dialog shows the absolute tank that will fill.

Versus the old RS-360 system

Important correction to make in your own words: do not say the legacy "wrote ambiguous indices" — that was a Ring pre-fix bug, not legacy behavior. RS-360 actually supported splitting cleanly (its report even printed "Batch gedeeld met Tank"), and in six months and 1,404 batches the plant never used it — every record shows splitting off. So this is parity-plus-safety, not a legacy regression. Ring now maps to the absolute tank number with overfill protection that follows the chosen tank — but, honestly, that fix still needs controls-engineer confirmation and a bench write-and-observe sign-off before split batching runs live.

Status & honest caveats

Likely questions & how to answer them

Chapter 3 — Turn Plant Memory Into Money

Every shift your plant produces two things: glue, and a record of how it made that glue — which recipe ran, how much of each ingredient went in, what alarms fired, who was on shift. Call that second thing your plant memory. The problem with the old system was never that it failed to write any of it down. The problem is that it wrote it into a filing cabinet nobody could open. This chapter is about taking that memory out of the dead filing cabinet and turning it into two things an owner actually cares about: faster decisions, and visible money.

A few plain-language terms first, because the whole chapter leans on them. The PLC (Programmable Logic Controller) is the rugged industrial computer that physically runs the valves, pumps, and mixer — Ring does not change it and, on this site, is not even allowed to send it a command. The HMI (Human-Machine Interface) is the operator screen; Ring is the new HMI, replacing the 2002 DOS-era screen called RS-360. A tag is one named value living inside the PLC, like "Tank 2 temperature." A batch is one production run of one glue recipe. And SQLite is simply a single, open-standard database file that lives on the Ring PC — think of it as one tidy spreadsheet-style store you own outright, not a sealed proprietary vault.

Here is the honest version of the old situation, and you should lead with this honest version because a buyer who knows RS-360 can check it. RS-360 did store batch, step, shift, and alarm records — but in a Paradox/BDE format (an early-1990s database engine that has since gone dead) that needs a custom-built reader just to extract anything. There was no living historian recording values over time, no on-screen trends, no step-duration timing operators could use, no cost numbers of any kind, and no way for an operator to search it. The records existed; they were just stranded and silent. Ring's pitch is not "they recorded nothing" — it is "they recorded it into a dead format and could never use it; we keep that same memory alive and turn it into decisions and dollars."

One safety fact underpins everything below: all of these features read and store data on the Ring PC. None of them sends a command to the PLC. On top of that, Ring currently ships with a read-only safety gate switched on, which suppresses every PLC write. On-site Ring read all 133 live tags without issuing a single command that could change the process. (Reads do put request packets on the network — that is how any HMI asks the controller for a value — but not one of them was a write that could move a valve or change the process.) So whenever someone asks "could this analytics stuff touch my running plant?", the answer is a flat no.

See your spend and stop the leaks before they cost you

What it is

A spend-and-leak dashboard for the owner. After a one-time setup, Ring shows you what each batch and each week of glue actually cost in dollars, and it highlights three specific ways money leaks: over-dosing (putting in more expensive ingredient than the recipe called for, which is pure giveaway), scrapped batches, and hold time. You open it by clicking the "Spend (this week)" card on Ring's main dashboard.

Why it matters

Right now nobody at the plant can answer "what did this week of production cost us?" without a manual exercise. Over-dosing in particular is invisible money walking out the door — an operator who consistently runs an ingredient 5% rich is gifting a customer free product every batch, and no one sees it. Putting a dollar figure next to each batch turns a vague feeling that "we waste material" into a specific number you can chase down.

How it works

Ring's cost engine is a piece of deterministic math (it always gives the same answer for the same inputs — no estimating). For each batch it multiplies the actual amount of each ingredient used by that ingredient's unit price as of the batch's date, so a price change last spring doesn't rewrite last spring's costs. Crucially, it is built to never under-state spend: if an ingredient was used but you haven't entered a price for it, that batch is flagged as "not fully priced" and the missing ingredient is named, rather than silently treated as free. The figures come entirely from Ring's own local database — no PLC reads, no writes.

Versus the old RS-360 system

On cost, the contrast is total and fair: RS-360 had no cost engine of any kind. It never computed or retained cost, giveaway, or leak data — those questions simply went unanswered. This is one place where "the legacy did nothing" is literally true, because cost was never a feature of the old screen.

Status & honest caveats

Likely questions & how to answer them

Make faster calls with decision screens the legacy never had

What it is

A set of seven brand-new "decision" screens that turn raw events into answers: an alarm-analytics screen (which alarms fire most and how long they take to handle), a tank CIP board (which tanks are clean, dirty, or in use — "CIP" means Clean-In-Place, the automated wash cycle), an alarm-to-batch correlation screen (which batch was running when a given alarm fired), a batch-queue planning board, a downtime/OEE screen (OEE = Overall Equipment Effectiveness, the standard score for how productively a line runs), a golden-batch overlay (compare a run against your best-ever "golden" batch), and a prioritized alarm summary.

Why it matters

On the old screen, every one of these questions was answered by memory, paper, or guesswork. "Which alarm is killing us?" "Is Tank 4 actually washed and ready for a changeover?" "What was running when that fault hit?" These are the daily questions that decide whether a shift runs smoothly or chases its tail. Putting each on a dedicated screen turns tribal knowledge into something anyone can read.

How it works

All seven are read-only screens that draw from Ring's local SQLite database and never write the PLC. They compute familiar metrics — for alarms, things like average time-to-acknowledge and time-to-resolve, and a Pareto chart (the "80/20" bar chart that ranks the worst offenders first); for alarm handling, the ISA-101 and ISA-18.2 industry-standard layouts that let an operator "shelve" a known nuisance alarm. Each opens through the Reports area of the navigation bar.

Versus the old RS-360 system

RS-360 had a single alarm-history query form and basic printouts — and nothing else in this category. No analytics, no OEE, no CIP board, no batch-queue planner, no golden-batch overlay, no alarm shelving. So these seven are genuinely net-new decision tools, not reworked old ones.

Status & honest caveats

Likely questions & how to answer them

Watch trends live and review any tank's last 30 days

What it is

Two related tools. The first is a live trend chart: you pick PLC values you care about and watch them plot in real time on a rolling graph, complete with markers showing when batches started and alarms fired, and a one-click export to CSV (a plain comma-separated text file any spreadsheet opens). The second is a Tank History viewer that lets you look back over each tank's temperature and level for the past 30 days.

Why it matters

On the old screen, a number appeared, updated, and was gone — if you wanted to know whether a temperature was climbing or a level was drifting, you had to be staring at it at the right moment. Engineers needed the separate Studio 5000 programming software just to watch a trend, which most operators can't and shouldn't open. Letting anyone watch a live trend or scroll back 30 days means a question gets answered in seconds instead of after the evidence has already scrolled away.

How it works

The live trend screen opens as its own window and quietly polls the chosen live values every two seconds, drawing them on a custom chart. It keeps a rolling eight-hour buffer, lets you zoom from five minutes to eight hours, hover for exact values, and export to CSV — with no charting add-on and no PLC writes. The Tank History viewer renders the per-minute temperature and level series that Ring's historian (described later in this chapter) has been quietly recording, across a 30-day window.

Versus the old RS-360 system

RS-360 had no live time-series trend plot at all. The thing that looked like a graph in the old system — its ScreenGraphForm — is a static, configuration-driven mimic/graph builder, not a moving chart of values over time, and there was no per-tank history viewer either. The legacy parity audit simply lists trending as Missing. So this is genuinely new ground, not a tidied-up old graph.

Status & honest caveats

Likely questions & how to answer them

Catch a failing pump before it scraps a batch

What it is

A quiet watchdog on your feed equipment. Ring measures how fast each ingredient is actually being fed and compares it to that ingredient's normal pace. When a pump or line drifts noticeably off its baseline, Ring raises an early warning — in plain words like "starch feed is running 18% slower than usual — check the pump/line" — so maintenance can look before that drift turns into an alarm, a scrapped batch, or a line stoppage.

Why it matters

A pump rarely fails all at once; it slows down first. On the old system that early slowdown was invisible — you only found out when a batch went out of spec or the line tripped. Surfacing the drift while it's still a 15% slowdown turns a future emergency into a scheduled five-minute check, which is the difference between planned maintenance and scrapped product.

How it works

For each recipe-and-ingredient pair, Ring keeps a rolling baseline (the median feed rate of the last ten batches) and flags when a batch runs more than 15% off that baseline — but only when the drift holds across two batches in a row, so a single fluke doesn't cry wolf. The warning appears on the dashboard's Equipment Health card. It is also routed into Ring's notification rules so it can be included in a daily email digest.

Versus the old RS-360 system

RS-360 never computed feed-rate drift or surfaced any predictive warning — it offered no early signal of equipment trouble at all. (To be precise and fair, the legacy did store step records in its dead Paradox files, but it never turned them into a feed-rate baseline or a warning anyone could act on.)

Status & honest caveats

Likely questions & how to answer them

Get every report you rely on, from one database, with PDF

What it is

The full set of printable reports operators and supervisors depend on — what was batched, how much was used, batch and alarm history, recipes, inventory, and per-shift consumption — now with modern print preview and real PDF output, all pulled from one local database.

Why it matters

Quality audits, supervisor handoffs, and management reviews all run on these reports. The value here isn't a flashy new capability; it's that the reports you already rely on survive the move off the dead engine, gain PDF and date/tank filtering, and come from a single queryable store instead of a brittle 1990s file format.

How it works

Every report is backed by Ring's SQLite database and hosted inside the Reports area. Reports render as an on-screen preview you can print, save to PDF (via a real, properly-licensed PDF exporter — not a stub), or export to CSV, and several support date and tank filters. The per-shift consumption report even correctly credits an overnight shift's usage back to the prior day's shift, matching how the floor actually counts it.

Versus the old RS-360 system

RS-360's reports were trapped in printouts over the dead Paradox/BDE engine, and several backing tables — inventory and shift data — were effectively abandoned or readable only through a custom extraction tool. There was no PDF and no single queryable store. Ring gives you the same report set from one open database, with print preview, PDF, CSV, and filtering, plus revived shift-consumption and inventory history the old system left stranded.

Status & honest caveats

Likely questions & how to answer them

Answer "show me our data" in one click — you own it

What it is

A self-serve data exporter. When an auditor or manager says "show me our data," you pick a table, choose which columns and an optional date range you want, and save it to a CSV file — a standards-compliant plain-text file that opens directly in Excel. Your operational data is portable and yours.

Why it matters

The deepest fear with any plant software is that your own records get held hostage by the vendor's format. This feature is the antidote: anyone authorized can pull any table out to an open file in seconds, with no special tools and no dependence on a fragile engine. It's the practical proof of "you own your data."

How it works

A simple three-step dialog — pick table, pick columns, set an optional date range — writes out an RFC-4180 CSV (RFC-4180 is just the published standard for how a proper comma-separated file is formatted, so it imports cleanly everywhere). It's reachable from the Reports menu and reads only from Ring's database.

Versus the old RS-360 system

RS-360 had an export equivalent, but the underlying data was locked inside the dead Paradox/BDE engine and hard to extract once that engine aged out. Ring exports any table from an open SQLite store, so the data stays portable and stays yours rather than aging into inaccessibility.

Status & honest caveats

Likely questions & how to answer them

Never trust a frozen number: live, stale, or off-target at a glance

What it is

A set of plain-language trust indicators on your readings. Ring shows whether a value is genuinely live or has gone stale, flags temperatures and levels that are off target, and shows how far a batch over- or under-delivered against its recipe. On top of that, any tile or pill whose data source goes quiet automatically fades — dimming toward 45% opacity — and shows an "as-of" timestamp tooltip, so a number that's secretly frozen can't keep looking confidently live.

Why it matters

The single most dangerous thing an HMI can do is keep displaying a confident-looking number after the connection has quietly dropped — the operator acts on a temperature that's actually ten minutes old. These indicators make staleness visible, so during a comms blip nobody makes a decision on a dead reading. That's a safety feature dressed as a UI detail.

How it works

A small library of badges and chips — link state, tank attention, time-to-empty, health, batch variance, alarm triage — is wired into the live screens. A "freshness" converter set is registered globally and bound to the opacity and tooltip of the dashboard's key tiles and the status strip, using each value's last-sample timestamp. The clever part: a once-per-second internal tick keeps re-checking the timestamp even when the PLC link has gone silent, so a frozen tile genuinely keeps dimming instead of freezing bright. The staleness threshold is ten seconds.

Versus the old RS-360 system

RS-360 showed raw numbers with no sense of whether they were live, healthy, or on-target. A comms blip left a confident-looking but dead reading on screen with zero indication anything was wrong. Ring attaches link state, health, and batch variance to readings and fades any stale tile or pill toward 45% opacity with an as-of timestamp — so a frozen number announces itself instead of fooling you.

Status & honest caveats

Likely questions & how to answer them

Keep a true history — automatically, with zero extra load on the controller

What it is

The quiet recorder underneath everything else in this chapter. About once a minute, Ring writes down each tank's temperature, level, and current recipe, building a real, continuous history you can chart, compare, and cost later. It is the memory that powers live trending, the golden-batch comparison, and the cost engine — and it does it without adding any new traffic to the PLC.

Why it matters

You can't trend, compare, or cost what you never recorded. The old system had no living historian, so the moment a value left the screen it was gone. This service is what makes "plant memory" real: it captures the raw material that every analytics feature in this chapter feeds on, automatically and honestly.

How it works

A background timer fires about every 60 seconds and reads the snapshot of tank values that Ring already holds in memory for the operator screen — so it adds zero new reads to the PLC — then writes one row per installed tank into the SQLite database in a single batched transaction. It keeps a 30-day rolling window, pruning older data hourly. It is built to be honest about gaps: it won't record while the link is classified as dead (so a frozen connection never writes a row of fake flat data), and it skips empty tank slots rather than littering the history with blank ghost rows. The history table is indexed so charts pull quickly.

Versus the old RS-360 system

RS-360 kept some records in its dead Paradox files but had no continuous per-tank historian and no way to trend or do statistical process control (SPC — charting a value over time to spot drift) over historical process values; its text logs were purged unread. Ring captures a per-tank temperature/level/recipe row roughly once a minute into an indexed, open database with 30-day retention and honest gap handling, and it does so with no extra PLC traffic.

Status & honest caveats

Likely questions & how to answer them

Chapter 4 — Smarter Alarms, Faster Fixes

A few terms first, because the whole chapter rests on them. The PLC (Programmable Logic Controller) is the rugged industrial computer that physically runs the plant — it opens valves, starts pumps, and drives the mixer. The HMI (Human-Machine Interface) is the operator's screen; it shows what the PLC is doing and lets the operator press buttons. Ring is the new HMI. It is a modern Windows program that replaces the plant's 24-year-old DOS-era screen ("RS-360"), but it talks to the exact same untouched PLC. Ring does not change how the plant runs; it changes what the operator sees and how fast they can react.

An alarm is the PLC's way of shouting "something is wrong" — a tank too hot, an emergency-stop pressed, a batch stuck on hold. Inside the PLC each alarm is just a number (an "Alarm Number," for example #4 or #831). On the floor, the real cost of a fault is not the fault itself — it is the minutes lost while an operator figures out what the number means, which screen fixes it, and what to do first. On a corrugating-adhesive (industrial glue) starch line that runs around the clock, those lost minutes are wasted batches and idle production.

This chapter covers eleven things Ring does to shrink that gap: it shows every alarm in the controller's own words, links each one to the screen that fixes it, offers a "first thing to check" card, sorts the urgent from the handled at a glance, flags a stalled batch right on the dashboard, shows how long a fault has gone unanswered, raises a hard-to-ignore pop-up, guards the three process buttons (Hold/Resume/Reset) with a confirmation, ties downtime back to the exact batch that was running, and stays correct on a screen left on for days. One of the eleven is a deliberately honest "status" item — a tracked alarm-coverage gap — rather than a finished feature, and one widely-pitched pop-up behavior is built but not yet switched on. All of that is spelled out below so nothing surprises you in the room.

One framing point an outsider should grasp up front: Ring currently ships with a read-only safety gate turned on (a setting called ReadOnlyMode). While that gate is on, Ring suppresses every command that could change the process — it can read the controller but cannot write to it. (Reading still sends small network request packets over the wire, so the honest phrasing is "zero write commands," never "zero bytes.") That gate is the backdrop for several features below.

Every alarm reads exactly like the controller says it

What it is

When a fault fires, Ring shows the operator the same number and the same plain description the PLC itself uses — for example "E-STOP has Been Pressed" or "Make Ready Tank Temperature Too High." There is no homemade label sitting between the controller and the operator that could say something different from what the machine actually means.

Why it matters

In the middle of a fault, an operator's worst enemy is doubt about what the alarm even means. If the screen's wording drifts from the controller's wording, people hesitate, second-guess, or act on the wrong thing. Matching the controller bit-for-bit removes that doubt so the operator trusts the alarm and acts.

How it works

Ring keeps a small built-in dictionary (the "alarm catalog," seeded in code) that maps each Alarm Number to its real text and a severity letter — A for Alarm/critical, W for Warning. The PLC also encodes an alarm's state by adding an offset to the number: the base number means "Active," base +1000 means "Silenced," and +2000 means "Resolved." Ring strips that offset back off to recover the true alarm and its state. Those offset rules were checked against the controller's own logic and confirmed against live plant data read on-site, so what Ring shows lines up with both the controller and the old HMI.

Versus the old RS-360 system

RS-360 stored alarm wording as positional Dutch text in flat files, riddled with gaps and blanks — entries 30/31 literally read "Thermische veiligheid ??", 97/98 were blank, and alarm #4 had no entry at all, so operators just saw the bare code "A0004." Ring seeds the controller's active alarm catalog (76 numbers today) with real descriptions and decodes the same +1000/+2000 state bands the controller uses, even down to preserving a legacy quirk for exact parity.

Status & honest caveats

Likely questions & how to answer them

One tap from the alarm to the screen that fixes it

What it is

Each alarm row offers a single button that jumps straight to the screen where you actually deal with that fault — for example "Go to Storage Tank 2," "Go to Make Ready Tank," or "Go to TVC" (the temperature-control area). The operator does not need to memorize the plant's screen map.

Why it matters

On the old system, knowing which screen fixed a given fault was tribal knowledge — fine for a veteran, slow for a new hire at 2 a.m. A one-tap link turns "where do I even go for this?" into a reflex, dropping the time from fault to fix to seconds.

How it works

A small lookup (a "link resolver") maps each decoded alarm number to a target screen and a label. Storage-tank alarms resolve to the right tank by its number; Make Ready Tank faults go to the MRT screen; certain temperature-control alarms go to TVC. The link is pure read-only information inside Ring — it sends nothing to the PLC — and the button is coded so that tapping it doesn't accidentally trigger the row's other behavior.

Versus the old RS-360 system

RS-360's alarms were inert text on the alarm form. To fix something you had to already know which area screen to open and navigate there by hand. Ring puts the right destination one tap away.

Status & honest caveats

Likely questions & how to answer them

A built-in "first thing to check" card for priority alarms

What it is

For a set of priority alarms, Ring offers plain-language first-response guidance — what the alarm means, the first thing to check, and who to call — without the operator hunting through a paper manual. Alarms that don't have a card yet point the operator to the manual, and a supervisor can add or edit cards over time.

Why it matters

The slowest moment in a fault is a green operator paging through a binder. For the highest-priority alarms, having "first check: ..." right on the screen lets a brand-new operator respond like a veteran, and lets supervisors keep raising the team's floor by writing better cards.

How it works

Ring ships a small built-in file of playbook entries keyed by alarm number, and a database override so a supervisor's edited card wins over the shipped default. Two surfaces use it: hovering a covered alarm on the dashboard shows the first check line in the tooltip, and selecting that alarm row on the Process > Alarms screen opens the full card — meaning, first check, and who to call — in a dedicated panel. A supervisor editor (Setup > Alarm Playbook) lets you add or override entries for any alarm number. The whole feature is observational: it never touches the PLC, the alarm queue, or the silence/acknowledge path.

Versus the old RS-360 system

RS-360 left operators on their own for most faults, with at most static "possible causes" text on a couple of hardcoded pop-ups. Ring ships a curated first-response playbook (meaning / first check / who to call) for about 10 priority alarms today, with a supervisor editor to add or override entries for any alarm number.

Status & honest caveats

Likely questions & how to answer them

Tell a live critical from a handled warning at a glance

What it is

Every alarm row shows two things instantly: how serious it is (Critical / Warning / Info) and where it is in its life (Active / Silenced / Resolved). Crucially, the state is shown by a distinct shape as well as a color, so a color-blind operator reads the same answer just as fast.

Why it matters

On a monochrome list, every line looks equally urgent, so operators waste attention re-reading handled faults or — worse — mistake a long-resolved warning for a live emergency. Encoding urgency and state visually lets an operator triage from across the room.

How it works

Ring maps the catalog severity letter to a tier (A = Critical/red, W = Warning/amber) and downgrades already-acknowledged or silenced rows to Info. State is drawn as a shape, never color alone: Active is a filled triangle, Silenced a half-circle, Resolved a check mark. Resolved and silenced rows are dimmed, and the list sorts Active alarms to the top (newest first), then Silenced, then Resolved. A small cache avoids re-reading the database on every 2-second refresh.

Versus the old RS-360 system

RS-360 forced operators to read every line equally — a monochrome DOS list with no severity tiers, no lifecycle states, and no color-blind affordance. (An earlier Ring build briefly painted every row an identical red "Alarm"; that's already fixed.) You now see severity and state at a glance as color plus shape, with resolved rows dimmed to muted info chips instead of staying red.

Status & honest caveats

Likely questions & how to answer them

An "ON HOLD" flag on the dashboard the moment a batch stalls

What it is

If the running batch goes on hold — held for inspection, held too long, or running too slowly — an amber "ON HOLD" chip with the reason appears right on the dashboard's active-batch banner, and the time-remaining reads "(paused)" instead of pretending the batch is still moving forward.

Why it matters

The expensive failure mode is a batch that's quietly stalled while the screen still shows a progress bar creeping along — nobody notices for minutes. Surfacing the hold and its reason on the main screen catches a stall early, before it costs a batch.

How it works

Ring watches the active alarms for the "hold" family (held for inspection, held too long, progress too slow), picks the most-escalated one, and shows its description in the amber chip on the hero banner. The estimated-time-remaining gains a "(paused)" tag while the hold is active. It is purely a re-presentation of the alarm data Ring already reads every 2 seconds — no new PLC reads.

Versus the old RS-360 system

On the live batch we observed, the legacy/early-Ring hero kept showing normal progress while the batch actually sat on hold for about 12 minutes — RS-360 had no hero hold chip tying the hold alarm to the running batch. Ring now flags the hold and the reason on the dashboard and stops the progress bar from faking forward motion.

Status & honest caveats

Likely questions & how to answer them

See how long a fault has been sitting unhandled

What it is

Each alarm shows how long it has been going — "4m", "1h 12m" — and the panel header calls out the single oldest unhandled (still-active) alarm. That "oldest active" line is the key "is anyone actually dealing with this?" signal for a supervisor.

Why it matters

A fault that's been ignored for an hour is a very different problem from one that fired ten seconds ago, but the old screen made them look identical. Showing age — and especially the oldest unhandled alarm — lets a supervisor catch the one that fell through the cracks.

How it works

Ring records when each alarm was raised and renders a compact age ("<1m", "Nm", "Nh Nm"), recomputed on the existing 2-second refresh with no extra timer. The "oldest active" header scans the full set of active alarms against the live clock and shows the single oldest one's age; it stays blank when the raise time is unknown, so an age is never invented.

Versus the old RS-360 system

RS-360 stamped an alarm's time but had no live, counting-up relative age and no "oldest active" callout — supervisors were left eyeballing timestamps to guess how stale a fault was.

Status & honest caveats

Likely questions & how to answer them

A full-screen alarm pop-up that won't let a live fault be ignored

What it is

When a genuinely new fault fires from the controller, Ring raises a full-window alarm overlay that takes over the screen, flashes a red beacon, shows the live alarm, and locks navigation until the operator either acknowledges it or explicitly chooses to keep monitoring. It fires only on a new fault — not every time the same alarm is acknowledged or silenced — so the screen doesn't nag.

Why it matters

On the old system, operators learned to tune alarms out. A modal overlay that blocks the screen on a genuinely new fault makes sure the important one actually lands, and the "new fault only" trigger keeps it from becoming background noise.

How it works

Ring polls the controller's alarm tags, detects when a new base alarm appears (not a state change of one already showing), and raises the full-window overlay, which hosts the live alarm grid and flashes a red beacon. The operator dismisses it by acknowledging or by tapping "Continue monitoring." Severity inside that overlay is conveyed by the same shape-plus-color glyphs as the alarm list.

Versus the old RS-360 system

RS-360 trained operators to ignore alarms — pop-ups were hardcoded per alarm with a fixed red gradient and a forever-blink regardless of severity, and there was no navigation-locking modal overlay at all. Ring adds a modal overlay that locks the screen behind a genuinely new live PLC alarm until it's acknowledged or the operator explicitly chooses to continue monitoring, and it suppresses re-pop-ups on ack/silence of the same alarm.

Status & honest caveats

Likely questions & how to answer them

An "are you sure?" guard before Hold, Resume, or Reset

What it is

The familiar Process buttons that pause (Hold), restart (Resume), or reset a batch now each pop a Yes/No confirmation before they send the command to the PLC, so an accidental tap can't disrupt a running batch. Resume and Reset stay hidden until Hold has been pressed.

Why it matters

These three buttons drive the live process. On the old system a single mis-tap went straight through. A confirm step keeps the operator's existing muscle memory but puts a deliberate "are you sure?" in front of an action that can interrupt production.

How it works

The Process submenu wires Hold/Resume/Reset to handlers that each call a Yes/No confirmation prompt — which defaults to "No" — before the actual write to the PLC runs. Resume and Reset only appear after Hold is pressed. The bits Ring pulses are the same control bits the legacy HMI used.

Versus the old RS-360 system

RS-360 sent the command on the first click — Hold/Resume/Reset pulsed the same control bits, but with no confirm-before-write guard. Ring keeps the identical control behavior and adds an explicit confirmation step in front of each live PLC command.

Status & honest caveats

Likely questions & how to answer them

Tie downtime to the exact batch that was running

What it is

A report that, for any alarm, shows which batch (and which recipe) was running at the moment the alarm fired — so maintenance and supervisors can attribute downtime or a quality issue to a specific batch and formula instead of leaving it a mystery.

Why it matters

"What was the plant making when this went wrong?" is the first question in any root-cause or accountability conversation, and on the old system it was unanswerable without manually cross-reading two separate logs. Linking the two turns guesswork into facts.

How it works

The correlation is a straightforward time-window join: for each alarm, Ring finds every batch whose start-to-end window contains the moment the alarm fired. Because alarms don't carry a tank identity, it matches all batches running at that instant (usually just one), and it widens the lookback so a long batch that started before the window still counts. The result is shown on a dedicated Alarm ↔ Batch report screen (Reports > Alarm ↔ Batch).

Versus the old RS-360 system

RS-360 kept alarm history and batch history as separate, unlinked logs — both existed, but there was no way to join them and ask "what was running when this alarm fired?" Ring answers that question on one screen.

Status & honest caveats

Likely questions & how to answer them

Honest coverage status: 76 alarms correct today, 94 legend rows tracked

What it is

This is a transparency item, not a screen feature. Ring's alarm catalog faithfully reproduces 76 controller alarm numbers correctly today. The plant's full Dutch legend, though, contains about 94 additional alarm numbers Ring hasn't seeded yet — and until the catalog is expanded, importing the legacy legend silently skips them.

Why it matters

A skeptical buyer or controls engineer will eventually count the catalog. Disclosing the gap up front — exactly what's covered, exactly what isn't, and that the fix is straightforward and tracked — builds more trust than a glossy "all alarms covered" claim that falls apart under inspection.

How it works

An audit of the legacy Dutch legend against Ring's seed found 94 numbers that need a new catalog row (plus 46 that need updated text and 30 already fine). The legacy-legend importer currently does a "blind update" — it only refreshes numbers that already exist in the seed, so any legend row with no matching seed entry is silently dropped rather than added. The fix is purely additive: expand the seed with the missing numbers and switch the importer to an "upsert" (update-or-insert).

Versus the old RS-360 system

The legacy legend was itself fragile — alarms 30/31 read "Thermische veiligheid ??", 97/98 were blank, and alarm #4 had no entry, so it showed "A0004." Ring already shows the full meaning for alarms the legacy left as placeholders (including the real text for #4); the remaining 94 numbers are a known, additive seed expansion.

Status & honest caveats

Likely questions & how to answer them

On a screen left running for days, a live fault never quietly vanishes

What it is

A set of robustness behaviors for an HMI that stays on for days at a time: a live (still-active) alarm never silently disappears because of a stale date filter, and reading a playbook for a live alarm isn't interrupted by the 2-second refresh throwing away your place.

Why it matters

A plant HMI runs 24/7. A naive screen can quietly hide an old-but-still-active fault behind a date window that froze at boot day, or it can rip the operator out of the alarm they're working every two seconds. Both are exactly the failures that erode trust in an alarm screen. These behaviors prevent them.

How it works

The default date window rolls forward on every refresh, so a screen left on for days never freezes at the day it booted. Active alarms are always shown regardless of the date window, so a weekend-old still-active fault never vanishes. And when the displayed set of alarms hasn't actually changed, Ring skips rebuilding the list — which preserves the operator's selected row (and any open playbook), sort order, and scroll position across refreshes. The only thing deliberately excluded from that "did anything change?" check is the drifting age text, so it can't defeat the guard.

Versus the old RS-360 system

These are modern robustness behaviors for a long-running Windows HMI; the single-shot DOS-era RS-360 display simply didn't face the same date-window and refresh pitfalls, so this is a genuinely new concern rather than a like-for-like comparison.

Status & honest caveats

Likely questions & how to answer them

Chapter 5 — On the Floor & Standing Up a New Site

This chapter is about the un-glamorous half of the job: the day a crew actually uses the new screen on a live shift, and the day someone has to set up a second screen on a fresh machine. None of it changes the glue. Before the feature list, fix three words in your head. PLC is the controller — the Allen-Bradley box that physically opens valves, runs pumps, and times the mix. Ring never changes it. HMI is the operator screen — the window a person looks at and clicks. Ring is the HMI; it replaces the 2002 DOS-era screen called RS-360 while leaving the same PLC untouched underneath. A batch is one production run of one glue recipe.

The real floor problem this chapter addresses is "everything that isn't the recipe itself." Shifts hand off by memory and scribbled paper. A communications drop between the screen and the PLC can pass unnoticed until something goes wrong. Standing up a new station on the old system meant rebuilding a 2002 developer's machine by hand, with settings buried in INI files (plain-text config files) and the plant's real Dutch equipment names trapped in a dead database format. And the screen itself, fresh out of the box, felt like foreign software because it showed generic names nobody on the floor uses.

One honest framing you should carry into the meeting: the old RS-360 was not a black hole. It did record batch, step, shift, and alarm history — but in a corruption-prone, long-dead Paradox/BDE database format with no living "historian" (no continuously-running data recorder), no on-screen trends, no cost numbers, no step-duration timing, and no way for an operator to search it. So the honest pitch is never "the old system stored nothing." It is "the old system locked its data in a format only a custom extraction tool can open, and gave operators no living, searchable, on-glass access to it." Ring is the living, searchable, on-glass layer on top of the same plant.

One more phrase to get exactly right, because a controls engineer will pounce on it. Ring ships with a read-only safety gate turned on (a setting called ReadOnlyMode=true) that blocks every command that could change the process. On-site it read 133 of 133 live values from the PLC without issuing a single command that could move anything. Reading still puts request packets on the network — so never say "zero bytes." Say "zero write commands." Reads ask; they never tell.

A tag (used throughout below) is just a named value inside the PLC — like Tank_IO[1].O_Agitat — that the screen can read or, when allowed, write.

Stand up a whole new station in a few guided minutes

What it is

The first time Ring boots on a new machine, it does not dump the technician into a blank settings file. It runs a setup wizard — the same friendly "next, next, next" experience as setting up a new phone. It walks the person through, one step at a time: pick a language, connect and test the PLC, confirm the safe read-only mode, set up email and who gets alerts, seed some default data, add the plant's logo and branding, set the shift pattern, and import the plant's real equipment names. At the end the station is live.

Why it matters

This is the difference between "a developer flies out for a day" and "a commissioning technician does it before lunch." It also means a supervisor can re-run the same wizard later from the Setup menu to fix a setting, without ever opening a config file. The read-only safety step is deliberately a human decision: writes to the plant are never switched on by accident — someone has to choose it on that screen.

How it works

The wizard is an ordered list of steps the program runs in sequence. Each step is self-contained and fail-safe: if a step hits a bad input internally, it lets you finish anyway rather than trapping you. A small flag is saved once the wizard completes, so it does not nag you on every launch — but it survives a machine rebuild, and it re-prompts if a newer version of Ring adds steps. A splash screen shows while it loads.

Versus the old RS-360 system

On RS-360, standing up a station meant reconstructing a 2002-era developer machine by hand: there was a splash screen but no guided setup, with configuration buried in INI files (one config file alone is roughly 7,500 lines) plus a separate helper program. Ring replaces all of that with one guided, fail-safe wizard that is re-runnable any time settings need a fix.

Status & honest caveats

Likely questions & how to answer them

See your own equipment names on day one — imported from RS-360

What it is

On day one, the new screen can show the plant's own familiar names — the Dutch tank names, ingredient names, custom recipe names, even alarm text — instead of generic "Storage Tank 3." It does this by reading those names straight out of the old RS-360's files and loading them in. A preview screen shows a supervisor every name it is about to set, side by side with what is there now, so a human signs off before anything is written.

Why it matters

Two payoffs. First, nobody re-types dozens of fields by hand. Second, the screen stops feeling like imported foreign software the moment it boots, because it speaks the plant's own vocabulary — the exact tank and ingredient words the operators already use. That is a real trust-builder in front of a skeptical senior operator.

How it works

Two design rules make this work in any language. (1) It reads each old file using the correct character encoding (the default fits Western-European text; several others, including Cyrillic, Turkish, Japanese, and Chinese, are supported) and stores everything in modern universal text. (2) It matches things by slot number, not by label — the old system always put the mix tank in slot 1, storage in slots 2–7, dosers in 8–13 — so it maps correctly whether a field reads "Natief Zetmeel" or "Domestic Starch." Every proposed name is tagged New / Changed / Unchanged with a confidence flag, factory-default "Formula N" names are skipped, and only after the supervisor confirms does it write — through Ring's own internal save paths, so the screens refresh live.

Versus the old RS-360 system

Migrating off RS-360 normally means re-keying everything by hand: its data sits inside Paradox/BDE tables and INI files with no documented export path, and is genuinely awkward to extract. Ring is a purpose-built, preview-then-commit, slot-keyed importer that liberates exactly that data and writes it into Ring so the screens update immediately.

Status & honest caveats

Likely questions & how to answer them

Never miss a comms loss or a live alarm — safety is visible on every screen

What it is

Every Ring screen is wrapped in a fixed frame of status indicators that you cannot navigate away from. A banner across the top shows whether the PLC is connected. A loud banner shows when the system is in safe read-only mode. If an alarm fires, a full-screen overlay drops in and locks the menu until it is dealt with. Small pop-up "toasts" confirm that an action went through without blocking your work. A strip along the bottom always shows the clock and the connection state. And a small badge shows not just "up/down" but five distinct connection states, so "truly offline" reads differently from "reachable but idle."

Why it matters

A missed communications drop is the nightmare: the screen looks normal but is showing frozen numbers. Ring makes that structurally hard to miss — the link state is always on screen. The read-only banner means nobody is ever confused about whether the system can write to the plant. And the five-state badge cuts the "the PLC is down!" false alarms, because operators can see the difference between a genuinely dead link and a link that is fine but momentarily idle.

How it works

The main window is laid out as fixed rows plus stacked overlays. One row is the PLC banner (it disappears when connected and shows a "Retry now" button when disconnected); one is the read-only banner, deliberately styled loud; the bottom row is the clock-plus-connection-plus-data-freshness strip. The alarm overlay sits on the very top layer and locks navigation; toasts and the help overlay sit just below; the active-alarm banner is placed so it never covers the menu's click area. The connection state is computed from the PLC's heartbeat and surfaced as named states.

Versus the old RS-360 system

RS-360 had an alarm form and a comms log, but no persistent link-state banner, no read-only safety banner, no navigation-locking alarm pop-up, no non-blocking toasts, and no five-state heartbeat — so a comms drop could pass unnoticed until something went wrong. Ring keeps link state, safety mode, and live alarms visible on every screen at all times, and tells offline apart from idle so operators trust the badge.

Status & honest caveats

Likely questions & how to answer them

Cut missed-context errors between crews with durable shift handoff

What it is

A set of screens that let crews hand off in writing instead of by memory. You can start and end a shift, see shift status, leave a written end-of-shift note for the next crew, and read a one-page summary of what actually happened during a shift window — the batches run, the alarms, and what is still running.

Why it matters

Most shift mistakes are missed context: the incoming crew doesn't know what the outgoing crew knew. A durable, timestamped note trail plus a "what happened this shift" summary means the next crew inherits real information, not a scribble on a clipboard that gets lost.

How it works

The Shifts menu has three pieces. Shift Control backs real Start/End actions with a saved event record and a status banner, stamping who did it from the logged-in session. Handoff Notes is an append-only list — notes are added, never overwritten, and the last ten are shown. Shift Handover is a read-only summary that queries the local database for the chosen shift window and lays out batches, alarms, and still-running items.

Versus the old RS-360 system

RS-360 crews handed off verbally or on paper. It had a shift control tab and shift user forms, but no handoff-note trail and no shift summary at all. In fact Ring's own earlier audit had once flagged its own shift screen as a "visual mock only" — that has since been replaced with a real, repository-backed screen, and the Handoff Notes trail and Handover summary are genuinely net-new with no legacy equivalent.

Status & honest caveats

Likely questions & how to answer them

See every tank group live, by the plant's own names

What it is

Dedicated live screens for each part of the plant, each named the way the plant names it: the mixer (Make Ready Tank), the storage tanks as a group, the use/doser tanks as a group, an agitator overview, the viscometer readings, and a detailed view of any single tank. So the bond-quality-critical reading and any one feed tank are a click away, not buried inside a group view.

Why it matters

Operators need both the wide view (all storage tanks at a glance) and the deep view (this one doser tank, in detail). On a glue kitchen, viscosity is the spec that makes or breaks the bond, so having a place to log and trend that reading matters. Naming the screens the plant's way removes the "which tank is this again?" friction.

How it works

The Main Screen menu opens live, polling overview screens — they re-read the PLC about once a second and update. The Use Tanks menu drills into a single feed tank, with the card headers resolved from the plant's own name tables. All the single-tank views share the same underlying data-fetch machinery.

Versus the old RS-360 system

RS-360 scattered this across a mixer form, several storage forms, a use-group screen, the TVC overview, a viscometer form, and use-tank forms — and Ring's earlier 2026-05 audit had flagged the Use Tank Group, the viscometer main screen, and the MF1 drill-down as missing or scaffold-only. Those are now built out and named the plant's way.

Status & honest caveats

Likely questions & how to answer them

Rename, reconfigure, and back up yourself — no developer, no callout fee

What it is

A password-gated Setup area where a supervisor or admin runs their own configuration instead of phoning a developer. Behind the password sit roughly two dozen-plus screens: rename tanks and groups, edit recipes, set shift names and times, manage inventory, set the PLC clock, back up the database, and more. Changes are saved and survive a restart.

Why it matters

On the old system, a tank rename or a shift-time change was a developer callout. Here it is a supervisor with a password. That removes both the cost and the wait of getting a vendor on the phone for routine config changes.

How it works

The Setup menu opens behind a password dialog that returns "Supervisor" or "Admin." Supervisors see about two dozen configuration screens; admins see those plus a handful of higher-privilege tools. Renames and edits are written to the local database (a lightweight, single-file database called SQLite), so they stick across restarts.

Versus the old RS-360 system

RS-360 had a Setup menu family (tank, group, formula, shift, viscometer, time/date, import/export setup), but several of Ring's own equivalents had once been session-only — for example a tank rename used to be lost on restart. That is now fixed: changes persist, and the gate cleanly separates supervisor from admin actions.

Status & honest caveats

Likely questions & how to answer them

Fix faster and stay informed off-site — alarm emails with fix steps, scheduled reports

What it is

A notification platform built into Ring. It can email an alarm — and the steps to fix it — to whoever you choose; mail any report on a daily/weekly/monthly schedule; email a completion notice when a batch finishes (today via a config flag; an in-app on/off toggle is a follow-up); and ping Microsoft Teams or Slack. It is set up in the wizard and in a Setup screen, with a "test send" button to prove it works.

Why it matters

A maintenance tech can get the alarm and the fix on their phone before driving in. The owner gets the Monday-morning report without coming to the plant. And operators don't get buried in alarm spam, because the system batches repeated alarms into a digest and enforces a cooldown.

How it works

Email goes out through a shared sender that queues messages and sends them on a background worker, so the screen never freezes waiting on email. It retries up to three times with increasing delays and logs every message (with the full error text if one fails). The alarm path adds storm control (a cooldown per alarm, and digest mode when too many fire in a window), stamps each alarm with the recipe and step at the moment it fired, includes the first-response checklist, and can send a follow-up when the alarm clears. The report scheduler works out which subscriptions are due and attaches a PDF.

Versus the old RS-360 system

RS-360 had no email or notification capability at all — alarms and reports were screen- and print-only, so you were blind off-site. Ring's full notification platform (queued, retried email; scheduled report attachments; completion notices; Teams/Slack) is net-new value with no legacy peer.

Status & honest caveats

Likely questions & how to answer them

Turn the HMI into an owner's management tool — cost, alarm guidance, maintenance

What it is

A cluster of Setup screens that give the owner management tooling the old system never had: ingredient costs and currency (so you can see what a batch costs), a playbook of what to do when each alarm fires, calibration and maintenance reminders, and a way to export or import the whole plant configuration as a portable profile to carry to a second station.

Why it matters

This is the line between "operate the plant" and "manage the plant." Cost visibility turns the HMI into something an owner reads. The alarm playbook captures the senior tech's knowledge so it doesn't walk out the door. The maintenance board stops calibrations slipping. And the portable profile means standing up a second station inherits the first one's configuration.

How it works

Each is a built, persisted Setup screen: the Costs screen writes currency and a downtime rate into the config plus per-ingredient costs into the database; the Alarm Playbook screen stores writable first-response notes per alarm; the Maintenance screen is a colour-coded due/overdue board; the Plant Profile screen exports and imports a commissioning subset. They live in the same Setup family as the email, language, and import screens.

Versus the old RS-360 system

RS-360 gave owners no management layer at all: INI files, no cost module, no alarm playbook, no maintenance board, no config export. Ring turns the HMI into an owner-facing management tool rather than just a control panel.

Status & honest caveats

Likely questions & how to answer them

Operators read the HMI in their own language and script

What it is

Ring runs in 13 languages — English, Dutch, German, French, Spanish, Italian, Portuguese, Turkish, Polish, Korean, Japanese, and both Chinese scripts — and you can switch between them on the fly, without restarting. English is the default. The Dutch words come from the live plant's own old dictionary, so Dutch operators see the exact terms they already know.

Why it matters

The screen stops feeling like imported foreign software when an operator reads it in their own language and script. And being able to flip the language live, in front of a senior operator, is a genuine trust-builder during a sale or a cutover.

How it works

Ring keeps an English string set as a permanent base and layers the chosen language on top, "last wins." Any word that hasn't been translated yet simply falls through to English — never a blank. Switching language swaps the active dictionary live, so the screen repaints instantly, and the choice is remembered for next launch. Importantly, the language switch deliberately does not touch the system's number formatting, so the batch math and PLC number parsing are never affected by which language is displayed.

Versus the old RS-360 system

Be careful and precise here, because a controls engineer who knew RS-360 will catch an overstatement. The honest, QA-corrected line: RS-360 shipped many language dictionaries and had an in-app language menu, but switching required a reload/reconfigure to take effect and it had no English fallback for missing strings. Ring switches the live UI instantly with no restart and always falls through to English. Do not say RS-360 "couldn't switch without reconfiguring" as an absolute — it had a menu; the real differentiators are live switching and the safe English fallback.

Status & honest caveats

Likely questions & how to answer them

End the "where am I / how do I get back" confusion

What it is

A single menu bar that runs down the left edge of every screen and is always there. Click a section like Reports or Setup and a small menu flies out next to it. The button for the screen you are currently on stays highlighted, and a Back button retraces your steps.

Why it matters

The old system was a sprawl of separate windows and per-tank menu items — roughly 97 forms — with no "you are here." Operators got lost and couldn't find their way back. One consistent rail with an active-screen highlight and a Back button removes that friction entirely.

How it works

The rail is a fixed strip with eleven top-level buttons; nine of them open a small fly-out menu that closes when you click away or press Escape. Clicking a menu item swaps the main content area to that screen (re-using a cached copy where it makes sense) and marks the rail button as active with a coloured accent. Back is a separate history stack.

Versus the old RS-360 system

Getting around RS-360 meant menu-diving through roughly 97 separate forms in a 2002-era windowing interface with hand-built per-tank menu entries and stacked child windows, and no persistent "you are here." Ring replaces all of that with a single persistent rail, active-screen highlighting, and a Back stack.

Status & honest caveats

Likely questions & how to answer them

Root-cause faster and protect your data

What it is

A set of engineer and maintenance tools so the floor can self-serve troubleshooting and keep data safe: read any live PLC value without opening the programming software, capture a one-shot system snapshot to send to support, watch a live feed of PLC messages to see why comms hiccuped, set the PLC clock, run one-button database backup and restore, and — admin only — factory reset.

Why it matters

When something is off, the question is "is it the network, the PLC, or the screen?" These tools answer that on the floor in minutes, without flying in a specialist or opening Studio 5000 (Rockwell's PLC programming software). And the one-button backup protects the plant's accumulated history.

How it works

These are pop-up dialogs. The Tag Inspector lets you paste a tag name (like Tank_IO[1].O_Agitat) and reads its current live value. The Diagnostic Console takes a one-shot snapshot of host, PLC, and traffic, behind a supervisor password. The Communication Monitor tails the live send/receive messages. The Time/Date tool sets the controller clock. Backup/restore uses the database's own safe online-backup, re-prompting for the password. Factory reset is admin-only and re-prompts before it runs.

Versus the old RS-360 system

RS-360 had a comms log with disk logging and a time/date form, but no live tag inspector, no one-shot diagnostic snapshot, no built-in database backup or restore, and no factory reset. The Tag Inspector and the Diagnostic Console are the strongest all-new technical tools, sitting alongside safe backup/restore and a guarded factory reset.

Status & honest caveats

Likely questions & how to answer them

Get hand-logged readings off paper and into reports

What it is

The things operators write down by hand — shift readings, manual measurements — become digital and reportable. There are five fill-in forms, and a supervisor can rename the field labels to match the plant's own terms, so the data lines up with how the plant already talks.

Why it matters

Hand-logged readings on paper are invisible to everyone who isn't holding the clipboard. Capturing them in Ring makes them searchable, trendable, and reportable — and letting the supervisor name the fields means the form matches the plant's existing workflow instead of forcing a new vocabulary.

How it works

A hub lists the five forms as buttons, each showing the supervisor-customized first-field label. Each form renders up to 11 fields parameterized by which screen it is. A separate setup hub lets a supervisor rename those 11 labels per screen, saved to the database. The results feed a Data Entry report.

Versus the old RS-360 system

RS-360 kept this on screen and on paper with an equivalent set of forms, but Ring's earlier audit headline was literally "Zero WPF mirror exists" for this whole family — it hadn't been built yet. It has since been built in full (the five-screen family plus setup and report), with supervisor-controlled labels.

Status & honest caveats

Likely questions & how to answer them

Set agitators to cycle themselves instead of managing paddles by hand

What it is

A per-tank agitator screen for each storage tank. You can turn the agitator on or off, or set it to automatic mode with on/off timer presets so the paddle cycles by itself instead of an operator babysitting it.

Why it matters

Manual paddle management is exactly the kind of repetitive attention that eats an operator's shift. Automatic timed cycling, set per tank, removes that chore — in principle.

How it works

Each tank's screen runs a small timer-driven state machine: it counts down an "on" interval and an "off" interval and flips the agitator state, with the timer rows enabled only when the tank is in Automatic mode. The screens are carefully written to rebuild their timer when revisited, to avoid a crash on re-open.

Versus the old RS-360 system

RS-360 exposed agitator control through a per-tank form, and Ring's earlier 2026-05 audit had listed all four of Ring's agitator handlers as "TODO: send command to PLC" stubs — i.e., not finished. They are now full per-tank state-machine screens (roughly 320–390 lines each; tank 1 is the largest at 386).

Status & honest caveats

Likely questions & how to answer them

Keep operators productive through the switch — manual a click away, F1 cheat-sheet

What it is

Help that keeps operators moving during the changeover: the original RS-3000 PDF manual stays one click away, a Contact Us screen gives a clear support path, and pressing F1 brings up a cheat-sheet of the app's keyboard shortcuts.

Why it matters

The fear with any new system is that operators slow down while they learn it. Keeping the familiar manual within reach, giving a clear "who do I call," and surfacing the shortcuts means people pick up the new screen without losing speed.

How it works

The Help menu has the manual, Contact Us, and (hidden for now) an About entry. "Contents" opens the legacy manual PDF by searching a few likely locations on disk and launching it. Contact Us is a simple content screen. App-wide, pressing F1 opens an in-window overlay listing the shortcuts (Ctrl+B, F1, Esc, Enter, Alt+F4).

Versus the old RS-360 system

RS-360 had a Help Contents entry for the manual, but no in-app keyboard-shortcut help and no Contact Us screen. Ring keeps the manual one click away and adds the F1 shortcuts overlay and the Contact Us path.

Status & honest caveats

Likely questions & how to answer them

A home screen shaped by what operators actually glance at

What it is

The Ring home screen is built around what operators really look at, not a designer's guess. A real operator stood in front of both the old and new screens side by side and pointed out the six things the old main screen shows at a glance. All six are now on the Ring home screen — and the design keeps evolving from that kind of floor observation.

Why it matters

A home screen that matches what operators already scan every hour means zero relearning of the most-used view. It is also a strong sale story: the layout came from an actual operator at the plant, not a slide deck.

How it works

The six field-observed items are: the current formula, the make-ready tank weight, the borax/caustic weight, the ingredient-addition progress, the mix-time progress, and the mix-time-remaining countdown. All six are now bound on the dashboard to data Ring was already polling — so adding them was a layout change with zero new PLC reads. The home screen went from showing two of the six to all six.

Versus the old RS-360 system

Give the old system its due here — this is a balanced contrast, which makes it credible. RS-360 docks a comms / run-hold / alarm status bar on every screen and keeps a live 17-row formula step table always visible. But that table forgets every step's duration the instant it scrolls off. Ring gives at-a-glance batch and alarm awareness shaped by the floor, and Ring can persist the step durations the legacy throws away.

Status & honest caveats

Likely questions & how to answer them

Chapter 6 — Own Your Data, on a Platform Built to Last

Every production run your plant makes — every batch of glue, every alarm, every drum of starch consumed — leaves a record. The question this chapter answers is a simple one a buyer will press hard on: who owns those records, can you actually get at them, and will the software that holds them survive the next ten years of power blips, upgrades, and staff changes? Two terms before we start. The PLC (Programmable Logic Controller) is the Allen-Bradley industrial computer that physically runs the valves, pumps, and mixer — Ring does not change it. The HMI (Human-Machine Interface) is the operator's screen — that is what Ring is, the replacement for the old 2002 DOS-era "RS-360" screen. A batch is one production run of one glue recipe.

The floor problem is this. The old RS-360 system did keep history — batch headers, step records, shift summaries, alarm logs — but it stored them in a long-dead database format called Paradox, reachable only through an abandoned 32-bit Borland Database Engine ("BDE") that has no maintained driver. In practice that means the data sits locked in a 2002 vault: no living "historian" (a system that continuously records readings over time), no trends, no cost figures, no step-by-step timing, no equipment-runtime stats, and no way for a supervisor to search it. Getting the live plant's own data out required writing a brand-new reader from scratch. So the honest distinction is not "the old system recorded nothing" — it is "the old system recorded plenty, then sealed it where nobody can use it."

Ring's answer is to put all of that in SQLite — a single, open, standard database file (think of one self-contained file, like a spreadsheet, that any free tool can open) — and then wrap it in the kind of engineering that keeps an industrial PC running unattended for months. This chapter covers the data store itself and the under-the-hood engineering that makes it trustworthy.

One honesty rule that runs through this whole chapter, because a controls engineer will test it: on-site, Ring read 133 of 133 live PLC values without issuing a single command that could change the process. Reading does send small network request packets — so never claim "zero bytes." The correct, defensible claim is zero write commands: every instruction that could move a valve or change the running plant is suppressed by a read-only safety gate.

A few more terms you will meet below, each defined where it first appears: a tag is a single named value inside the PLC (like "Tank 2 level"); a table is one named list of records inside the database (like the "Batch" table); a migration is an automatic, ordered upgrade to the database's structure; and WAL is a journaling mode that protects the database through a power cut.

---

Own all your plant data in one open file, with no vendor in the loop

What it is

All of Ring's data — batches, alarms, inventory, recipes, shifts, costs, maintenance, email logs — lives in one SQLite database file on the plant PC. SQLite is a free, open, widely used database format; the whole thing is a single file you can copy to a USB stick, back up, email, or open with any free SQLite viewer. There is no proprietary engine and no vendor you must call to read your own records.

Why it matters

When an auditor, a plant manager, or a prospective buyer of your business says "show me your data," you answer on the spot by handing over one file. You are not dependent on a software vendor staying in business, returning your call, or selling you a license to see records you generated. You own them outright.

How it works

On first run, Ring builds roughly 40 well-structured tables (Batch, AlarmDefinitions, AlarmLifecycle, IngredientUsage, InventorySnapshots, FormulaSteps, ShiftDefinition, ProcessHistory, EquipmentRuntime, IngredientCost, and more). Each table is guarded by rules that keep bad data out — for example, an alarm's severity can only be "A" (alarm) or "W" (warning), nothing else. All of it runs on the standard System.Data.SQLite library, an open format any free SQLite tool can read.

Versus the old RS-360 system

RS-360 traps the same kinds of data across many Paradox tables, each one split into a quartet of files, reachable only through the deprecated 32-bit Borland Database Engine, with no maintained driver. Because no maintained, supportable BDE/ODBC path remains, even pulling the live plant's own data out required writing a from-scratch pure-.NET Paradox reader. Ring keeps everything in one inspectable file readable by any free SQLite tool.

Status & honest caveats

Likely questions & how to answer them

---

Self-service backups, a checked restore, and one-click Excel exports

What it is

Three things you can do yourself, with no vendor and no special tooling: back up the whole database while the app is still running, restore from a backup that Ring checks before trusting, and export any table to a spreadsheet (CSV — the standard format Excel opens) in one click.

Why it matters

Backups are your insurance for cutover day and for any future hotfix. The checked restore means you are not trusting a backup blindly — Ring checks it is sound before you rely on it. And the export means "send me this in Excel" is answered in seconds, not by a callout.

How it works

Backups use SQLite's online backup feature, so they capture a consistent snapshot while the app runs — no shutdown required. Before a restore, Ring runs an integrity check plus a presence check of core startup tables, takes an automatic safety copy of the current database first, then swaps files and cleans up leftover temporary files. Exports use a defined per-table column catalog with an optional date-range filter, covering Batch, Ingredient Usage, Alarm History, Shift, Inventory and more, with a table-and-column picker. PDF reports are built from the same database.

Versus the old RS-360 system

RS-360 gives you no built-in backup or restore at all; its reporting is print-outs from an abandoned report component, over data locked in the dead engine and awkward to extract. Ring gives you the familiar report-export workflow but over an open, portable store, backed by a checked restore the old system never had.

Status & honest caveats

Likely questions & how to answer them

---

Keep the batch you just finished through a power blip — and never freeze under load

What it is

Two durability guarantees that run automatically on every database connection. First, a sudden power loss will not cost you the batch you just completed. Second, the plant PC keeps responding even when several screens are reading and writing the database at the same time — nobody waits on a frozen screen mid-shift.

Why it matters

A night-shift power blip or a busy moment where the dashboard, batch screen, trending, and alarms all hit the database at once are exactly when an industrial system must not lose data or lock up. This removes both fears.

How it works

Every time Ring opens the database it applies three settings: a 15-second busy-timeout (so concurrent access waits its turn instead of throwing a "database is locked" error), WAL journaling mode — Write-Ahead Logging, which lets many readers and one writer work at once — and a deliberate "FULL" durability override that forces each save to be physically flushed to disk. That last setting trades a little write speed for the guarantee that committed records survive a power loss, which is the right trade for a plant PC. These settings apply uniformly across every part of the app.

Versus the old RS-360 system

Paradox/BDE gives you no WAL, no documented concurrency guarantees, and a corruption-prone store — recovering a corrupted table during a night-shift line stop is a genuine hazard. Ring runs WAL concurrency with a busy timeout and full flush-on-commit durability, so commits survive power loss.

Status & honest caveats

Likely questions & how to answer them

---

Upgrade without a database expert — and an interrupted upgrade never corrupts your history

What it is

When you install a new version of Ring, the database upgrades its own structure automatically and safely — no database administrator, no manual scripts. It tracks a version number, applies only the new changes in order, and is built so that a power cut mid-upgrade rolls back or safely re-runs rather than leaving a half-broken database.

Why it matters

Software will get updated over the plant's life. Without this, every update is a risk: a botched or interrupted upgrade could corrupt years of history, and you would need a specialist on hand. This makes upgrades a drop-in you can trust.

How it works

The database stores a version number. On startup, Ring reads it and applies each pending change (called a migration) in ascending order, then stamps the new version. The chain currently runs from version 1 through version 18 — adding operator identity, the cost module, alarm-email rules, process history, equipment runtime, maintenance, batch notes, and more. Each step wraps its structural change and its version stamp together in a single savepoint (a database checkpoint it can roll back to), so a crash mid-step undoes both together rather than leaving the version number and the structure out of sync.

Versus the old RS-360 system

RS-360 has no version concept and no migration mechanism. Its table structure is frozen in the 2002 build; any change means hand-editing tables in a dead toolchain with no rollback safety. Ring's schema versions itself, applies only the new deltas, and wraps each step so it rolls back or safely re-runs.

Status & honest caveats

Likely questions & how to answer them

---

Inventory totals you can trust, even after a controller reset

What it is

Inventory numbers that stay accurate. Ring never double-counts a repeated signal from the PLC, and — crucially — it never silently drops a genuinely new record after the controller is power-cycled. Your starch, caustic, and borax usage matches what the plant actually consumed.

Why it matters

Inventory drives reordering and costing. A silent under-count is the worst kind of error because nobody notices until stock runs short or the numbers don't reconcile. This closes a specific trap where a controller reset could have quietly dropped records forever.

How it works

Each inventory snapshot the PLC reports carries a counter value. The PLC's counter wraps back to a low number at 32,767, and a controller power-cycle restarts it too — so without care, a brand-new snapshot could look identical to an old one and get thrown away while the system still told the PLC "got it," losing the record. Ring's fix (migration version 7) makes each record unique on the combination of its counter plus the PLC's own event timestamp. A true repeat has the same timestamp and is correctly ignored; a post-reset record has a different timestamp and is correctly kept. The rebuild only runs if the old design is detected, preserves all existing rows, and runs inside a savepoint so an interrupted rebuild can't leave the table missing.

Versus the old RS-360 system

RS-360's Paradox inventory tables have no equivalent notify/acknowledge protocol or wrap-aware deduplication in the extracted code; correctness leaned on the 2002 engine and logic with no recovery tooling. Ring uses a timestamp-aware uniqueness rule that tells a real new record from a reset collision, so totals stay correct across power cycles.

Status & honest caveats

Likely questions & how to answer them

---

Your tank, ingredient, and recipe names — and language — stay put forever

What it is

When you rename a tank, an ingredient, or a recipe — and when you choose the operating language — those names and that choice are remembered in the database. They survive reinstalls and rebuilds, and they update live across every open screen instead of getting lost.

Why it matters

On the floor, the plant's own names ("Voorraadtank," "Doseertank") are how operators navigate. If a reinstall or a build wiped them, you'd be re-typing them and risking mistakes. Storing them in the database means they stick, and a software rebuild that wipes local config files can't reset your language or names.

How it works

Tank, group, and recipe names live in dedicated database tables that update-in-place and then notify open screens to refresh live. The chosen language and first-run-wizard status live in a generic settings table inside the database — placed there precisely because a rebuild wipes the local config file but never the database. All these reads are failure-safe: if anything is missing they return a sensible fallback rather than crashing the startup.

Versus the old RS-360 system

RS-360 scatters these names across flat INI/text files and Paradox tables, fixes language per-install via a code-page file with no live refresh, and spends thousands of lines on config-file marshalling alone. Ring keeps the names and language in the database with live cross-screen refresh and failure-safe reads.

Status & honest caveats

Likely questions & how to answer them

---

A glance-from-15-feet look, designed to re-skin by swapping one file — for screens already migrated

What it is

One consistent visual language across the HMI — colors, spacing, buttons, status indicators — defined once with meaningful names like "danger" and "surface" rather than scattered hard-coded color codes. Because the look is centralized, screens built on it could be re-skinned (for example into a dark control-room theme) by swapping one definition file rather than rewriting every screen.

Why it matters

An operator reading a screen from 15 feet away needs calm, consistent numerals and state colors, with saturated red reserved for genuine live danger. Defining the look in one place means a future restyle is a config change for those screens, not a line-by-line rewrite, and the look stays consistent as new screens are added.

How it works

Ring loads its visual styles in a strict, documented order, ending with a self-contained semantic token layer — a single file that defines the named colors and styles (Surface, Card, Accent, Success, Warn, Danger) and the type, spacing, and component styles every migrated screen draws from. It's built on the MahApps.Metro UI toolkit, with an app-wide fix for a known button-text clipping issue.

Versus the old RS-360 system

RS-360 is a 2002 fixed-pixel design with hand-built per-tank menus and no design system — each screen styled on its own. Ring centralizes the visual language into a single named token source that the migrated screens share.

Status & honest caveats

Likely questions & how to answer them

---

Fixes and features arrive sooner, with a contained blast radius

What it is

The app is assembled from many small, swappable building blocks rather than one giant tangled program. An engineer can replace or fix one block — say an email rule or an alarm channel — without disturbing the rest, so changes ship faster and with less risk of breaking something unrelated.

Why it matters

Over the plant's life you'll want fixes and new features. In a tangled program, every change risks rippling somewhere unexpected. This architecture keeps the "blast radius" of any change contained, which means lower-risk, faster delivery — and it doesn't lock you to one developer.

How it works

Ring uses a standard dependency-injection container (a Microsoft library that wires the building blocks together). At startup it registers the whole graph — 39 data-access blocks (one per table area), plus logging, configuration, alarm escalation, email delivery, the historian, and more — behind named interfaces, so any one can be swapped for another without touching the screens. The layering is a clean separation of screens, services, and data access.

Versus the old RS-360 system

RS-360 wired screens straight to database columns and used shared-memory communication across 21 interdependent sub-programs — a wide blast radius where a change anywhere could ripple anywhere, with no service abstraction. Ring wires interfaces through a real container, so blocks are swappable and the blast radius is contained.

Status & honest caveats

Likely questions & how to answer them

---

A screen that never freezes, and data that holds up to a security audit

What it is

Two things. First, the display stays responsive no matter how busy the PLC is, because talking to the controller always happens on background workers, never on the screen's own thread. Second, the data stands up to a security audit because every database query uses safe parameterized commands — values are passed separately from the query text, so malformed or malicious input can't corrupt or expose data.

Why it matters

A frozen HMI mid-shift is dangerous and erodes trust. And "could a bad value or an attacker break or read our data?" is a question a serious buyer's IT team will ask. This addresses both.

How it works

PLC reading runs on background timers that fill thread-safe snapshot holders; the screen reads those snapshots on its own gentle timer (every half-second to two seconds) and never touches the PLC directly. All pollers stop when the window closes, and a background timer self-recovers if the PLC or a network switch was still booting when Ring started — no operator has to click "Retry." On the data side, queries use parameterized commands throughout — a code scan found hundreds of parameterized bindings and only one harmless exception, and the security review rated every repository clean.

Versus the old RS-360 system

RS-360 wired screens straight to database columns over the old engine with bespoke communication and shared memory, with no documented threading model or query-safety discipline, and a data engine with no concurrency guarantees. Ring uses a documented background-snapshot model and uniformly parameterized queries, audited clean.

Status & honest caveats

Likely questions & how to answer them

---

Faster, cheaper support — and months of unattended 24/7 uptime

What it is

On the rare crash, the app writes a small forensic report to disk first, captured from three different kinds of failure, so support can diagnose it fast and cheap. And the operator's screen doesn't slow during a long stretch of PLC outages, because logging is built to never block the screen — and the app even repairs its own log folder if someone deletes it, so it runs for months unattended.

Why it matters

An HMI runs around the clock. When something rare goes wrong, the difference between "we have a forensic file" and "we have nothing" is the difference between a quick fix and an expensive guessing game. And a logger that quietly dies or drags down the screen during an outage storm undermines exactly the reliability you bought it for.

How it works

A crash logger installs first thing at startup and hooks the three ways a .NET app can fail, writing one small file per crash to a crashes folder — while still letting the operating system's own dialog fire. Logging itself runs on a background writer draining a capped queue, so the screen's hot paths just hand off a line and move on, even during a PLC backoff storm; logs rotate at 10MB with backups, and the logger self-heals a deleted log directory. A UI-hang sentinel watches for the screen thread stalling.

Versus the old RS-360 system

RS-360 offers a communication log and disk logging but no modern instrumentation and no crash-report pipeline — no documented async self-healing logger and no hang sentinel. Ring adds three-hook crash capture, an async self-healing logger, and a UI-hang sentinel.

Status & honest caveats

Likely questions & how to answer them

---

No second copy fighting for the PLC, and clear guidance when one is frozen

What it is

You can't accidentally end up with two copies of Ring fighting over the same PLC and database. Double-click the icon when Ring is already running and it brings the running copy to the front instead of opening a second one. If the running copy is frozen, it tells you the exact process to end rather than silently doing nothing.

Why it matters

Two instances driving the same controller and writing the same database is a "split-brain" hazard that can corrupt data or double-send commands. And the common real-world frustration — "I double-clicked and nothing happened" — is replaced with a clear instruction.

How it works

At startup, before any database or PLC connection, Ring claims a named system-wide lock. A second launch detects the running copy and checks whether its window is responsive: if healthy, it focuses that window and exits quietly; if frozen or windowless, it shows a message naming the exact process number to end, and exits with a distinct code a watchdog can read. Because this runs before any database or PLC connection, a duplicate can never open a second database handle or a competing poller.

Versus the old RS-360 system

No equivalent guard is documented in the legacy stack; this behavior — and the distinct exit codes for an automated watchdog — is part of the modern robustness layer RS-360 lacks. Ring adds a hardened guard that distinguishes a healthy from a wedged instance and tells the operator what to do.

Status & honest caveats

Likely questions & how to answer them

---

Any .NET contractor can build it, and every release is checksum-verifiable

What it is

You are never locked to one developer's machine. The whole app builds with standard, freely available Microsoft tools; the screen layouts are plain text files an engineer can read, compare, and review like any other code; and a packaging script produces a release plus a checksum (a fingerprint that proves a file wasn't altered) so you know exactly what you're installing.

Why it matters

Software you can't rebuild is a hostage situation. If your developer disappears, you need any competent contractor to pick it up, build it, review changes, and ship a verified release. This guarantees that, and the checksum reduces the risk of installing the wrong or tampered build.

How it works

The project uses a standard, classic-style build with pinned package versions (every dependency locked to an exact version) and a deterministic compiler setting, built with the standard Microsoft build tools. A release script stages the build, zips it, and emits a per-file SHA-256 checksum manifest (SHA-256 is a standard fingerprinting algorithm). Helper scripts cover watchdog and crash-dump deployment. The screen layouts are text files you can compare line-by-line.

Versus the old RS-360 system

RS-360 has no build documentation and no automated build pipeline; its project files hardcode one developer's absolute folder paths, and its forms are dozens of binary files you cannot compare line-by-line — so rebuilding means reconstructing a 2002 machine. Ring uses standard build tools, pinned packages, text layouts you can diff, and a checksummed release.

Status & honest caveats

Likely questions & how to answer them

Chapter 7 — A Reliable, Honest Connection to the Controller

Every feature in this chapter is about one thing: the link between the operator's screen and the controller that actually runs the plant. Two pieces of vocabulary you must be comfortable saying out loud. The PLC (Programmable Logic Controller) is the rugged industrial computer that physically opens valves, runs pumps, and drives the mixer — it is the plant's brain, and Ring does not change a line of its program. The HMI (Human-Machine Interface) is the operator's screen — and that is what Ring is. Ring is a brand-new HMI that talks to the same untouched Allen-Bradley CompactLogix PLC the old 2002 screen, "RS-360," used to talk to. We replaced the window, not the brain behind it.

The real floor problem is trust in what that window shows. An HMI is just a viewer; it reads values out of the PLC and paints them. The dangerous failure is not a screen that goes blank — everyone notices that. It is a screen that keeps showing a number that looks live but is actually frozen, while the operator makes a real decision on it. A second floor problem is the morning ritual: after a power blip the old screen often had to be restarted by hand before anyone could see the plant. This chapter's features attack both problems — they make the connection honest about its own health, and resilient enough to heal itself.

A few more terms you'll meet below, defined once. A tag is a named value living inside the PLC (for example, a tank level). A heartbeat is a special counter inside the PLC that ticks upward only while the control program is actually running — a frozen program stops ticking. EtherNet/IP is the modern, open, industry-standard language Allen-Bradley controllers speak over ordinary Ethernet network cable. Read-only mode is a master safety switch in Ring that blocks every command to the controller, so the screen can watch the live plant without being able to change it.

One honesty rule that governs this whole chapter, because a sharp engineer will test it: when Ring "reads" the plant it does send small request messages over the network (that is how reading works on any system). What read-only mode blocks is write commands — anything that could change the process. So we never say "zero bytes." We say "zero write commands," and that is exactly true: on-site on 2026-06-10, Ring read 133 of 133 live tags and issued nothing that could move a valve.

Knowing the difference between unplugged, frozen, and running

What it is

A simple connection light has only two states: green (connected) or red (disconnected). Ring's status is smarter. By watching the PLC's heartbeat counter, Ring can tell apart three genuinely different situations and name each one in plain English on an always-visible status banner: unplugged (the controller isn't answering at all), frozen / wedged (the controller answers the network but its control program has stopped, so the heartbeat is stuck), and running (answering and the heartbeat is ticking up). It also has a short "stale" grace state for a momentary hiccup, so a one-second blip doesn't trigger a false alarm.

Why it matters

The most dangerous case on any plant floor is the middle one: the network is perfectly healthy, so a naive screen stays green, but the control program has actually halted and every number on the screen is silently frozen. Ring calls that out by name ("PLC reachable but heartbeat stopped — controller logic not running") instead of showing a comforting green light. The flip side is fewer wasted maintenance calls: when the heartbeat is genuinely ticking, Ring says so, so nobody gets dispatched to chase a "PLC is down" that isn't.

How it works

Inside Ring a small piece of always-on logic (a "state machine" — it's always in exactly one named state and moves between them by fixed rules) checks the heartbeat value about once a second. If the value changed since last time, the state is "Connected." If it answered but the value is unchanged for more than 4 seconds it goes "Stale," and past 12 seconds "Starved" (reachable but wedged). If nothing answers at all for 12 seconds, or three reads in a row fail, it goes "Disconnected." All of that timing runs off a forward-only stopwatch, not the wall clock, so someone changing the PLC's date/time mid-batch cannot trick Ring into hiding a real comms loss.

Versus the old RS-360 system

Be careful and precise here, because this is the one place an original author can push back. The old RS-360 was not blind to a frozen heartbeat — its comms module did flip a heartbeat indicator to "not OK" when the counter stuck, and even had a yellow transitional color. So do not claim the old screen "had no liveness model" or "let operators trust numbers that were already dead." Ring's honest, defensible advantage is that it separates "unplugged" from "frozen" by name where the legacy collapsed both into a single binary OK/not-OK; it adds the 4-second blip tolerance; it runs the timing on a tamper-proof forward-only clock; and — uniquely — it uses that state to actively block commands, not just to color a light.

Status & honest caveats

Likely questions & how to answer them

Commands only reach a controller that's provably alive

What it is

This is a background safety rule, not a screen. Even when Ring is allowed to send commands, it will only actually send one if it has just confirmed the controller is fully running. If the heartbeat so much as hesitates, the command waits rather than firing into a possibly-frozen controller. Crucially, reading the plant uses a more forgiving rule than writing to it, so the screen keeps updating smoothly through a tiny blip while commands stay strictly protected.

Why it matters

A command sent into a wedged or transitioning controller can be lost or misapplied — a batch start, a formula selection, a setpoint, an agitator command, an alarm silence. By refusing to write unless the controller is demonstrably running, Ring guarantees that commands land only where they can actually be acted on. And because reads use the looser rule, the screen doesn't flicker to "disconnected" every time the network twitches.

How it works

There are two deliberately different gates. The read gate allows polling in either "Connected" or the brief "Stale" state — a 4-to-12-second blip must not freeze every value on the screen (an earlier version had a bug where one hiccup froze all readings during a live batch). The write gate is stricter: it allows a command only in the full "Connected" state, because "Stale" is not proof the controller's program is advancing. That one difference — permissive reads, strict writes — is the load-bearing safety rule, and it's enforced at the single point where Ring would actually send a command.

Versus the old RS-360 system

The legacy screen's heartbeat status was, as far as we can tell, used for display — it did not gate writes on a verified-advancing scan, so in principle a command could be issued toward a controller that wasn't actually running its program. Ring turns liveness from a light into an enforced precondition: it writes only when the controller is provably alive, and that guarantee is kept separate from the more relaxed read rule.

Status & honest caveats

Likely questions & how to answer them

A stale number never poses as a live one

What it is

Ring refuses to display an old, frozen reading as if it were current. If the controller stops answering, or only partly answers, the affected numbers are flagged as out-of-date — on the live tank cards a value that's gone stale visibly blanks out to a dash ("—") instead of sitting there looking fresh and green. The screen would rather show you "I don't currently know" than a confident lie.

Why it matters

The worst operator decision is one made on data that looks current but is minutes old. Tank levels, weights, temperatures, step state — if any of those silently freeze during a comms outage and keep displaying, an operator can act on a dead number. This feature removes that trap: the numbers are either genuinely current or visibly marked stale.

How it works

Each batch of readings Ring takes is stamped with the exact time it was captured and is never edited afterward. When Ring asks the consumer screens "is this fresh enough?", it answers using that capture time against a freshness window. The important fix is in the failure path: if the big bulk read of the controller's data array fails, Ring falls back to reading just the low-numbered values individually — and if every one of those also fails, it reports the read as failed and does not re-stamp the old cached values with a fresh timestamp. It also tracks the case where only the low values refreshed, so any screen relying on a higher-numbered value (such as the inventory-update word) correctly still sees it as stale.

Versus the old RS-360 system

A legacy HMI that simply caches the last reading and keeps painting it has no concept of per-field freshness. It's fair to say the old system had a system-wide comm OK/not-OK status — so phrase the contrast as "no per-tag freshness," not "no notion of staleness at all." Ring adds field-by-field freshness and a poller that flatly refuses to re-stamp old data as new — an explicit defense against exactly the frozen-but-live-looking trap.

Status & honest caveats

Likely questions & how to answer them

It reconnects itself — no morning restart

What it is

If Ring starts before the PLC is ready — common first thing in the morning or after a power blip — or if the network drops, Ring keeps quietly re-checking and reconnects on its own the moment the controller comes back, with no operator clicks. There's also a "Retry now" button on the status banner to force an immediate attempt.

Why it matters

It kills the morning ritual and the help-desk call. The old pattern was: plant powers up, the screen came up before the controller was reachable, and someone had to restart the HMI by hand to get the plant back on screen. Ring just comes back by itself when comms return — set-and-forget reliability.

How it works

At startup Ring quietly tests whether it can reach the PLC over the network, and it does this off the part of the program that paints the screen, so the window never freezes while it tries. If the controller isn't reachable, Ring schedules a background timer that re-runs the exact same connect-and-start sequence roughly every 30 seconds until it succeeds, then shuts that timer off. Overlapping attempts are prevented, and the "Retry now" banner button runs the identical path on demand. A subtle crash that an abandoned connection attempt used to cause has been closed off.

Versus the old RS-360 system

Honesty matters here, because the original copy overstated it. Do not claim RS-360 did "one startup probe then gave up" — its comms module actually ran a continuous timer that kept re-checking the driver, the link, and the heartbeat every tick. So the legacy was monitoring continuously, not abandoning the connection. The honest, still-valuable framing: Ring fixes the morning-restart ritual with proven, code-verified self-healing logic — present it as Ring's reliability, not as something the old system provably lacked.

Status & honest caveats

Likely questions & how to answer them

Catching a frozen screen before it fools anyone

What it is

A background watchdog inside Ring continually checks that the display itself is still responsive. If the screen ever locks up — keeps showing old data but stops actually updating — for a full minute, Ring detects it and writes a forensic record of the freeze. The goal is to make sure a hung screen is caught and diagnosable rather than silently misleading an operator.

Why it matters

A frozen HMI that still shows plausible-looking numbers is the worst kind of failure, because nobody knows it happened until someone notices nothing is changing. This watchdog turns that silent failure into a detected, recorded event — giving the plant a forensic trail and a defined path toward automatic recovery.

How it works

A background timer posts a tiny "are you alive?" ping to the screen's drawing thread every 5 seconds; that thread records the ping only when it actually runs it. If the gap between recorded pings ever exceeds 60 seconds, the screen thread is wedged — the pings keep being sent but stop getting answered — and the watchdog writes a single, deduplicated hang report capturing how long the freeze lasted and what the screen was doing. The gap math is written to be immune to the timer counter wrapping around. By deliberate choice it is log-only today: an auto-restart wrapper script exists, but the automatic kill-and-restart is left switched off until that wrapper is verified on the actual plant computer.

Versus the old RS-360 system

The old single-threaded 2002 Windows HMI had no way to monitor its own responsiveness, so a hung legacy screen was a manual-discovery event — found only when someone noticed nothing was moving. That contrast is fair. Ring adds an internal sentinel that converts that silent failure into a detected, recorded one, with a staged path to automatic recovery.

Status & honest caveats

Likely questions & how to answer them

An open, watchable link to the controller

What it is

Ring talks to the PLC using a modern, open, widely-supported software library over standard Ethernet, instead of a closed vendor-specific driver wired into the old screen. And every read and write between Ring and the controller can be watched live in a monitor and saved to a daily log — so an engineer can see exactly what's flowing to and from the PLC.

Why it matters

Two wins. First, you shed a proprietary dependency: the old screen's controller link was a closed component you'd have to keep alive forever. Ring uses an open, well-maintained standard you can support with ordinary skills and tooling. Second, total visibility: when something looks wrong, maintenance can open a live tail of every message to the controller and a saved daily record, rather than guessing.

How it works

Ring uses libplctag — a popular open-source library — to speak EtherNet/IP (the open Allen-Bradley network protocol) directly to the CompactLogix controller, with no proprietary middle-man software. A logging service keeps the most recent 500 messages in memory for the live monitor and can also write a per-day file to disk; those disk writes happen off the controller-communication path so they never slow it down, old logs are pruned automatically, and any logging error is swallowed so it can never disrupt a controller call. Notably, even suppressed writes (the ones read-only mode blocks) are logged — so the monitor shows you exactly what Ring would have sent.

Versus the old RS-360 system

Use the corrected wording — the original copy was wrong on the specifics and a controls engineer would catch it. The old RS-360 reaches the CompactLogix through its built-in Borland ActiveX/OCX comms module (called ASABTCP) over Ethernet — an ActiveX/OCX is a closed, plug-in Windows software component bolted into the program. It carries old SLC-500-era "mirror" tag arrays kept alive purely as compatibility shims from the plant's earlier controller generation. It is not a DOS-era driver, not separate helper programs, and not the old DH+ network for the live link. Ring replaces that closed driver with the open libplctag EtherNet/IP stack and re-implements the comm monitor with batched, retention-managed logging plus visibility into suppressed writes.

Status & honest caveats

Likely questions & how to answer them

Riding out an outage without flooding the network

What it is

When the PLC isn't answering, Ring doesn't hammer the network or spam errors — it automatically slows its polling down, then speeds back up the instant the controller responds. At startup it deliberately spaces out its connections so it doesn't overwhelm a small controller, and it runs cleanly with no PLC attached at all, for office demos or operator training.

Why it matters

An HMI that retries aggressively during an outage creates an error storm and can overload a modest controller — making a bad situation worse and harder to diagnose. Ring stays quiet and stable through an outage, recovers to full speed automatically the moment comms return, and can be run completely PLC-free for demos and training without errors.

How it works

After a couple of failed read cycles, each poller backs off — slowing the heartbeat check from about 1.5 seconds to 5, the fast snapshot from half a second to 5, and the big data block from 5 seconds to 8 — and it restores fast speed on the very next success. At startup a single coordinator staggers the seven per-tank pollers' first reads about 150 milliseconds apart, so they don't all open network connections at once; that matters because a CompactLogix controller of this class only allows a handful of simultaneous network sessions, and a sudden pile-up can briefly exhaust that limit (a known, self-recovering condition). The coordinator also skips a tick if the previous read is still running, and a shutdown timing bug that could leak errors during reconnects has been closed.

Versus the old RS-360 system

Phrase this one as a centralization win, not as a flat claim that the old system had none — it's an absence-of-evidence point. We found no documented adaptive backoff, startup staggering, or no-PLC graceful start in the monolithic legacy HMI. Ring's contribution is concrete and defensible: one coordinator that centralizes start/stop, cadence, and recovery for all the pollers — something the old single-block design didn't offer.

Status & honest caveats

Likely questions & how to answer them

Chapter 8 — Why Replace It Now

Before the feature list, get the one idea that holds this whole chapter together: the old system is not broken today, and that is exactly the argument. A quick vocabulary check first, because everything below depends on it. The PLC (programmable logic controller) is the rugged industrial computer bolted in the panel that physically opens the valves, runs the pumps, and drives the mixer. The HMI (human-machine interface) is the operator screen people actually touch — it shows what the PLC is doing and sends the operator's button-presses to it. RS-360 is the 2002 HMI you run now. Ring (full name Ring RS3000) is the new HMI that replaces RS-360 while leaving the PLC completely untouched. A batch is one production run of one glue recipe. Your plant makes corrugating adhesive — industrial starch glue for cardboard — and it has run about 1,404 batches' worth of history.

The real floor problem this chapter addresses is not a bug. It is a single point of failure that gets quietly riskier every month. RS-360 is written in a programming tool from 2002 that you can no longer buy, patch, or hire for; its data sits in a database format no current software can open; and the whole thing can only be rebuilt on one specific old developer's PC with instructions that exist nowhere. It keeps running only because nothing has forced it to change. The day something does force a change — a dead hard drive, a Windows update, a corrupted file, or the one developer who knew it retiring — you would be doing emergency surgery on a 24-year-old system with no vendor to call.

"Why now" is the answer to that. Replacing it while it still works means you do it calmly, on your schedule, screen by screen, with the old system still installed and parked as a fallback — instead of in a panic after it has already failed. Everything in this chapter is a piece of that argument: get off the dead toolchain, get your data into a format you own, and make the system maintainable by any ordinary contractor.

One honest framing note that runs through the chapter: most of these are platform and business-case arguments, not individual screens you click. That is not a weakness — it is the point — but it means the right answer to "show me that on the screen" is sometimes "this one isn't a screen, it's the foundation under all of them," and you should say so plainly.

Buy out your single point of failure before it forces your hand

What it is

This is the headline reason to move: you are removing the biggest hidden risk in the plant — a control screen built on tools that no longer have a maker, a buyer, or a support line — and doing it now, on a calm schedule, instead of after a failure forces a rescue. Because the old screen still runs the line today, this is insurance, not a fire drill.

Why it matters

A plant can tolerate a slow, clunky system. What it cannot tolerate is a system that one day simply stops and cannot be rebuilt. RS-360 is one retirement, one disk failure, or one breaking Windows update away from that situation, and there is no vendor anywhere to call. Buying the replacement while the line is still running converts an open-ended emergency into a planned project.

How it works

RS-360 is locked to Borland C++ Builder 6, a programming tool released in 2002 with no security updates and no successor. Its screens are built with VCL (Borland's visual component library) and its reports with QuickReport, both long abandoned. Its settings live in INI files — plain-text configuration files — that are read and written by sprawling hand-written C++ code; the single module that handles that INI logic, CommINI.cpp, is about 7,466 lines on its own. Ring replaces all of that with mainstream, still-supported software: Microsoft .NET 4.7.2 and WPF (the modern Windows screen-building framework), styled with the widely-used MahApps.Metro library, organized in a clean, standard structure (the "MVVM + Services + Repository" pattern — just the conventional way modern apps separate the screen, the logic, and the data). The move is done one screen at a time so it stays controlled and reversible.

Versus the old RS-360 system

Old: an end-of-life toolchain, a corruption-prone deprecated database, a build that cannot be reproduced, and a shrinking pool of people who even know these 2002 tools — it works only because it has not had to change, and changing it gets harder and riskier every month. New: mainstream, widely-supported software and an open database on a build any modern shop can reproduce, cut over deliberately with the legacy app left installed and parked, and a documented rollback checklist with a ~10-minute target if switchover day goes sideways.

Status & honest caveats

Likely questions & how to answer them

Own your recipes, batch history, and alarms instead of leaving them trapped in a dead database

What it is

Your recipes, your batch history, and your alarm log currently live inside a 2002 database format that no current tool can open and that can corrupt silently with no recovery path. Ring's data instead lives in an open, single-file database you can read, back up, and export yourself — so a night-shift line stop never turns into permanent data loss.

Why it matters

Plant data is the plant's memory: what we made, when, how much, and what went wrong. Today that memory is locked in a format that is awkward to read and prone to silent corruption, with no vendor to recover it. Owning your data in a portable, inspectable format means an auditor's "show me your records" is answerable, and a database hiccup is a backup-restore, not a catastrophe.

How it works

The legacy data is stored in Paradox .DB files — a 1990s database format — that, in normal operation, the old app reaches only through the Borland Database Engine (BDE), deprecated middleware (a go-between driver) that Microsoft's modern Windows no longer ships and nobody maintains. To even get the data out, the team had to write a brand-new reader from scratch in modern code (PdxReader.cs) that opens those files directly, byte by byte, without BDE, precisely because no maintained driver exists. Ring stores everything in SQLite — an open, single-file database used in billions of devices — running in WAL mode (write-ahead logging, a crash-safety setting that protects the file if power drops mid-write), with an integrity check on restore, a proper online backup, and a one-click export to CSV (the universal spreadsheet format) with a picker that lets you choose exactly which tables and columns to export. The export button is reachable from the navigation bar, so an operator can do it without a developer.

Versus the old RS-360 system

Here is the honest, corrected before/after — and it matters that you get this right, because a controls engineer who knows the old system will catch an overclaim instantly. The old system did keep batch, step, shift, and alarm history (1,404 batch headers, 16,776 step rows, 2,880 alarm records, 327 shift records were all pulled off-site). What it did not have was any safe, modern, openable home for that data: it is locked in a corruption-prone, dead Paradox/BDE format that needed a custom-written reader just to extract, with no maintained driver, no integrity checking, no continuous trend/time-series historian, no step-duration timeline, and no recovery tooling. Do not say "the old system recorded nothing" — that is false and easily disproven. The true and still-strong line is: "it kept the records, but trapped them in a dead engine you cannot safely open, back up, or recover, with no living trends, step timing, or operator-searchable access." Ring's side: portable single-file SQLite with WAL crash-safety, integrity check, online backup, and one-click CSV export with a column picker.

Status & honest caveats

Likely questions & how to answer them

Make changes any .NET contractor can do, not a 2002 build wired to one retiring PC

What it is

Today, changing RS-360 is wired to one person's 2002-vintage developer PC with no written rebuild instructions, which makes every change slow, expensive, and one resignation away from impossible. Ring is built with standard, current tools any competent .NET contractor can pick up and modify with confidence.

Why it matters

"Maintainability" sounds abstract until the day you need a small change — a new report, a tweaked screen — and discover the only person who can do it is gone and the build only exists on a dying machine. That is key-person risk and rebuild risk, and it quietly raises the cost and danger of every future change. Removing it means routine changes stay routine.

How it works

The legacy app is 21 interlocking sub-projects passing data through shared memory, totalling roughly 134 code files, 130 header files, and 97 screen-layout files — with two single files over 5,000 lines (the main form at ~5,647 lines and the INI handler at ~7,466). The project files hardcode one developer's exact folder paths (C:\Projects\CB6\RS360\..., with an even older C:\Projects\CB3\... reference still hanging around), and there is no README, no build document, and no automated build setup anywhere in the tree. On top of that, the great majority of the screen files — 88 of the 97 — are stored in Borland's binary IDE format, which can't be meaningfully compared, reviewed, or merged the way normal text can. Ring, by contrast, builds with Visual Studio 2022's MSBuild from XAML — the text format that describes WPF screens, which any developer can read, diff, and review — and ships with a production-readiness binder so a contractor knows exactly what they are looking at.

Versus the old RS-360 system

Old: no patch path and no second build environment — rebuilding realistically means reconstructing a specific 2002 IDE, the old database runtime, and third-party add-ons on one machine, and most of the screen files are binary-only so they can't be properly code-reviewed or merged. New: built with current Visual Studio tooling from diffable, reviewable text screen files, backed by a documented binder, so updates ship safely.

Status & honest caveats

Likely questions & how to answer them

Buy bounded, shrinking risk and stop paying for unbounded, growing risk

What it is

This is the business case stated honestly: you are trading an open-ended, growing liability (an unsupportable 2002 system) for a known, scoped one (a planned cutover with a short tail of remaining work). The pitch is deliberately conservative — it sells risk-avoidance and supportability today, not a productivity miracle — with no invented payback period, uptime figure, or customer count to erode your trust later.

Why it matters

Owners get pitched inflated ROI numbers constantly, and a sharp buyer punishes the first one that doesn't hold up. The strength here is the opposite: the case rests on a risk comparison anyone can see is true. Legacy risk is unbounded and growing — a database corruption with no recovery, a Windows update breaking an unpatchable runtime, the one developer retiring, none with a vendor to call. The new system's risk is bounded and shrinking — a known, catalogued cutover tail with remediation plans. That asymmetry is the close.

How it works

The case is laid out in the sales document's ROI/risk section. It deliberately avoids hard productivity claims and instead frames the value as risk avoidance: the dollars are the avoided cost of emergency Borland/database talent, the avoided cost of a Paradox recovery with no tooling, and a lower cost-per-change on a clean modern architecture versus surgery on binary legacy screens. The one external line item is quoted plainly and separately: the controller-side ladder-logic restoration ("ladder logic" is the program inside the PLC), estimated at roughly $5,000–$15,000 of engineer time, quoted precisely per site and kept separate from the HMI.

Versus the old RS-360 system

Old: the legacy platform's risk is the entire ROI argument — it cannot even produce a remediation list for itself, and emergency recovery has no vendor to call. New: the remaining work is catalogued with plans, and the one external line item is a precise, scoped quote, so you see a known number rather than a surprise.

Status & honest caveats

Likely questions & how to answer them

Verify every claim against the code before you sign

What it is

This is the trust mechanism: a complete positioning guide that ties every claim back to the actual code and audits, names the real gaps out loud, and forbids inventing numbers — so a technical buyer can check the pitch instead of taking it on faith.

Why it matters

A skeptical buyer or controls engineer assumes vendors overstate. The fastest way to win that person is to hand them the receipts and point out your own gaps before they find them. A pitch that survives verification closes; one that can't be checked invites suspicion of everything.

How it works

The guide is a ten-section playbook (executive summary, the "burning platform" case, a legacy-versus-Ring comparison table, top reasons to buy, value by stakeholder, the actual pitch, objection handling, the ROI/risk narrative, a one-page leave-behind, and honest positioning notes). Its final section explicitly separates what is shipped from what is roadmap, and proactively discloses the three real gaps: no per-operator named-user audit trail yet, the modern dark-theme visual pass deferred to the next version, and the controller-side process logic still needing a scoped cutover window. It also sets hard "do not" rules — no claimed uptime, ROI, payback, or customer count, and explicitly not claiming Ring is "already running a plant"; the truthful statement is that it was verified live against a controller at the bench. Every claim is cross-referenced to its grounding file.

Versus the old RS-360 system

Old: there is nothing to verify on the legacy side — no README, no build document, no collateral; the legacy tree is undocumented and locked inside the IDE and can't even produce a remediation list for itself. New: a grounded, code-cross-referenced positioning guide with an explicit gap list and "do not invent" rules, so a technical buyer can check the pitch against the source.

Status & honest caveats

Likely questions & how to answer them

Chapter 9 — Where the Work Honestly Stands

This chapter is the honesty ledger. Everywhere else in this guide we explain what Ring does; here we tell you plainly what is finished, what is half-finished, what is built but not yet switched on, and what is still an open question for your own team. The whole point of this section is that you can win a hard meeting by being the most candid person in the room, because every line below has been independently checked and your engineer can re-check it.

A few terms first, since the rest of the chapter leans on them. The PLC (Programmable Logic Controller) is the industrial computer that physically runs the valves, pumps, and mixer that make your glue. The HMI (Human-Machine Interface) is the operator screen — that screen is what Ring is. Ring replaces the 2002 DOS-era screen ("RS-360") but runs on the same untouched Allen-Bradley CompactLogix PLC; installing Ring does not change how your plant runs. A batch is one production run of one glue recipe. A tag is a single named value inside the PLC (a temperature, a valve state). The read-only gate is a safety switch (ReadOnlyMode=true) that suppresses every command Ring could send to the PLC, so Ring can watch the live plant without ever being able to change it.

One honesty rule that runs through this whole chapter: when Ring read the live plant, it read 133 of 133 values without issuing a single command that could change the process. Reading still sends small network request packets — so never claim "zero bytes" — but it sent zero write commands. That distinction is the kind of thing a skeptical engineer will test, so we get it exactly right.

The status the auditors gave Ring is GO-WITH-CONDITIONS: a strong replacement, cleared to go live behind a short, written list of fix-first items. That is deliberately not the same as "everything is perfect." Throughout, P0 means a critical fix, P1 an important one, and P2 a minor one. Each feature below carries a plain Status line and, where there is any way to get caught out, a Watch-out telling you the exact thing to be ready to defend and the safe way to say it.

An audited go-live decision with every condition named

What it is

Instead of a vendor saying "trust us, it's ready," you get a written verdict from an independent review: Ring is a strong replacement for the old system, cleared to go live once a short, named list of fixes is closed. Every item on that list is written down with a plan to close it, so nothing is hand-waved.

Why it matters

Replacing the screen that runs your glue kitchen is a real risk if you do it on optimism. This turns a leap of faith into a checklist you can hold the vendor to. You can see exactly what stands between today and a clean cutover, and watch that list shrink.

How it works

An independent audit compared Ring screen-by-screen against the old system and found roughly 80% of features at full parity or better. It then produced an enumerated punch list — a short set of critical, important, and minor items — each with a remediation plan. Connecting Ring to a live PLC clears the "can it read and write at all" questions, but it does not clear the verification items still outstanding (a fresh side-by-side diff, deliberate fault-injection on the bench, a multi-day soak test, staged rollback media, and signed operator acceptance).

Versus the old RS-360 system

With RS-360 you inherit unbounded, quietly growing risk: decades of field history but no reproducible build, no security-patch path, and a corruption-prone Paradox/BDE database (an obsolete 1990s file format) that can fail without warning. With Ring, your only remaining risk is a known, scoped, shrinking cutover tail — with written remediation plans the old app could never even produce.

Status & honest caveats

Likely questions & how to answer them

A dated, auditable trail of every go/no-go decision

What it is

A written, dated record of every safety decision made about Ring: it started as a deliberate NO-GO when a review caught a serious bug, became GO-WITH-CONDITIONS after the fixes, and earned a clean GO for a safe read-only session against your real plant. Your own engineer can read the whole trail.

Why it matters

Anyone can claim "we tested it." Far fewer can hand you a paper trail that shows they failed their own first review on purpose, fixed what they found, and re-checked. That is the difference between a vendor's word and an auditable decision that survives scrutiny.

How it works

The first formal go/no-go review returned NO-GO: it caught one critical issue in the new split-batch feature plus five important ones. All were fixed and re-reviewed; the build came back clean. A later review — an adversarial double-check run by 23 separate review agents — issued a GO for a read-only live session, and confirmed the single most important safety property: that Ring's write-guard fails safe, suppressing every command to the PLC, with all 24 places in the code that could write to the controller short-circuiting to a logged, do-nothing "suppressed" path.

Versus the old RS-360 system

With RS-360 there is no readiness review and no documented verdict process at all; it "works" because it has not had to change, and its correctness becomes unprovable the day you actually need to change it. With Ring, every verdict, date, and fix is written down and reproducible.

Status & honest caveats

Likely questions & how to answer them

About 80% screen-for-screen parity, with the gaps named

What it is

A feature-by-feature comparison of every old screen against its Ring equivalent. About 80% of features are at full parity or better, with Ring beating the old system on trending charts, batch time-to-finish estimates, exports, formula history, and safety. The remaining 20% is split into deliberate scope cuts and a short list of genuine, named gaps.

Why it matters

Your operators don't want to relearn their job, and you don't want to discover a missing capability after cutover. This map tells you exactly what carries over and exactly what doesn't — so there are no surprises on the floor.

How it works

An audit using 11 parity reviewers produced a comparison map with file-and-line evidence for each claim, not a marketing summary. It confirmed where Ring is a superset of the old system (batch ETA with stale-data warnings, full live trending, PDF/CSV export, filter presets, formula-history snapshots, the read-only safety gate, data-freshness indicators) and named the genuine high-severity gaps up front.

Versus the old RS-360 system

With RS-360 you lose the live picture the moment it scrolls off the screen. The old system did record batch, step, shift, and alarm data — but it locked that data inside a dead Paradox/BDE database (an obsolete 1990s file format) that needs a custom reader just to open, with no living historian, no surviving on-glass trends, no operator-usable step-duration timeline, no equipment-runtime stats, and no way for an operator to search it. Its one clear remaining edge today is the live mixer screen that animates roughly 20 valves and pumps. With Ring you gain durable, operator-searchable history and safety the old system kept locked away; the one named tradeoff is that Ring's mixer component popup currently shows equipment state as UNKNOWN until that animation is wired in.

Status & honest caveats

Likely questions & how to answer them

The audit-trail gap we disclose first: no per-person logins yet

What it is

We're telling you this before you find it at an audit: Ring does not yet have real per-person logins. It uses shared role passwords rather than personal sign-ins, there is no in-app way to create users or change passwords yet, and it records what was done but not which named person did it.

Why it matters

For an industrial-adhesive plant, a shared-role login model is genuinely acceptable. But if you operate under stricter food or pharmaceutical record-keeping rules, "who did this?" accountability is a legal requirement — and you want that scoped before you sign, not discovered during an inspection. Naming it first is how you stay in control of that conversation.

How it works

Today Ring has two roles: Supervisor and Admin (the Admin password is partly derived from the date). The password-management screen is a "coming soon" stub. Ring does persist an operator's typed-in name, but on the honor system — there's no login-derived identity tied to each action, and no dedicated security-event log. Adding true named-user logins is a scoped piece of work; some of the underlying data plumbing already exists.

Versus the old RS-360 system

The old system was no better here — and be careful exactly how you say it. RS-360 also had no per-person forensics: it used access levels and 14 shared, unhashed plaintext credential slots found in the plant drop. Those credentials live in the HMI's configuration files (an INI directory), not inside the PLC — say "HMI-config-resident," not "PLC-resident," because an engineer who opens the file will see it's a screen-config file. Accountability in the old system was role-level, never person-level.

Status & honest caveats

Likely questions & how to answer them

Floor troubleshooting without Studio 5000, plus one-button backup

What it is

A set of built-in tools so your floor can diagnose problems and protect their data without specialist software. There's a one-tap system snapshot, a live reader for any PLC value, a live feed of PLC messages, a tool to set the controller's clock, one-button database backup and restore, and an admin-only factory reset. ("Studio 5000" is Allen-Bradley's engineering software — normally you'd need an engineer with it to read a raw PLC value.)

Why it matters

Today, deep troubleshooting on the old system means pulling in an engineer with Studio 5000 — slow and expensive. With these tools, floor staff can read a tag, see why communications hiccuped, and capture a support snapshot themselves, turning multi-hour callouts into minutes. The backup/restore protects your history.

How it works

Each tool is a built-in dialog. The Tag Inspector lets you paste a tag name (for example a tank's agitator output) and read its live value. The Diagnostic Console captures a one-shot host/PLC/traffic snapshot for support. The Communication Monitor shows a live feed of messages to and from the PLC. The Database Backup tool makes a safe online copy of Ring's history database (stored in SQLite, a small self-contained database file) and can restore it. The sensitive tools are password-gated, and the factory reset re-prompts before it runs.

Versus the old RS-360 system

With RS-360 you get a communications log and a Time/Date form, but no live tag inspector, no one-shot diagnostic snapshot, no built-in backup/restore, and no factory reset — so deep troubleshooting means calling in an engineer with Studio 5000. With Ring, that becomes a built-in, in-app task your own floor can do.

Status & honest caveats

Likely questions & how to answer them

A 13-language screen you can switch live — with honest coverage limits

What it is

Ring ships a 13-language interface with English as the default, and you can switch language on the fly — no restart, no reinstall. The translations were seeded from your plant's own Dutch dictionary. But be precise about coverage: today the translation reliably covers the first-run setup wizard, the top-level menu buttons, the common buttons, and core domain words — not yet the deep operator screens.

Why it matters

Your floor reads the plant in Dutch; the old system runs in Dutch. An English-only screen would be a real adoption problem. The live-switch engine is real and the high-traffic navigation is translated — but a half-translated screen can read worse than none, so we're honest about exactly how far it currently reaches.

How it works

A localization service swaps a single per-language set of strings, so every translated label repaints instantly with no restart. Crucially, it deliberately never changes the system's number formatting or culture settings, so batch math and the numbers Ring exchanges with the PLC are completely unaffected by the language choice. Missing translations fall back to English, so the screen never goes blank.

Versus the old RS-360 system

With RS-360 you pick one language at commissioning and it's frozen there — roughly 7 language dictionaries (13 source files including regional variants), but one language per install, with no runtime switching. With Ring you match that multi-language reach with a modern engine that switches live and extends incrementally, screen by screen.

Status & honest caveats

Likely questions & how to answer them

The built-but-gated follow-ups that don't block daily work

What it is

A short list of items that exist but need a small finishing touch: an automatic batch-completion email that runs once it's enabled in settings, and two Setup areas that still read "coming soon" — the in-app communication-adapter settings and user/password management. None of these blocks day-to-day operation.

Why it matters

You should know the exact edges of "done." These three items are the difference between "fully wired" and "wired but gated." The good news is none of them stops anyone from running glue; the honest news is they each need a step before they're fully self-service.

How it works

The batch-completion email is real, working code with a real mail transport built in. It's gated off by default and only attaches when enabled. The communication-adapter settings (timeouts and retry behavior) live in a config file today rather than on a screen, and the password-management screen is a "coming soon" stub.

Versus the old RS-360 system

With RS-360 there is no batch-completion email at all, while comm and password settings are exposed as editable forms. With Ring, even the config-gated email is a net gain; we deliberately hardcode the single-site tag layout, trading editable forms for simplicity, with the toggle and Setup screens as honest follow-ups.

Status & honest caveats

Likely questions & how to answer them

The scoping questions only your team can answer

What it is

A short list of facts we can't settle for you and need to confirm together before cutover: your plant's regulatory class, the full tank scope, and the provenance of a second controller identity we saw in an export. These are flagged as honest questions for you, not claims we invented.

Why it matters

Commissioning-day surprises are expensive. Settling these three now means no mismatched tank counts, no wrong-language screens, and no controller confusion when the system goes live. It's cheaper to ask than to discover.

How it works

Three open questions. First, your regulatory class (chemical-only vs. food vs. pharmaceutical) decides how much audit-trail work the named-user logins really need. Second, tank scope: the live plant runs 13 tanks (1 mixer + 6 storage + 6 doser) with Dutch names, not the 1/2/4 demo subset Ring ships with — so a name-import and a scope confirmation are needed before the floor sees correct names. Third, controller provenance: the live box is a CompactLogix 1769-L36ERM on firmware v20.12, but a separate "running export" we were given carries a controller identity that does not match it — and the newer Studio software can't even upload from a v20 controller — so whether a second controller exists is genuinely an open question for your point of contact (POC).

Versus the old RS-360 system

With RS-360 you inherit a system pre-bound to one site's tank set and one Dutch install, with no documented provenance trail for the controller it talks to. With Ring, these are explicit, documented open questions to resolve with your team before cutover — which is itself the safer position.

Status & honest caveats

Likely questions & how to answer them

Adopt the new screen now; the control-logic port is scheduled separately

What it is

You can put up Ring — the new operator screen — on its own timeline, independent of any control-logic work. The HMI is finished and waiting. The separate question of which control program runs the plant, and any work to bring Ring's analyzed control logic fully live, is a scoped engineering engagement scheduled on purpose, not a surprise on cutover day.

Why it matters

This is the single most important framing point in this chapter, and the easiest to get wrong in a hostile room. Ring replaces the screen, not the controller. Keeping those two cleanly separable means your floor can adopt the modern interface immediately while any controller-logic engagement is scheduled deliberately — and it means installing Ring does not touch the program that actually runs your line.

How it works

Two distinct things must not be confused. (1) Our pre-cutover snapshot of the controller's project file ships inert — its main task is inhibited and the batch routines are commented out. (2) On-site reads of the live plant PLC show the opposite: the main task is scanning and real batches are running. So that inert state describes our checked-in snapshot, not the box on your floor. Bringing Ring's analyzed control logic fully live is a scoped engagement using v20-era Studio 5000 (our bench controller is a firmware twin at v20.12), with a couple of routines needing real porting. The HMI is complete and waiting; the plant goes fully live once that engineer engagement completes.

Versus the old RS-360 system

With RS-360 the control logic is entangled with bespoke Borland bridges and sidecar executables, with no clean separation between the screen and the control logic. With Ring, the HMI is cleanly separated from the controller program, so the interface can go up now and the control-logic work can be restored on a scoped, scheduled basis.

Status & honest caveats

Likely questions & how to answer them

Appendix A — Plain-Language Glossary

Every term in this guide, defined as if for the first time. If a question turns on a word, find it here.

The plant and the process

• Corrugating adhesive / starch glue — the industrial glue this plant makes; it bonds the layers of corrugated cardboard. Not food.
• Viscosity — how thick or thin the glue is. It's the critical quality spec, but the controller has no viscosity sensor, so neither the old system nor Ring can display a live viscosity number.
• Batch — one production run of one recipe; the plant's basic unit of work. ~1,404 in recorded history.
• Recipe / formula — the ordered steps that make one product (add water, heat, add starch, stir…).
• Step / operation — one instruction in a recipe, identified inside the controller by a numeric op-code.
• Op-code — the controller's number for an operation (e.g., "add starch"). The old system showed operators these raw numbers; Ring turns them into words.
• Tank — a vessel holding liquid. 13 in service: 1 mix tank, 6 storage, 6 doser/feed.
• Mix tank / Make-Ready tank — where the glue is actually mixed.
• Doser / feed tank — meters an ingredient into the mix.
• Agitator — the motorized paddle that stirs a tank; turning it on/off is a recipe step the controller sequences.
• Giveaway / overdose — product you over-make beyond target: ingredients you paid for and effectively gave away. Ring can price it.
• CIP (Clean-In-Place) — cleaning a tank without dismantling it; "CIP state" = whether a tank is clean, dirty, or in use.
• OEE (Overall Equipment Effectiveness) — a standard factory score combining availability, performance, and quality; Ring's downtime screen estimates it.

The two computers

• PLC (Programmable Logic Controller) — the rugged industrial computer that physically runs the plant (valves, pumps, mixer, safety interlocks). Here: an Allen-Bradley CompactLogix 1769-L36ERM. Ring does not replace or reprogram it.
• HMI (Human-Machine Interface) — the operator's screen software. RS-360 = the old HMI (2002, Borland C++, DOS-era). Ring = the new HMI.
• Tag — one named value inside the controller (e.g., a tank's temperature). "133 tags read" = every live value Ring needs was read correctly.
• Studio 5000 — Allen-Bradley's engineering software for programming the PLC. A selling point is that Ring gives the floor diagnostics without needing Studio 5000 open.

How Ring connects

• EtherNet/IP — a standard, open industrial network protocol Ring uses to talk to the controller. (Different from a generic office network; it's the Allen-Bradley standard.)
• CIP frame / request packet — the small network message sent to read a tag. (This is why "we sent zero bytes" is wrong but "we sent zero commands that could change the process" is right.)
• libplctag — the open-source library Ring uses to speak EtherNet/IP. Replaces the old system's bespoke Borland helper components.
• Read-only mode / cutover gate (ReadOnlyMode=true) — a Ring setting that suppresses every write to the controller, so Ring can watch the live plant safely before go-live.
• Heartbeat — a value in the controller that keeps changing while the program is running; Ring watches it to tell "running" from "frozen" from "unplugged."
• Stale / freshness — whether an on-screen reading is currently live or has stopped updating. Ring dims stale readings and stamps "as of HH:MM" so a frozen number is never mistaken for a live one.

The software underneath

• .NET / WPF — the modern Microsoft technology Ring is built on (current, supportable, hireable). Contrast with the legacy's dead 2002 Borland C++ toolset.
• SQLite — the modern, single-file, open database Ring stores its data in. Any standard tool can open it; one-click export to CSV/Excel.
• Paradox / BDE (Borland Database Engine) — the abandoned 1990s database format the legacy used; no maintained driver, which is why recovering legacy data required writing a custom reader.
• WAL (Write-Ahead Logging) — a SQLite durability feature: a batch you just finished survives a power blip, and the screen doesn't freeze under load.
• Migration — a controlled, all-or-nothing upgrade of the database structure when Ring is updated; an interrupted upgrade won't corrupt your history.
• Process Historian — a background recorder that logs each tank's temperature/level/recipe about once a minute, building the history that powers trends, best-batch comparison, and the cost engine — with no extra load on the controller.
• Golden batch — your best, proven good run; Ring can overlay a current batch's temperature trace against it to catch drift early.
• Dashboard / command center — Ring's one home screen that shows the whole plant at a glance.
• KPI tile — one of the key headline numbers on the dashboard (open alarms, mix-tank temperature, batch % done, which tank needs attention); each is tappable to jump to the screen that fixes it.

Status words used in this guide

• Live (wired) — built, finished, and reachable by an operator on a real screen today.
• Dormant — the code is built and tested but not yet placed on a screen an operator can reach. Honest status; some "shipped" items are here.
• In progress — partially built; core works, finishing touches remain.
• Roadmap — planned and specified, not yet built.
• Parity — Ring matches what the old system did for a given capability. "~80% parity-or-better" = Ring matches or beats the legacy on about 80% of capabilities (per a code audit), with the gaps named.

People who might grill you

• Controls engineer — knows the PLC and the legacy intimately; will challenge anything that misstates the controller or the old system. Most of Part 0 §0.8 exists for this person.
• Operator — runs the plant daily; cares about "is it easier, and is it honest about what's live?"
• Owner / buyer — cares about cost, risk, lock-in, and what isn't finished.

Appendix B — The Hardest Questions (cross-cutting), and How to Answer Them

The per-feature Q&A lives in each chapter. This appendix is for the big, whole-product questions that aren't about one feature — the ones most likely to decide the meeting. Each answer is written to be said out loud, and each is honest, because honesty is the thing that survives a grilling.

The five "say it this way" rephrasings (your armor — repeated from Part 0 because it's that important)

If you're tempted to say…	A sharp person can refute it because…	Say this instead
"The old system records nothing."	Its database files hold ~1,404 batches and ~16,776 step rows.	"The old records are locked in a dead format with no living historian, trends, cost, or step-timing — Ring keeps the same history usable and exportable."
"We read the plant without sending a single byte."	Reading values sends network request packets.	"We read all 133 live values without issuing a single command that could change the process — every write was suppressed."
"Zero bytes to the controller."	Same as above.	"Zero write commands under the read-only safety gate."
"The old system couldn't tell if it was connected."	It had an OK/Not-OK heartbeat light.	"The old light was one on/off signal; Ring names unplugged vs. frozen vs. running and gates writes off that state."
"~70–80% parity, verified on-site."	The number and the on-site event are two different things.	"~80% parity-or-better per an engineering code audit; separately, 133/133 live reads verified on-site on your controller."

The whole-product questions