25–30%
time saved on troubleshooting
Provably lower MTTR.
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."
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.
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;
Where is -94B1 physically? Operator says "the photo-eye on conveyor 3."
-94B1 is the SICK WL12-2P430 photo-electric sensor.
- Cabinet +SK3 · row F · clamp position 11–12
- Wired to Siemens DI module I 4.3
- Replaced 2025-02-14 · maintenance journal entry #4729
This fault 2 on Conv3 keeps repeating. Is there a pattern in the last 30 days?
Yes. Fault 2 (PhotoCell low) fires 3.4× more often on the night shift. Spike correlates with cleaning crew passes after 22:30.
- 47 events · 30 d · MES production DB
- Cluster: Mon · Wed · Fri , matches cleaning rota
- No correlation with conveyor speed, ambient temp, or product mix
What's the typical response time for the SICK WL12 in dusty conditions?
From the manufacturer datasheet (rev 04/2024):
- Switching frequency: 1 000 Hz nominal
- Response time: ≤ 0.5 ms (clean lens)
- Recommended cleaning interval in dust class M: every 240 h
Your maintenance log shows the lens was last cleaned 312 h ago. That likely explains the repeated PhotoCell low events.
Line 3 just emergency-stopped. Trace alarm 4711 for me.
Alarm fired at 14:03:22. Walking the chain back through the PLC trace, sensor logs, and the last six months of journal entries:
- Alarm:
Conv3_Emergency_Stop - Caused by:
Sensor_B7_3.Temperature> 85 °C (read 87.2 °C) - Root cause: cooling-fan relay
Q4.2stuck OFF since 13:47 - Confidence: 94% · 3 similar incidents in the last 6 months on the same relay
Recommended action. Replace relay Q4.2 (Part # 3RT2016-1BB42). Est. 15 min. Previous fix confirmed by M. Novák on 2025-11-12.
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/h
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.
441hrs / yr
returned to senior technicians per plant
Senior technicians don't have to be the bottleneck.
An ordinary technician picks up where a PLC specialist used to be needed.
700 €k / plant / yr
saved across the cohort
Reliability numbers that hold up 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, the problem usually isn't the repair itself — it's diagnosing the right problem. Your data already has the answer, scattered across PLC projects, schematics, alarms, journals, and people's heads, but none of it connects. Edmund significantly shortens the diagnostic step.
Without Edmund
With Edmund
01
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.
02
The answer lives in your data. The connections between it don't.
PLC projects, 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.
03
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.
§ The fit test
Three tests. Any one means we should talk.
Tick what matches your line. If none do, your operation probably runs fine without us. We'd rather tell you that on the call than walk you through a sales funnel.
§03 How Edmund works
Edmund speeds up the way you solve faults.
Edmund works with the data you already have. No new systems to build or connect. Your existing infrastructure stays intact. On top of it, we add a diagnostic layer powered by generative AI.
01
Connect to data We read what you already run
Documentation, PLC projects, databases, and people's know-how. Nothing in your production systems gets changed.
02
Process We build a virtual brain of the machine
Components, code, data, and people's notes linked into one system that understands how your line actually behaves.
03
Diagnose A technician asks. Edmund diagnoses.
A technician asks in plain language or with a photo. Edmund searches every data source and answers from it.
04
Repair Clear next steps
Edmund tells the technician what to do, finds the part ID and the replacement procedure, and logs the work into the maintenance journal — instantly available across the company.
§ 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
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 = TRUEmag_empty = FALSE- no fault flags in
mag_eject_faultormag_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
All your plant data and signals, in one platform.
Edmund reads and connects every data source, from PLC programs to handwritten journals, into a single source of truth.
/01 PLC · vendor-agnostic
Understands PLC projects and code from 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
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
+SK3
F124V
F2PSU
F3I/O
F4I/O
F5-94B1
F6
F7I.4.3
+SK4
G1VFD
G2VFD
G3
G4SAFE
+SK5
H1HMI
H2NET
H3NET
H4
H5I/O
H6I/O
H7RES
/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
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
"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
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.
- 26%drop in repair time
- 440hrsman-hours saved per plant, per year
- 90%faster fault diagnosis
- Day 1adoption · 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.
- 30%cut in MTTR · downtime per fault
- 300Kpages 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.
- 10K+data points connected into one platform
- 24/7expert knowledge on the shop floor
- 3ERPs 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
