What does it take to collect data from CNC?

"Data acquisition" gets used loosely in manufacturing conversations, sometimes meaning the whole idea of machine monitoring and sometimes referring to something much more specific: the actual pipeline that moves a value from a sensor or controller register to a number on a dashboard. This article is about that pipeline — the architecture underneath any CNC data collection project, regardless of which protocol or platform sits on top of it. If you're brand new to the topic, our data collection primer is a gentler starting point; this article assumes you already know why data collection matters and want to understand how it's actually built.

Contents:

1. The basic pipeline: source to insight
2. Where data originates on a CNC machine
3. The connection layer
4. Edge processing and local aggregation
5. Transport and storage
6. From acquired data to usable metrics
7. Common architecture mistakes
8. Frequently asked questions
9. Conclusion

The basic pipeline: source to insight

However complex a specific implementation gets, almost every CNC data acquisition setup follows the same basic stages:

• Source — the controller, PLC, or sensor generating the raw value (a spindle load reading, an alarm code, a program status change).
• Connection layer — the protocol or interface used to read that value: MTConnect, OPC UA, a vendor-specific library like FOCAS, or a signal-based method for machines without any of those.
• Edge processing — optional but common: local buffering, filtering, or aggregation before data leaves the machine's immediate network.
• Transport and storage — moving data to wherever it will be kept and queried, whether that's a local database or a cloud-hosted platform.
• Analysis and presentation — the stage where raw acquired values become metrics, dashboards, and reports.

Every architectural decision in a data acquisition project is really a decision about one of these five stages, which is why it helps to think about them separately rather than as one undifferentiated "connect the machine" task.

Where data originates on a CNC machine

Not all data comes from the same place, and knowing the source matters for deciding how to reach it:

• The CNC controller itself holds program execution status, axis positions, and alarm states, typically reachable through a controller-specific protocol or interface.
• The machine's PLC often holds additional state — door interlocks, coolant status, custom logic-driven flags — that may or may not be mirrored into the CNC controller's own data.
• External sensors, where installed, provide data the controller and PLC never had in the first place: vibration, power consumption, ambient temperature.

A complete data picture on a given machine sometimes requires combining more than one of these sources, particularly on machines where relevant data is split between the CNC controller and the PLC.

The connection layer

This is the part most people mean when they talk about "the protocol," and it's covered in depth elsewhere on this blog for each major approach: MTConnect, OPC UA, FANUC FOCAS, Heidenhain's LSV2/DNC interface, SINUMERIK's connectivity options, and Modbus TCP. Architecturally, what matters at this stage is less which specific protocol is used and more a few structural questions: is the connection read-only or bidirectional, does it require polling or does it push updates, and what's the realistic update frequency it can sustain. For machines with no usable open or vendor protocol at all, the connection layer shifts to PLC-level access or hardware-based signal monitoring, which we cover separately in connecting machines with no open protocol.

Edge processing and local aggregation

Between the connection layer and wherever data ultimately gets stored, many architectures include an edge component — a local device or piece of software that sits close to the machine. Its jobs typically include:

• Protocol translation — reading a machine's native interface and republishing it in a more consistent format for downstream systems.
• Local buffering — holding recent data if the network connection to storage is temporarily interrupted, so short outages don't create permanent gaps.
• Basic filtering or aggregation — reducing raw high-frequency samples into summarized values before they're sent onward, which affects both storage volume and network load.

Not every setup needs a dedicated edge layer — on a small deployment, a monitoring platform might poll machines directly — but as fleet size grows, edge processing tends to become more valuable for reliability and network efficiency.

Transport and storage

Once acquired, data has to travel from the machine's local network to wherever it's stored and queried — a local server within the plant, a cloud platform, or some combination of both. This stage brings in its own set of trade-offs around latency, bandwidth, and where processing actually happens, which we cover in more detail separately since it deserves its own treatment. Storage itself is typically structured as time-series data — timestamped values tracked over time rather than single current-state snapshots — which has implications for how it's queried and retained; we go into that specifically in a dedicated primer on time-series machine data.

From acquired data to usable metrics

Acquisition is only half the picture. Raw values — a spindle load reading, a run/stop state, a timestamp — aren't yet the OEE percentages or downtime reports a plant manager actually looks at. That transformation, from raw signal to computed metric, is a distinct step in the architecture with its own logic and potential failure points, which is worth understanding on its own rather than assuming it happens automatically once data starts flowing.

Common architecture mistakes

• Designing the connection layer before deciding what questions the data needs to answer. Starting with "which protocol should we use" instead of "what decisions will this data support" often leads to collecting data that doesn't actually answer the questions that matter.
• No plan for network interruptions. Without local buffering, a temporary network outage between the plant and storage can create permanent gaps in historical data rather than just a delay.
• Treating every machine the same architecturally. A mixed fleet often needs different connection layers for different machines; forcing one uniform approach can mean leaving some equipment out entirely.
• Skipping validation between stages. Confirming that a value looks right at the source doesn't guarantee it still looks right after transport, aggregation, and metric calculation — each stage is a place errors can be introduced silently.

Frequently asked questions

Do I need an edge device for every machine, or only for larger fleets?

Small deployments can often work with a monitoring platform polling machines directly, without a dedicated edge layer. Edge processing becomes more valuable as fleet size grows, network reliability becomes a concern, or protocol translation is needed for machines with proprietary interfaces.

Is data acquisition architecture the same regardless of which protocol I use?

The five-stage structure — source, connection, edge, transport/storage, analysis — applies broadly, but the specifics of the connection layer differ significantly depending on whether you're using MTConnect, OPC UA, a vendor-specific library, or signal-based methods for legacy equipment.

How much of this should a manufacturer build versus buy?

Most manufacturers use a monitoring platform that already implements most of this pipeline — connection, edge processing, storage, and metric calculation — rather than building each stage independently. Understanding the architecture is still useful for evaluating what a given platform actually does versus what it claims to do.

Where does data quality fit into this architecture?

Data quality issues can be introduced at any stage — a misconfigured sensor, a dropped connection, an incorrect aggregation rule — which is why validating data at multiple points in the pipeline matters more than trusting a single end-to-end check.

Conclusion

CNC data acquisition is a pipeline, not a single connection: data originates somewhere specific, moves through a connection layer, is optionally processed at the edge, gets transported and stored, and only then becomes a usable metric. Understanding these stages separately makes it much easier to diagnose problems, evaluate platforms, and design an architecture that actually fits a specific fleet rather than assuming one protocol or one tool handles everything end to end.

Related articles:

• Data Collection for Beginners
• Connecting Machines with No Open Protocol
• MTConnect Explained: How the Manufacturing Data Standard Works
• PLC Data Collection: Your Bridge from Tradition to Tomorrow
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.