Most factories already record how long every machine runs and stands still. Nobody reads it, because it sits inside the machine in a format built for service engineers.

What the machine saves
06:04:12;EV17;0;D:\PRG\A4471_R2.PRG;S;0001 06:52:40;EV18;0;D:\PRG\A4471_R2.PRG;E;0001 06:53:30;EV03;1;;; 06:58:11;AL214;2;DOOR INTLK;; 07:03:02;AL214;0;;; 07:05:31;EV17;0;D:\PRG\B0920_R1.PRG;S;0002 08:21:07;EV18;0;D:\PRG\B0920_R1.PRG;E;0002
What you need to see
M2 · 06:00 TO 09:00 06:0007:0008:0009:00 RUNNING 2H 16M OF 3H · 76%
Same morning, same data. Left as the controller writes it, right as a production manager needs it. Illustrative data.

I saw this first-hand in a UK factory running six machines. Everyone had a feel for how busy the machines were. "Pretty much flat out" was the usual answer. Nobody had a number, because nobody believed the data existed.

It did. Every machine kept its own job history. It just looked like noise: codes, timestamps, file paths, no totals. Once those files were turned into one readable view, the first measured day showed the machines running about 80% of planned time. A good chunk of every shift had gone missing between jobs, and no one had noticed.

The number alone changed things. Once the team could see it every day, the average climbed to about 91%. Same machines, same people. The only new thing was being able to see.

This guide shows you where that data hides on your own floor, who to ask, and what to do in your first afternoon.

Why the number in your head is too kind

If you track stoppages at all, you probably do it by hand. A sheet by the machine, a box on the job card, a figure at the end of the shift. That is honest work, but it misses the same things in every factory.

  • Short stops. Two minutes waiting for material does not feel worth writing down. Forty of them is over an hour.
  • The gap between jobs. Unloading, finding the next file, a quick chat. The machine is idle, but nobody calls it a stop.
  • Rounded memory. A stop written down at 10 pm about something at 3 pm becomes "about 15 minutes".
  • Running slow. A machine running at half speed counts as running. The lost time never shows up as a stop.

None of this is anyone's fault. People are there to make parts, not to keep a stopwatch. Companies that sell monitoring systems often say the first automatic measurement shows two to three times more lost time than the plant believed. Treat that as a rough guide, not a promise. The point is simpler: the machine keeps a more honest record than any of us can.

Who to ask

You do not need IT or a consultant to start. The answers usually sit with four people you already know.

The operator

Uses the screen every day and has seen menus nobody else opens.

"Is there a history, log or report screen on the machine? Can it save to a USB stick?"

Maintenance

Knows the drives, panels and hour counters inside the cabinet.

"Do the drives or the panel keep run hours or an alarm history? Can we read it without changing anything?"

The machine supplier's service engineer

Knows exactly what the controller stores and how to get it out.

"What does this controller log, how many days does it keep, and how do we export it?"

Whoever looks after the ERP

Knows what gets booked against each job.

"Do we record job start and finish times, or quantities per shift? Can I get last month as a spreadsheet?"

One tip: ask about exports, not changes. "Can we save what is already there?" gets a yes far more often than "Can we connect something to the machine?"

Six places the data hides

Start with the one closest to hand. You only need one source to begin.

1824h OFFICE 1 2 3 4 5 6
Six places to look. Four on the floor, two in the office. Number 6 is for older machines that have nothing to export yet.
1

The machine's own controller

A history of programs or jobs run, with start and finish times. Moulding machines often keep shot counts and cycle times.

Look for History, Log, Job report or Statistics on the screen. Many save as CSV to a USB stick.

When the machine actually worked, job by job.

2

The drive cabinet

Many drives count "run hours" and "power-on hours" separately.

Ask maintenance to read both from the drive's display. It needs no setting changed, but the cabinet is theirs: never open it yourself.

Two numbers, one ratio: how much of its switched-on time the machine really works.

3

The operator panel

Alarm history: every fault, when it started and when it cleared.

Often an "export alarm history" option to USB or SD card.

Which stops repeat, and how long each one costs.

4

Your ERP or job system

Job start and finish bookings, quantities per shift, scrap booked.

A standard report exported to Excel. Ask for one month.

Planned against actual, per job. Useful even with no machine data at all.

5

Your file folders

Programs and job files, each with the date and time it was saved.

Sort the folder by "date modified".

A rough timeline of what was prepared and sent to the floor.

6

The power cable

Nothing yet, on older machines with no screen worth asking.

A clamp-on current sensor on one wire of the supply. It does not touch the machine's controls, but it goes inside the electrical panel, so an electrician fits it.

Running, idle or off, minute by minute. On presses and moulding machines it can even count cycles.

For the curious

A controller is the small computer that runs the machine. It logs events for its own use and for service visits. Nobody designed those logs for a production manager, which is why they look so unfriendly.

One warning: most machines only keep a short history. Some keep about a month of jobs, some the last thousand cycles, some only the last day. Older records are written over.

ABOUT 30 DAYS KEPT ALREADY WRITTEN OVER 60 DAYS AGOTODAY SAVE ONE EXPORT A WEEK AND NOTHING IS LOST
A typical controller memory. Every week you wait is a week of data you cannot get back.

Your first afternoon: save it, don't read it

