When your line stops,
Edmund knows why.

Edmund is a debugging platform that reads your PLCs, HMIs, schematics, manuals, alarms, and maintenance journals. Unifies all of your data sources into one platform with a reliable maintenance workflow.

Book a demo → See it in action

edmundai.app/session/line-3-cmm-fault

What does FB_Conv3_Control do, and where is it called from?

FB_Conv3_Control is the conveyor #3 motion controller in Main_OB1. It governs start/stop interlocks and reports faults to the HMI.

42FUNCTION_BLOCK FB_Conv3_Control 43VAR_INPUT 44 Enable : BOOL; 45 EmergStop : BOOL; // hard-wired E-stop loop 46 PhotoCell : BOOL; // -94B1 product detect 47END_VAR 48IF EmergStop OR NOT PhotoCell THEN 49 Stop(reason := 2); // fault flag → HMI 50END_IF;

FB_Conv3_Control · L42 Main_OB1 · call site EPLAN · -94B1

Ask Edmund, try "trace alarm 4711 to PLC block" ⌘ K

Trusted by leading European manufacturers 13 production groups · 4 countries

§01 The bottleneck

You have a CMMS. You have an MES. You have Copilot.
So why do faults still take hours to fix?

€30,000–€60,000

An hour of unplanned downtime on a tier-2 automotive line.

We bet your last downtime took more hours than you would have liked.

§ What changes

Three things a Plant Director sees in the first quarter.

Edmund's first users are technicians on the floor. Its first KPI movers are the people running the plant.

25–30%

time saved on troubleshooting

MTTR drops measurably.

Mean time to repair gets shorter, and the difference shows in OEE. Numbers you can defend in a quarterly review without hand-waving about "improving processes."

441hrs / yr

returned to senior technicians per plant

Senior engineers stop being the bottleneck.

Junior technicians fix lines they couldn't fix before, without calling the one person who actually knew the system.

€700k / plant / yr

saved across the cohort

Reliability KPIs you can defend in a board review.

Every fault has a documented root cause. The board review stops being "we're working on it" and starts being "this is the third Tuesday relay sticking; here's the procurement plan."

§02 Why downtime hurts

The fix is ten minutes.
The hunt is an hour.

When a line stops, technicians don't lose time turning wrenches. They lose it figuring out which one. The data exists, across PLCs, schematics, alarms, journals, and people's heads, but none of it connects. Edmund compresses that diagnostic stretch.

MTTR · diagnosis vs repair

Without Edmund

Diagnosis ~50 min

Repair ~10 m

With Edmund

Diagnosis ~10 m

Repair ~10 m

Saved ~40 min

Diagnosis eats the budget.

Across our deployments, the part swap is rarely the bottleneck. The hour you lose is upstream, figuring out which part, why it failed, and whether it'll come back next quarter.

The data exists. The connections don't.

PLC code, EPLAN drawings, alarm history, maintenance journals, and what's only in the head of the senior technician, separate systems, separate handoffs, no map between them.

Technicians want to fix, not investigate.

A traceable answer beats a confident guess. Edmund hands the technician the cause and the next step, with citations, so the only thing left to do is the wrench work.

§03 How Edmund works

Four steps from data to decision.

Edmund AI doesn't pull anything you don't already have. Existing systems stay in place. We add a debugging layer on top of them.

Connect

We read what you already run

Documentation, PLC projects, databases, and people's know-how. Nothing in your production systems gets changed.

Understand

We build a graph of the machine

Components, code, data, and people's notes linked into a single map of how this factory actually behaves.

Diagnose

A technician asks. Edmund cites.

Plain language in. Specific source out, the PLC block, the EPLAN page, the SQL row. Never a vague summary.

Act

One concrete next step

A part number, a procedure, a hand-off. If the action exceeds the user's authorization, Edmund says so, clearly.

§ How Edmund thinks

A traced answer, not a guess.

One question from the shopfloor. Five disconnected sources, schematics, PLC code, datasheets, IoT readings, decades of maintenance journals. One traced answer, with citations.

Maintenance technician asks

"Why is the gripper not opening?"

scroll

01 Step oneContext linking

It knows where the question lives.

