Getting data off the machine: sampling, timestamps and context that survives

Sample rate is decided by the phenomenon, not by convenience

Capturing more slowly than a signal changes does not merely lose detail, it produces false patterns: a fast oscillation sampled slowly reappears as a slow drift that does not exist. Vibration, current waveform and pressure transients need rates far above what a supervisory system typically collects, while a tank temperature does not. Decide from the physics of what you are watching and from the shortest event you must be able to see. Where a high rate is genuinely required, capture it near the machine and reduce it there rather than attempting to transport and store every point across the plant.

What happens between samples matters as much

A value read once per interval reports one moment; the peak that caused the damage may have occurred between readings. For quantities where extremes matter, capture minimum, maximum and mean over each interval rather than a single snapshot, or record on change with a defined threshold. Averaging is not neutral either: an average across a period containing both running and stopped time describes neither condition. Be explicit about what each stored value represents, and store that definition with the tag, because an analyst confronted with a column of numbers has no way to infer whether they are single readings or interval statistics.

Clocks that disagree destroy cause and effect

Data arriving from controllers, inspection stations, energy meters and manual entries carries whatever time each device believed. Left unsynchronised, those clocks drift apart steadily, and any analysis linking a process condition to a downstream defect becomes guesswork or worse, showing effects apparently preceding causes. Synchronise every device that timestamps anything against a common source, decide whether the timestamp is applied at the device or on receipt, and record which. Also settle time zone and daylight handling once, at the plant level, or you will spend an entire shift each year explaining a duplicated or missing hour in the production record.

A value without context is not information

A temperature reading is nearly useless on its own. To answer a real question it needs to be associated with which product was running, which batch or order, which tool or cavity, which operator and which shift, and what the machine state was at the time. Attaching that at capture is straightforward; reconstructing it afterwards from separate systems is an exercise in approximate joins that nobody trusts. The most valuable single improvement most plants can make to their data is ensuring a machine's process signals and its current job identity are recorded together, so a later question about one product can actually be asked.

Conditioning, quality flags and the reading that was never real

Signals arrive with noise, offsets, disconnected inputs reading as zero and devices reporting a fault while still emitting a plausible number. Filtering removes noise and also removes the transient you were hoping to see, so apply it deliberately and record what was applied. More importantly, carry a quality indication with every value: whether the sensor reported healthy, whether the value was substituted, whether the reading was outside the device range. Datasets without quality flags force analysts to invent their own rules for discarding suspect points, and every analyst invents different ones.

Frequently asked questions

How fast should we sample a process signal?

Fast enough that the shortest event you care about is represented by several readings rather than one. Work backwards from that event: a slow thermal trend needs very little, a pressure spike or a motor current signature needs a great deal. Sampling too slowly is the more damaging error because it can manufacture apparent patterns that are pure artefact. Where high rates are needed only occasionally, a triggered capture that records a detailed window around an event is usually more practical than continuous high-rate collection.

Should timestamps be applied at the device or when the data is received?

At the device wherever possible, provided its clock is synchronised, because receipt time includes network delay and any buffering after a connection loss. Data forwarded after an outage will otherwise all appear to have occurred at the moment the link recovered, which destroys the record of what happened during the disturbance. Whichever you choose, record it explicitly with the tag, since an analyst comparing two sources that use different conventions will otherwise draw confident conclusions about a lag that is purely an artefact.

What context should be recorded alongside process values?

At minimum the product or part being made, the order or batch identity, the machine state, and the tool, cavity or head where relevant. Shift and operator help for some questions and raise legitimate concerns about individual monitoring, so agree that use openly. The test is whether someone could later isolate every reading taken while making a particular product on a particular tool. If not, most root-cause questions will require manual reconstruction from separate records, which rarely gets done.