Data Logging

Automation|Process Desk|

Data logging is the keeping of the record a machine makes of its own life — the states it passes through, the alarms it raises, the parts it cycles, the loads it carries — written down over time so the shop can read its own past. Machine connectivity is the pipe that carries a machine’s data off the machine; data logging is what the pipe is for, the store that turns a moment’s reading into a history. A shop that never logs runs on memory and opinion: the sense that a machine is always down, that a job always runs late, that one shift cuts faster than another. A shop that logs well runs on evidence: the day’s states reconstruct as a bar of cutting and idle and setup, the alarms accumulate into a list that shows the same fault returning, and the questions that once were argued are answered by the record. This entry treats what is worth recording, how the record is kept honest, and how a log earns its keep by being read.

The anatomy of a machine’s time

The heart of the log is time, divided honestly among the states a machine can be in. A machining centre’s day is a sequence of spans — cutting while it runs a cycle, ready while it waits with a finished part in the vice, setup or changeover while the next job goes on, down while it stops on a fault or waits for a person, off while the shop sleeps. Each minute belongs to one state, and the state log — kept by the machine itself where it can tell cutting from idle, and by a person where it cannot — is what the day is rebuilt from: the run time the shop is paid for, the idle and setup time that it is not, the down time it must explain. From that single honest division of time come the utilisation figures every shop quotes, and the discipline of the log is that every minute lands somewhere, and no minute lands twice.

The events worth keeping

States record how long; events record what happened. The useful log keeps the events that mean something and lets the rest go. The alarms, each with its code, its time and its plain-language meaning, accumulate into the list that shows the same fault returning on the same machine every week. The program runs — the program number, the part count, the cycle time of each run — become the record of what was made, when and how fast. The tool uses, each tool change counted, tell the shop how many parts a cutter truly made before it was changed. The measurements — the sizes that a probe or an in-process gauge reports — follow the part’s quality through the run. And samples of spindle load and vibration, kept at intervals rather than continuously, give each machine’s health a history that a single reading cannot.

Sampling, and the honest log

Logging is a discipline of sampling and of honesty. The record samples what it keeps: a machine’s state changes only when it changes, so states can be logged exactly; a load read every few seconds is enough to show a trend, while reading it a thousand times a second would only fill the store. The record must also be true — a collector that drops when a machine’s network hiccups, silently missing an hour of idle, makes a log that lies, and a lie is worse than no log because it is believed. The softest part of any log is the reason a person must type: a machine knows it stopped, but only a person knows why, and the shop earns honest reasons by making them cheap — a list of taps for the common causes rather than a keyboard for the rare. A clean, honest, well-named record of a few things beats a complete record of everything, every time.

The questions the log answers

Each thing worth recording earns its place by a question it answers. The state log answers where the time goes: which machine gates the shop’s delivery, how much of a shift is really cutting, and how a quoted job time compares with the actual, as this wiki’s machining job cycle frames it. The alarm log answers what stops the shop: the same fault every Tuesday is not bad luck but a machine wearing on a schedule, and the maintenance plan that reads its own alarm history catches a fault while it is still a pattern rather than a breakdown. The part and tool counts answer the honest cost of a job and the honest life of a tool. Together the streams fold into one summary of how well a machine turns its time into good parts — the availability the state log measures, the performance the cycle times measure, the quality the measurements record — and that summary tells a shop whether each machine earns its place.

The log that is read

The final discipline is that the log is read, for a record no one reads is only expense. The shop that logs well schedules the reading — a weekly look at the states and the alarms, the exceptions questioned, the pattern acted on — and closes the loop: the repeated alarm is fixed, the idle machine is fed, the job that ran over its estimate is understood. Data logging is the memory of the automated shop: connectivity carries the data, monitoring watches it live, and logging keeps it, so that the shop improves by what the record shows rather than by what someone remembers. A machine that keeps an honest log gives the shop its past, and the shop that reads it earns the right to plan on what actually happened rather than on what it hopes did.

Related