Lane · Professional · Engineering Diagnostics

AI as a co-diagnostician.

Industrial troubleshooting is a hypothesis game — ten things could cause a compressor trip, nine of them are wrong, and the cost of checking is measured in hours and refrigerant kilos. AI doesn't replace the technician's judgement; it prunes the tree fast enough that the right cause surfaces while the system is still warm.

DEMO
Synthetic equipment. The Cryovox compressor, Helix drive, and Torquon motor, along with their RGH- alarm codes, are invented for this demonstration. Descriptions, parameters, and failure modes draw on real-world analogues from Copeland, Bitzer, Danfoss, Siemens and ABB practice — but no confidential vendor data, customer records, or proprietary schematics appear on this page.
01 Discipline What engineering diagnostics actually is

Ten candidates. One right answer. Fast.

A field alarm is a question posed in bad lighting: what changed? The discipline is Bayesian — you hold a prior ("condenser fouling accounts for 70% of high-side pressure trips in my installed base"), you gather evidence cheaply (the fan is running, the ambient is 14 °C, the sight glass is clear), and you update. The technician who wins is the one who eliminates three causes in the time it takes the competition to check one.

AI's role isn't to replace that Bayesian loop — it's to expand the prior. A well-indexed language model has read a thousand more service bulletins than you have, seen failure modes on adjacent product families, and remembers what a desaturation fault on a parallel drive looks like at 3 AM. The technician still owns the call. The AI just makes sure no branch of the tree gets skipped.

02 Toolkit What's in the diagnostic bench

Model, manual, and a good multimeter.

The AI-assisted diagnostic stack is layered — a reasoning model at the top for hypothesis work, a curated knowledge base in the middle for manuals and bulletins, instrumentation at the bottom for ground-truth. None of the layers matter without the others. The model hallucinates without grounding; the manuals collect dust without a reader; the instruments measure the wrong thing without a hypothesis.

Reasoning
Claude · Sonnet 4.5
Hypothesis generation, cross-reference against schematic, written handoffs to operators. Used as the lead co-diagnostician in live sessions.
Knowledge
PDF corpus + RAG
Service manuals, parameter references, fault-code lists, and commissioning reports — indexed and retrievable against queries.
Telemetry
PLC + VFD logs
Live parameter dumps from UniCloud / S7 / AK-PC controllers. The ground truth any hypothesis must explain.
Pattern library
Schematic correlator
Known-good P&IDs and wiring diagrams indexed against symptom signatures — finds the "looks like" match fast.
Session log
Structured note-taking
Every diagnostic round produces a timestamped log: symptom, test, result, inference. Feeds back into the knowledge layer.
Hands & meter
The technician
The irreplaceable layer. AI narrows the search to three candidates; the technician verifies which one is real.
03 Process Six steps · repeatable loop

The elimination loop.

A diagnostic session is a loop, not a line. Each step produces evidence that either confirms a branch or prunes it — and the loop continues until one branch is the last one standing. Speed comes from cheap eliminations early; accuracy comes from refusing to commit until the last branch is the only one that explains every piece of evidence.

01
Capture
2–5 minutes
Record the symptom in the operator's words. Pull the last fault code, the alarm log, and the raw parameter dump. Nothing is interpreted yet — the goal is a complete snapshot of the system state at the moment the machine cried for help.
02
Frame
5 minutes
Translate operator language into engineering language. "It's running hot" becomes discharge temperature at 118 °C, envelope limit 110 °C, ambient 34 °C. The frame determines which hypothesis tree is even relevant.
03
Hypothesize
5–10 minutes
Enumerate every cause the framed symptom could plausibly have. Rank by prior probability. This is the step AI contributes most to — it remembers causes a tired technician at the end of a long drive would miss.
04
Eliminate
Most of the visit
Run the cheapest test first. A sight-glass check eliminates two hypotheses in 30 seconds; pulling a compressor plate eliminates one in three hours. Cost-ordered elimination is the whole skill of the trade.
05
Verify
10–30 minutes
The surviving hypothesis must explain every piece of evidence, not just most. If a single parameter doesn't fit the story, the story is wrong. Back to step 3.
06
Close
30–60 minutes
Apply the fix. Re-test under load. Document the root cause in language a junior technician visiting next month will understand. Feed the new pattern back into the knowledge layer.
04 Equipment Three synthetic units · click to see fault catalog

One compressor, one drive, one motor.

The diagnostic tool below covers three invented units designed to exercise realistic fault modes. The compressor is a semi-hermetic CO₂ reciprocating unit; the drive is a mid-range AC VFD with braking and STO; the motor is a Super Premium efficiency induction machine. Between them: 66 alarm codes, all prefixed RGH-.

05 Try it 66 codes · 2 input modes · live hypothesis trees

Feed it a code or a symptom.

Two doors into the same reasoning engine. If you have the alarm in hand, type the code or a fragment of its name — RGH-C05, discharge, igbt. If you only have an operator description — "it's burned", "it won't start", "it hums but doesn't spin" — pick from the symptom chips and get a ranked list across all three units.

66 alarms indexed
Pick a chip or type freely
06 Featured case A three-alarm cascade · 41-minute diagnosis

"The chiller that blamed everybody."

Late-night call from an operator: a CO₂ chiller tripping repeatedly with three alarms stacked — RGH-C01 discharge pressure high, RGH-D04 drive output overcurrent, and RGH-M02 bearing DE temperature high. Classic cascade. Each alarm, taken alone, points somewhere different. Together, they tell one story — but only if you read them in the right order.

00:03
Capture

Parameter dump from the PLC shows the three trips landed inside a 90-second window. Ambient 32 °C. Load at 88% nominal. Last successful run 14 minutes prior.

00:08
Frame — which alarm fired first?

Time-ordering matters enormously here. The PLC log puts RGH-M02 (bearing temp) first, then RGH-D04 four seconds later, then RGH-C01. That ordering changes the whole tree.

00:14
Hypothesize

If the bearing was the root, the drive tripped because the motor's friction load spiked, and the compressor tripped because the drive yanked the shaft. That's one story. The competing story: the compressor was already fighting a blocked condenser, the drive was working overtime, the motor overheated its bearing from heat soak. Cost-ordered test: check the bearing first.

00:22
Eliminate

DE bearing PT100 reading 118 °C with the machine stopped for eight minutes. Condenser inlet 34 °C — perfectly normal for 32 °C ambient. Sight glass clear. Discharge pressure nominal during the cooldown. The condenser story is dead.

00:31
Verify

Turn the shaft by hand — noticeable resistance at one angular position. Vibration log from the previous 48 hours shows a growing 1× rotational signature. Every piece of evidence now fits: bearing failure caused the friction spike, the friction caused the overcurrent, the overcurrent triggered the pressure-side trip downstream.

00:41
Close

Bearing replacement ordered. Customer informed the fault is mechanical, not refrigeration — their condenser is fine, they don't need a refrigerant top-up, the drive doesn't need replacement. Three alarms, one cause, one procurement line.

Why this is the AI leverage. A tired technician at 23:00 reads "discharge pressure high" and heads for the condenser — it's the 70% prior. The AI co-diagnostician flags the alarm ordering in the PLC log as the single most informative data point on the page, re-ranks the tree accordingly, and suggests the bearing test first. Ninety minutes saved before the first wrench is picked up.