Edmund classifies the question and locates the exact file in the right silo of your factory's knowledge graph, the PLC project, the function block, the line of structured text where the gripper-open routine is written.

PLC & HMI projectsEject_Mag.scl

02 Step twoCross-source correlation

It threads the answer across sources.

From that line of code, Edmund follows the mag_ejected variable into the wiring diagram, traces the wire to the actual sensor, opens the sensor's datasheet, and surfaces the section in the manual that describes the retraction routine.

PLC & HMI projectsEject_Mag.scl

Schematics & EPLANPallet_sensing_wiring.pdf

DocumentationManual_LDF5000 §4.7

03 Step threePattern recognition

It sees the fault before you see it.

Edmund matches this fault signature against years of maintenance journals, every paper notebook, SAP ticket, SharePoint entry, and recognises this exact failure has been logged before. Across multiple machines. With a known resolution path.

0 similar fault patterns
logged across 12 machines
over the past 90 days

04 Step fourStructured insights

It comes back with an answer.

Not a 50-PDF search result. Not a chatbot guess. A traceable answer the technician can act on, with every source clickable, every claim cited.

Edmund · answer 07s · 4 sources

"Why is the gripper not opening?"

The gripper-open logic lives in Eject_Mag.scl. It only fires when:

eject_mag = TRUE
mag_empty = FALSE
no fault flags in mag_eject_fault or mag_retract_fault

This exact fault has been logged 47 times across 12 machines in the last 90 days, and resolved 41 of 47 times by re-pressurising Module 3 to 5.5 bar and resetting the magazine.

Suggested first check: pneumatic pressure on Module 3.

PLC · Eject_Mag.scl Schematic · Pallet wiring Manual · LDF5000 §4.7 Journal · 47 entries

§04 One platform

Every signal in your factory, in one place.

Edmund reads and connects every data source, from PLC programs to handwritten journals, into one searchable map. Ask once, in plain language. The platform picks the right source for you.

/01 PLC · vendor-agnostic

Reads the logic across every vendor on your floor.

Edmund parses TIA Portal, Allen-Bradley, and Omron projects (plus anything that compiles to IEC 61131-3) into the same searchable model. Returns blocks, line numbers, call sites, never a paraphrase. A technician can navigate code they didn't write.

Siemens TIA Portal Rockwell · Allen-Bradley Omron Codesys (Beckhoff · Schneider · Wago) IEC 61131-3 No vendor lock-in

Recent fault sessions line 4 · Allen-Bradley PLC

Allen-Bradley HMI · alarm 017214:03 · today

EXH Low Left · fault logic traceyesterday

ESA diagnostics won’t start2 days ago

Bearing replacement log overview3 days ago

Allen-Bradley exhaust warning logiclast week

Unwind position diameter faultlast week

/02 ePLAN · logical to physical

Turns a logical address into a physical spot.

A tag like -94B1 resolves to the cabinet, the row, and the clamp position a technician can put a hand on. Closes the "where is it physically?" loop in seconds, not days.

Logical → physical Cabinet maps Wire-tracing

Cabinet view +SK3 · row F EPLAN

+SK3

F124V

F2PSU

F3I/O

F4I/O

F5-94B1

F7I.4.3

+SK4

G1VFD

G2VFD

G4SAFE

+SK5

H1HMI

H2NET

H3NET

H5I/O

H6I/O

H7RES

+SK3 · row F · clamp 11–12 I 4.3 · DI module 4 SICK WL12-2P430

/03 SQL · live operational data

Tests the hypothesis against live data.

Pulls trends, historical measurements, and alarm logs in real time. Confirms or refutes a guess from PLC or EPLAN, surfaces patterns across shifts and lines, and returns a diagnostic conclusion with a recommended next step, not a CSV to read.

SAP · MES · ERP SQL · Postgres · MSSQL Time-series 10+ DB connectors

Fault freq. Conv3 · fault 2 · 30 d MES

30 d ago14 dtoday

3.4× more events on Mon · Wed · Fri · 22:30+ · aligns with cleaning rota

/04 Documents · the most-used agent

Finds the page, the paragraph, the line.

