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.
Find a servo drive and explain its activation conditions in the PLC program.
Found the servo control block FB 1343 Faulhaber MCBL. The drive is enabled when it is online, not cancelled, and a motion command (Home / Jog / Positioning) requests it.
142//Go Hall Zero 143IF #GoHallZero AND NOT #Cancel AND NOT #Stop THEN 144 IF NOT #status.enabled THEN 145 #state.enable.start := true; 146 END_IF; 147 #state.goHallZero.start := true; 148 #status.done := false; 149END_IF;
Where is -94B1 wired, and where do I find it in the cabinet?
-94B1 is the product-detect photocell (SICK WL12-2P430) on conveyor 3. It's wired to input %I4.3 on DI module -A4, through terminal X1:11–12 in cabinet +SK3.
How did IMM01 spend its energy the week of Jan 12? Anything wasteful?
Pulled IMM01 power from the MES historian for Jan 12–18, 2026 and bucketed it by machine state:
IMM01 (kWh) Over DateTime — Weekly Trend
IMM01(kWh)
Total hours per state (Jan 12–18, 2026)
OFF 63 h ON_NO_PROD 74 h PROD 31 h
The machine drew power while idle for 74 h — more than double its 31 h of actual production. Trimming idle time is the fastest saving here.
What does the WL12 datasheet say about cleaning it in dusty conditions?
From the SICK datasheet (rev 04/2024):
"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 ↗
Your maintenance log shows the lens was last cleaned 312 h ago — past the 240 h interval, which lines up with the repeated photocell dropouts.
Has anyone fixed the Station 52 photocell before? What did they do?
Yes — the Station 52 photocell replacement (Tomáš Marek, Apr 23) sits at the top of the Line 4 journal, indexed alongside every recent fix:
NameStatusCreated
Station 52 – photocell replacementTomas MarekIndexedApr 23
Cell 7 – main panelTomas MarekIndexedApr 23
St 31/32 servo motor offlinePetr DolezalIndexedApr 15
WP transfer fault – station 13Jan HorakIndexedApr 14
Line commissioningTomas MarekIndexedApr 13
Cell 3 – calibrationPetr DolezalIndexedMar 26
34 entries‹ 1 2 3 4 ›
Open any entry for the full symptom, cause, and fix — so the next technician inherits it instead of rediscovering it.
For Assembly line 4 — what's indexed, and is everything current?
Assembly line 4 is fully indexed and every source is active:
Documents547▲ 41 last 30d
Maintenance journals34▲ 2 last 30d
PLC programs4S7-1500 · TIA
Data sources3DB · files · OPC
Documents by category All active
547docs
Spare parts catalog211
Mechanical drawings128
Machine & component docs112
Schematic diagrams96
Last PLC sync · 6 days agoNewest journal · 2 days ago
A plant lead can confirm coverage at a glance — and catch a source that's gone stale before someone hits the gap mid-fault.
Ask Edmund, try "where is -94B1 wired?" ⌘ 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.
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.
§ Siemens Industrial Copilot vs Edmund
Ask both why conveyor 3 keeps stopping.
Here, Copilot means Siemens Industrial Copilot, Siemens' own factory-floor AI, not the Microsoft 365 office assistant. Edmund reads the Siemens stack too, alongside the other controllers and the records around them.
Siemens Industrial Copilot is a real diagnostic assistant, and a good one, on Siemens equipment. It reads the TIA project, translates Siemens fault codes, and works through the Siemens manuals. But your plant isn't all Siemens, and the answer at 2 a.m. isn't all in the Siemens manuals. Edmund reads the Siemens line and the Rockwell cell next to it, plus the schematic, the journals, the MES, and it cites where every answer came from.
Conveyor 3 keeps stopping with a photocell fault. What should I check?
The conveyor 3 fault is a photocell signal fault on the SIMATIC controller. I've translated the HMI message and pulled the troubleshooting steps from the machine manual.
Documented checks: clean the sensor lens, verify the alignment, inspect the sensor wiring. The spare-part list has the replacement sensor if you need it.
Strong on the Siemens side: it reads the TIA project and the Siemens manuals. It stops at the Siemens stack, though — not the third-party sensor's place in the schematic, not the journal where the last tech logged this, not that it's the third stop this month.
Conveyor 3 keeps stopping with a photocell fault. What should I check?
That's -94B1, the SICK WL12-2P430 photo-eye on conveyor 3 — input %I4.3, part of the run interlock in FB_Conv3_Control, line 48.
It's the third photocell stop on this conveyor in 30 days. The lens was last cleaned 312 h ago; the maintenance plan calls for every 240 h in this dust class. Clean the lens and the reflector first. If the fault returns, check terminals X1:11–12 in cabinet +SK3.
Same Siemens PLC, plus the third-party sensor, its place in the schematic, and the repair history. Each line cited, so the technician can check it before opening the cabinet.
Siemens Industrial Copilot Edmund
/Controllers Built around SIMATIC and TIA Portal. Its cross-vendor reach is sensor data, not the control logic. Reads the PLC projects themselves — Siemens, Rockwell, Omron — into one model.
/Sources Siemens manuals, fault codes, spare-part lists, TIA documentation, plus Senseye sensor data. PLC code, EPLAN schematics, SQL and MES, manuals, free-text journals, all linked together.
/Schematics Co-authors EPLAN diagrams on the engineering side. Not built to trace your existing schematic to a fault. Traces the live schematic: sheet, cabinet, terminal.
/Repair history Structured machine history and condition data. The free-text journal: the note the last technician actually wrote.
/Citations Cites the Siemens manuals, fault codes, and TIA project it drew on. The exact source — code line, schematic sheet, journal entry.
/Built for Tuned for SIMATIC and TIA environments. Any mix of controllers and records on the floor.
On Siemens equipment, both will answer. The difference shows when the fault crosses into the rest of the plant.
None of this is a knock on Siemens' copilot — it troubleshoots well from Siemens fault codes and manuals, and Senseye brings predictive maintenance across sensor data from any vendor. Two things it isn't built for, as of mid-2026: reading a competitor's PLC project to diagnose its logic, and tracing your existing EPLAN schematic or free-text journals to find a fault. That's the gap Edmund fills, across the whole plant, Siemens included.
§ 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 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.
More vendors coming soon: 
SCL PLC Program Block Example
Messages
Find a servo drive and explain its activation conditions in the PLC program
Searching programs · servo drive enable / activation logicProgram logic
Found the servo control block FB 1343 Faulhaber MCBL. The drive is enabled when it is online, not cancelled, and a motion command (Home / Jog / Positioning) requests it:
142//Go Hall Zero 143IF #GoHallZero AND NOT #Cancel AND NOT #Stop THEN 144 IF NOT #status.enabled THEN 145 #state.enable.start := true; 146 END_IF; 147 #state.goHallZero.start := true; 148 #status.done := false; 149END_IF; 150//Position abnullen 151IF #SetPositionNull AND #status.online THEN 152 #state.setPositionNull.start := true; 153END_IF;
Sources
0003 - Customer specific functions1
0004 - Process3
St-31 Spindling 12
Faulhaber5
RS232 communication2
FB 1343 Faulhaber MCBL S7-1500 Siemens_2020_08_03.scl
FB 1343 Faulhaber MCBL S7-1500 Siemens.scl✓ Cited
FB9001 Faulhaber MC5010 S (Murr RS232).scl
FB9002 Faulhaber CRC8.scl
calculateTargetPos.scl
/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
Supports PDF exports from: 
Find -94B1 in the cabinet
Messages
Where is -94B1 wired, and where do I find it in the cabinet?
Searching schematics · EPLAN =CMM+SK3Schematic
-94B1 is the product-detect photocell (SICK WL12-2P430) on conveyor 3. It’s wired to input %I4.3 on DI module -A4, through terminal X1:11–12 in cabinet +SK3.
Sources
=CMM+SK3 · PLC I/O · sheet 3✓ Cited
+SK3 · terminal plan X1
Device list · -94B1 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.
MES ERP Time-series 10+ DB connectors Suggestion · IMM01 consumption analysis
Owned by Petr Messages
Period: week of Jan 12, 2026
Searching database
Running code
IMM01 (kWh) Over DateTime — Weekly Trend
IMM01(kWh)
Total hours per state (Jan 12–18, 2026)
OFF 63 h ON_NO_PROD 74 h PROD 31 h
/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.
Drawings · schematics · PDF Manuals · datasheets Multilingual Cited every time
Supports PDF exports from:
"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 ↗
Sources
PDFWL12-2P430 · datasheetp. 7
PDF+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
NameStatusCreated
Station 52 – photocell replacementTomas MarekIndexedApr 23
Cell 7 – main panelTomas MarekIndexedApr 23
St 31/32 servo motor offlinePetr DolezalIndexedApr 15
WP transfer fault – station 13Jan HorakIndexedApr 14
Line commissioningTomas MarekIndexedApr 13
Cell 3 – calibrationPetr DolezalIndexedMar 26
34 entries‹ 1 2 3 4 ›
/06 Data health · every source, one view
Shows what’s indexed, and whether every source is current.
Every project keeps a live count of indexed documents, journals, PLC programs, and connected sources, each with its status and last-sync time. A plant lead can confirm coverage at a glance and catch a source that’s gone stale before someone hits the gap mid-fault.
Coverage counts Per-source status Last-sync freshness
Documents547▲ 41 last 30d
Maintenance journals34▲ 2 last 30d
PLC programs4S7-1500 · TIA
Data sources3DB · files · OPC
Documents by category All active
547docs
Spare parts catalog211
Mechanical drawings128
Machine & component docs112
Schematic diagrams96
Last PLC sync · 6 days agoNewest journal · 2 days ago
§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 we cut MTTR by 30% in a corrugated-packaging plant.
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 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.
§06 What people say
People running Edmund every day.
References from our customers
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
New production lines and machines are coming to our plant, and we don't yet have the experience to diagnose them efficiently. At the same time, we can't grow the maintenance team to keep up. So we use Edmund AI as an "invisible co-worker": it fills the missing know-how, supports our technicians' decisions, and speeds up finding and fixing faults.
Ivo Vítek
Head of Maintenance · Innomotics
Industry 4.0 promised a lot but delivered very little. Edmund is genuinely making a difference.
Filip Škeřík
Head of automation · Festo
§ 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