Your only job today is to make sure the data stops disappearing. Understanding it can wait.

  1. Pick one machine. The busiest one, or the one everyone argues about.
  2. Look at its screen with the operator. Find the history, counter or alarm page.
  3. Write down the counters at the start and end of every shift for a week, and every stop over 5 minutes. The shift log in the checklist below is made for this.
  4. If the screen offers an export, ask whoever looks after the machine whether a USB stick is allowed. Many sites block them, and that is fine: a week of readings is enough to start. If you can export, save one file a week with the machine name and date in the file name, so the history stops being written over.

Then open the file, if you are curious. It will probably look something like this:

2026-10-06 06:02:11;EV17;0;D:\PRG\A4471_R2.PRG;S;0001
2026-10-06 06:02:14;EV03;1;;;
2026-10-06 06:41:57;EV18;0;D:\PRG\A4471_R2.PRG;E;0001;002385
2026-10-06 06:58:30;AL214;2;DOOR INTLK;;
2026-10-06 07:03:02;AL214;0;;;
2026-10-06 07:03:09;EV17;0;D:\PRG\A4471_R2.PRG;S;0002

If that means nothing to you, good. It means nothing to most people. It was written for a service engineer with the manual open, not for someone running a shift.

But look closer. Every line has a time. Somewhere in those lines is when the machine started, when it stopped, why it stopped, and for how long. Across a month of files, that is every shift you ran. You were just never given a way to read it. So let's read one.

Try it yourself · about 2 minutes

Decode a raw machine log

One machine, one 8-hour shift, exactly as the controller saved it. No software skills needed. You will do by hand what my tools do every night.

1

Make a guess first

How much of the shift do you think this machine was actually running?

88%

2

Crack the four codes

Most lines are noise. Four codes carry the story. Tap a code, then tap what you think it means.

Lock in your guess first.


          

D:\LOG\EVT_20261006.CSV · lines · saved by the machine, not written for you

Codes

Meanings

Clue from the service manualLook at the letter after the file name, S or E. Alarm lines repeat their code: the number after it is 2 while the fault is active and 0 once it clears.

3

Write the rules

Now tell the decoder what to measure. Tap an empty box, then tap the event that belongs there.

Crack all four codes first.

Events


          

Your rules, written as code. Each rule you get right switches its lines on. This is the core of a real decoder.

4

Run it

The decoder reads every line, keeps what your rules care about and draws the shift.

Finish all three rules first.

5

Now picture your whole floor

Run the decoder first.

You decoded one machine for one shift. Next, put that number to work on a real job: the calculator below already has it.

After that: a real floor has several machines, each writing its own format, and the files get written over every few weeks. That is the part I build.

Put it on a real job ↓

Example data, invented for this exercise. Not from any real machine or client.

Keep it · free toolYours to keep

Turn one job into a number you can plan with

This one is yours, not part of the puzzle. Bookmark it and use it whenever an order lands and someone asks when it will be done.

One line from a log is enough. Take how long a cycle ran and how many parts it made, and see the ceiling: what the machine makes if it never stops. No machine does, so it plans with a real running % too. Measured, guessed, or the puzzle's number, which drops in by itself once you solve it.

Use it whenan order lands · a customer asks for a date · someone says "flat out"

Keep it: open it on its own page and bookmark it →

What I do with it

This is the part I build. You bring the files you saved. I turn them into something you can run the floor on.

M1 · .CSV M2 · .LOG M3 · .TXT THREE MACHINES, THREE FORMATS DECODER your rules ONE CONTINUOUS RECORD W38W39W40W41
Every machine writes its own way. The decoder makes them speak one language and adds each new export to the same record. Illustrative data.
  • Readable. Each raw log becomes a plain picture of the shift: running, stopped, changing over. Per machine, per day, with the hours added up.
  • Standardised. Every machine writes its files differently. I make them all speak the same language, so every new export joins the ones before it in one continuous record.
  • Kept. Your history stops being written over. Pick any week or month you have exports for and compare it with any other.

The tool only reads the exports you already make. It does not connect to your machines or your ERP, and it does not change a single setting. It is built around how your team already works, and you own it. You can watch the machine data tool run on the tools page.

A tool like this costs about £1,700, as a fixed price agreed in writing. Your first tool is paid for only when it works as agreed.

Keep it · free to printYours to keep

Checklist and shift log: find your machine data

Everything here can be done at the machine with a pen. No IT, no tools, nothing opened.

Find your machine data

One machine, one week.

Rule firstLook, don't open. Anything behind a cover or panel goes to maintenance. Follow your site's rules.

Look at the screen

  • Job or program history: is there a page listing past jobs?
  • Counters: parts made, run hours, power-on hours
  • Alarm history: which alarms come up most?

Write it down, each shift

  • Counter readings at the start and end of the shift
  • Every stop over 5 minutes: when, how long, why
  • A photo of the history page, where phones are allowed

Ask on the floor

  • Operators: when does it stop most, and why?
  • Supplier, on the next service visit: what does the controller log, and for how long?

Keep the sheets

  • One sheet per machine, one week. Keep the sheets together.

Got a week of readings? That's enough to start.

Print it with your machines on it →

Add your machines and who to ask, then print the checklist (one page) and a one-week shift log for each machine. It remembers your machines for next week.