Mechanical drawings, electrical schematics, manuals, datasheets, measurement protocols. Returns the exact citation, multilingual and visual when needed. The agent that turns up in every debugging workflow, checking the HMI, reviewing schematics, looking up a part spec, handing context to the next shift.

EPLAN · DWG · PDF Manuals · datasheets Multilingual Cited every time

Match SICK · WL12-2P430 PDF · p. 7

"Recommended cleaning interval for the WL12 in dust contamination class M is every 240 operating hours; failure to clean reliably degrades switching frequency below the 1 000 Hz nominal value."

SICK datasheet · rev 04/2024 Open page 7 ↗

PDFWL12-2P430 · datasheetp. 7

DWG+SK3 cabinet · sheet 217v. 3

MDMaintenance journal 2026-04-12#4729

/05 Maintenance journals · tribal knowledge

Saves the fix so the next person inherits it.

Captures what technicians know but rarely write down: the symptom, the root cause, the parameter change, the photo. Edmund parses handwritten notes and shift logs, surfaces repeat interventions, and turns one expert's hour-long debug into a repeatable solution anyone can follow.

Handwriting OCR Multilingual Photos · scans · PDFs

Journal Conv3 · 90 d Hand-OCR

02-14 -94B1 photo-eye replaced (SICK), dust on lens

03-02 conv3 fault 2, restarted, OK

03-19 conv3 fault 2 again, checked wiring +SK3-F5

04-12 cleaned -94B1 lens, retest OK

Pattern detected: 4 interventions on -94B1 in 60 days. All resolve by cleaning, none by replacement. Recommend adding cleaning every 240 h to the preventive plan.

§04 Case study

See how Edmund helps technicians at the shopfloor.

01 03

Case: /01
Sector: Packaging
Operator: Amcor Flexibles
Site: Nový Bydžov, CZ

How Edmund cut repair time 26% across Amcor's Nový Bydžov plant.

Maintenance knowledge sat in three places, hundreds of PDFs, handwritten logs, and the heads of technicians who'd spent decades on the floor. None of it was searchable. Edmund pulled all of it into one query box.

A junior technician answering a 2 a.m. fault alarm now reaches the same institutional knowledge a senior engineer could recall in seconds. Adoption was immediate, the interface was simple enough that technicians started using it on day one without prompting.

The standout feature was voice input. Instead of typing notes after a long shift, technicians dictate directly on the floor and Edmund writes the entry into the digital maintenance log automatically.

Read the full case →

26%

drop in repair time
440hrs

man-hours saved per plant, per year
90%

faster fault diagnosis
Day 1

adoption · no extra training

Case: /02
Sector: Packaging
Operator: Model Obaly
Site: 4 plants · CZ

How Edmund made 300,000 pages searchable across four Czech plants.

Model Obaly's Opava plant alone had accumulated over 300,000 pages of technical documentation: manuals, PLC programs, maintenance logs, spare-parts databases, spread across shared drives, physical binders, and the heads of long-serving engineers.

Nobody could search it. When a machine stopped, the maintenance team had to know the right person, not the right system. As experienced engineers retired, the institutional memory was quietly leaving the building.

Edmund indexed the production machines at Opava, covering printing, laminating, die-cutting, and waste lines.

Read the full case →

30%

cut in MTTR · downtime per fault
300K

pages of documentation indexed

Case: /03
Sector: Metalworking
Operator: Moravia Cans
Site: Bojkovice, CZ

How Edmund made sure no maintenance question goes unanswered at Moravia Cans.

Moravia Cans makes aluminum aerosol cans with patented embossing technology and high-speed production. With 480+ employees and 60% growth over three years, their Bojkovice factory runs shaping and printing lines where uptime is everything.

Manual collections, maintenance records, and live ERP databases sat in disconnected systems. Edmund brings them together so technicians get a complete picture from a single question. No switching between tools or chasing colleagues for context.

Edmund connects directly to Moravia Cans' Microsoft SQL databases, including QAD and PowerBI. Maintenance teams check spare-parts availability, review repair history, or pull production metrics on the spot, without database expertise or IT tickets.

Read the full case →

10K+

data points connected into one platform
24/7

expert knowledge on the shop floor
3

ERPs unified · SQL · QAD · PowerBI

§05 What people say

People running Edmund every day.

Shop-floor voices. Their words, not the marketing team's.

Before, when a machine stopped and the fault wasn't obvious, just finding the right information took longer than the repair itself: manuals on the shared drive, electrical docs elsewhere, repair history in another system. Now everything is at the machine. Downtime is roughly 30% shorter and we save tens of hours every month. The biggest benefit is being able to focus on the repair, not on hunting for information.

Kamil Fedor

Country Maintenance Manager · Model Obaly

300K

Documents indexed

30%

Less MTTR

AI is the only tool that can systematically work with data from multiple sources. Using Edmund has led to a lower frequency of a specific failure, or even its complete elimination.

David Frajt

Head of Maintenance · MoraviaCANS

We've had a very positive experience with Edmund. The results have an immediate impact on the efficiency of our production processes.

Martin Bryknář

PLC Specialist · Amcor

441 hours

Saved on maintenance per year

We tested various solutions across several levels of our operations. In a number of areas, the Edmund platform delivers the best and most accurate results, which clearly convinces us of the long-term potential of this direction.

Jan Svoboda

Technical support manager · FERMAT

Industry 4.0 promised a lot but delivered very little. Edmund is genuinely making a difference.

Filip Škeřík

Head of automation · Festo

§06 What an engagement looks like

Seven weeks from kickoff to live diagnosis on your own data.

Two or three use cases with measurable business impact. We'd rather scope down than oversell the first rollout.

wk 1wk 2wk 3wk 4wk 5wk 6wk 7

01 · Kickoff

02 · Build & tune

03 · Present

01 · Week 1

Kickoff workshop

Scan of the operation. Identify key documentation and input data. Two or three concrete use cases agreed with the maintenance lead, each tied to a measurable business impact.

You'll leave with: a signed scope, the data list, and a defined success metric per use case.

02 · Weeks 2–6

Build & tune

Platform configuration. Knowledge integration. Quality control of data and output answers. Weekly reviews with the team that will actually use it.

You'll leave with: Edmund running on your real data, your team trained, real fault traces in your hands.

03 · Week 7

Final presentation

Results presented to management with a business case built from the agreed use cases.

You'll leave with: a documented business case, signed-off renewal terms, and a roadmap for the next 90 days.

Edmund is built for your factory if:

You run custom-automated production lines
You're a mid-to-large manufacturer with maintenance and PLC engineering teams
Unplanned downtime costs your plant measurable money
You have documentation Edmund can read, schematics, manuals, alarm logs
PLC integration is ideal, but Edmund still works without it

Book the kickoff call →

When your line stops,Edmund knows why.

You have a CMMS. You have an MES. You have Copilot. So why do faults still take hours to fix?

Three things a Plant Director sees in the first quarter.

MTTR drops measurably.

Senior engineers stop being the bottleneck.

Reliability KPIs you can defend in a board review.

The fix is ten minutes. The hunt is an hour.

Diagnosis eats the budget.

The data exists. The connections don't.

Technicians want to fix, not investigate.

Four steps from data to decision.

We read what you already run

We build a graph of the machine

A technician asks. Edmund cites.

One concrete next step

A traced answer, not a guess.

It knows where the question lives.

It threads the answer across sources.

It sees the fault before you see it.

It comes back with an answer.

Every signal in your factory, in one place.

Reads the logic across every vendor on your floor.

Turns a logical address into a physical spot.

Tests the hypothesis against live data.

Finds the page, the paragraph, the line.

Saves the fix so the next person inherits it.

How Edmund cut repair time 26% across Amcor's Nový Bydžov plant.

How Edmund made 300,000 pages searchable across four Czech plants.

How Edmund made sure no maintenance question goes unanswered at Moravia Cans.

People running Edmund every day.

Seven weeks from kickoff to live diagnosis on your own data.

Kickoff workshop

Build & tune

Final presentation

Edmund is built for your factory if:

When your line stops,
Edmund knows why.

You have a CMMS. You have an MES. You have Copilot.
So why do faults still take hours to fix?

The fix is ten minutes.
The hunt is an hour.