Python Libraries and Official APIs for CNC Controller Data Collection: A Complete Guide

"What Python library do I use to pull data off this machine?" is a question I get asked about a different control almost every month, and the honest answer is always it depends which one. There's no single SDK for "CNC machines" — there's FOCAS for FANUC, LSV2 for HEIDENHAIN, OPC UA for Siemens, MTConnect for whoever bothered to implement it, and a handful of proprietary protocols nobody outside the machine builder fully documents. I've built collectors against several of these for real shop-floor projects, and this is the map I wish existed when I started: every major controller, its official channel, the Python library that actually works against it, and what you're licensed to do with any of it.

Why collect data from a CNC controller at all?

Every number in this section already exists inside your controls. The only question is whether it stays trapped on a screen next to the machine or starts feeding systems that make the shop better. That's the entire pitch for Industry 4.0 in a machine shop: not robots and buzzwords, just getting the data that's already there into a place software can use it.

• OEE, honestly measured. Run state, cycle counts, and downtime read straight off the control turn OEE from a Friday spreadsheet ritual into a live number instead of an operator's best guess.
• Predictive maintenance. Spindle load, vibration, and servo diagnostics trended over weeks catch a failing bearing before it strands a job — the same FFT technique that reads a vibration trace needs a data feed to trend against.
• Live dashboards and andon boards. A wall monitor showing what every machine is doing right now, sourced from the controls instead of someone walking the floor with a clipboard.
• MES and ERP integration. Actual cycle times and part counts flowing into your MES beat the planned times it was seeded with — machines report reality, not the schedule.
• SPC without a clipboard. Probing results and in-process measurements already land in macro variables or system registers; reading them automatically is the difference between real-time control charts and a shift-end transcription job.
• Automated reporting. Shift summaries, scrap reports, and utilization rollups generate themselves once the raw numbers are flowing somewhere queryable.
• Digital twins and remote diagnostics. You can't mirror a machine's state, or diagnose it from your phone, without first reading that state off the control.

How CNC controllers actually talk to the outside world

Before the controller-by-controller detail, it helps to know the handful of kinds of channel you'll run into. Almost every integration on this page is one of these:

• Official manufacturer SDKs. A vendor-provided library — FANUC's FOCAS, Okuma's THINC-API, Beckhoff's ADS — that talks the control's native, undocumented-to-outsiders wire protocol. Deepest access, narrowest scope: one SDK, one brand.
• Proprietary Ethernet protocols. Simpler, sometimes officially documented text or binary protocols over plain TCP — Haas's Q Commands, Fagor's PC-CNC protocol. No SDK required, but you're on your own for anything the documentation doesn't cover.
• OPC UA. An open, secure, cross-vendor industrial standard. You subscribe to nodes in an address space and get pushed updates — the closest thing to a universal answer, where the control supports it.
• MTConnect. An open, manufacturing-specific standard: an adapter feeds a plain-text stream, an agent serves clean XML over HTTP. Read-only, dead simple to consume, cross-vendor.
• REST APIs. Increasingly common on cloud-connected platforms (Mazak's iSMART Factory, ANCA's gCONNECT, DMG MORI's ADAMOS) — usually paid, usually gatewayed through the vendor's own cloud rather than talking to the control directly.
• PLC / fieldbus communication. Where the CNC and the PLC share memory, reading the PLC directly (Modbus, EtherNet/IP, MC Protocol, ADS) gets you machine state without touching the NC side at all — the standard route for Mitsubishi and Beckhoff-based controls.
• Serial / legacy protocols. Pre-Ethernet controls that still earn their keep on the floor. No API to speak of — just RS-232 and matching baud rates.

Controller-by-controller: official methods, SDKs, and protocols

Fourteen controllers you'll actually run into on a shop floor, and how each one officially wants to be talked to. "Official" doesn't always mean "documented for outsiders" — a few of these are gated behind a reseller relationship or a paid option, which the next table covers.

Controller-by-controller: Python libraries, licensing, and what you can collect

Same fourteen controllers, now with the part that actually matters to a developer: what runs in Python today, what it costs, and what data actually comes back.

Open-source Python libraries, compared

Zooming into the libraries themselves — the ones you'll actually pip install — rather than the controllers they target:

Worth being precise about scope: pymodbus, pycomm3, and fanucpy aren't CNC libraries — the first two talk to PLCs and drives, and fanucpy (despite the name) drives FANUC robot arms, not FANUC CNC controls. All three show up constantly in machining-cell projects anyway, because a tending robot, a coolant system, or a VFD spindle drive is often easier to read over its own protocol than to extract from the CNC itself. If your "CNC data" question is really "what's happening around the CNC," they belong in the toolbox.

A quick look at three of these in practice — connect, read one value, done:

import pyLSV2

con = pyLSV2.LSV2('192.168.1.5', port=19000, timeout=15, safe_mode=True)
con.connect()

status = con.get_program_status()
info = con.get_versions()
print('program status:', status)
print('control info:', info)

con.disconnect()

import asyncio
from asyncua import Client

async def main():
    async with Client(url='opc.tcp://192.168.1.20:4840') as client:
        node = client.get_node('ns=2;s=Channel1.SpindleSpeed')
        value = await node.read_value()
        print('spindle speed:', value)

asyncio.run(main())

import pyads

plc = pyads.Connection('5.24.34.100.1.1', pyads.PORT_TC3PLC1)

with plc:
    x_pos = plc.read_by_name('MAIN.axisPositionX', pyads.PLCTYPE_LREAL)
    print('X position:', x_pos)

Three different libraries, three different wire protocols, and — deliberately — almost the same shape: connect, read a value, disconnect. That shape is the thing worth internalizing more than any one API.

For the three protocols with the most ground to cover — FOCAS, MTConnect, and OPC UA — the code library has full, tested, copy-ready versions of these patterns, not just the trimmed-down snippets above:

Official SDK or open-source library? How to choose

This isn't really an "either/or" — most real fleets end up running both, on different machines. But when you're staring at one control deciding where to start:

• Official SDKs win on depth and support. FOCAS, THINC-API, and RemoTools expose things community wrappers can't reach — deep diagnostics, write access, guaranteed behavior across firmware versions — and when something breaks, there's a vendor to call.
• Official SDKs lose on friction. Licensing costs, NDAs, Windows-only DLLs, and support cycles measured in ticket queues, not GitHub issues. Getting a THINC-API or Open Core Engineering license moving can take longer than writing the whole rest of your collector.
• Open-source libraries win on speed and cost. pip install, read the source when the docs run out, and you're reading data the same afternoon. pyads, asyncua, and pyLSV2 are all mature enough to trust in production.
• Open-source libraries lose on guarantees. No SLA, no vendor support line, and maintenance depends on volunteers — pyLSV2 in particular reverse-engineers an undocumented protocol, so new HEIDENHAIN firmware occasionally breaks something until the maintainers catch up.

Comparison matrix: ranking each controller for Python integration

A rougher, more opinionated cut — how each platform actually feels to integrate, from someone who's had to do it under a deadline:

*HEIDENHAIN's spread reflects two very different paths to the same control: pyLSV2 is free, but the officially licensed RemoTools SDK is not.

Don't pick the controller with the best rating on this table — pick the one your shop already owns, and use this table to set expectations for how much runway you'll need.

Real-world use cases

This all sounds abstract until it's running against real machines. Here's what people actually build once the data starts flowing:

• Live machine monitoring. A dashboard or andon board showing every machine's cycle state, program, and alarms in real time — the most common first project, and usually the fastest to justify.
• Tool life tracking. Reading tool tables and usage counters (FOCAS, LSV2, or PLC-side) to flag a tool nearing end-of-life before it snaps mid-cut instead of after.
• Predictive maintenance. Trending spindle load, servo diagnostics, and vibration spectra over weeks to catch a failing bearing or misalignment on a schedule you choose, not one a breakdown chooses for you.
• Automated reporting. Shift summaries and scrap reports generated from real cycle data instead of an end-of-shift spreadsheet — a natural pairing with openpyxl for the output side.
• Production dashboards and OEE. Availability, performance, and quality computed continuously instead of recreated by hand every Friday.
• Digital twins. Mirroring real axis positions and machine state into a 3D visualization or simulation — genuinely useful for training and remote visibility, genuinely oversold as a replacement for walking the floor.
• Remote diagnostics. Alarm history and machine state reachable from a phone or a service laptop, so a controls engineer can triage before driving in — and, increasingly, the read-only data layer that an AI agent sits on top of to answer plain-language questions about the floor.

One data model, many protocols: building a universal collector

The mistake I see most often isn't a wrong protocol choice — it's building the FANUC collector, then the Beckhoff collector, then the Siemens collector, as three unrelated codebases that each grow their own downstream logic. The fix is boring and durable: define one internal shape for a machine reading, and make every protocol-specific collector responsible for nothing but filling it in.

from dataclasses import dataclass
from datetime import datetime, timezone
from typing import Optional

@dataclass
class MachineReading:
    machine_id: str
    source: str          # 'focas' | 'opcua' | 'mtconnect' | 'ads' | 'lsv2'
    timestamp: datetime
    program: Optional[str] = None
    spindle_speed: Optional[float] = None
    feed_rate: Optional[float] = None
    axis_x: Optional[float] = None
    axis_y: Optional[float] = None
    axis_z: Optional[float] = None
    alarm: Optional[str] = None

def from_opcua(machine_id: str, node_values: dict) -> MachineReading:
    return MachineReading(
        machine_id=machine_id,
        source='opcua',
        timestamp=datetime.now(timezone.utc),
        spindle_speed=node_values.get('SpindleSpeed'),
        feed_rate=node_values.get('FeedRate'),
        program=node_values.get('ActiveProgram'),
    )

# from_focas(), from_lsv2(), from_ads() all return the same MachineReading.
# your dashboard, database, and alerts never need to know which protocol it came from.

Every collector in this post — FOCAS, LSV2, OPC UA, ADS, MTConnect — ends at the same place: a handful of numbers with a timestamp. Normalize at the edge, right where each protocol's quirks are already being handled, and everything downstream (dashboard, database, alerting, an OEE calculation) is written once against one shape instead of once per machine brand.

Best practices for a production CNC data collection platform

1. 1Design the unified data model first, protocols second. Decide what a MachineReading looks like before writing a single collector — it's the contract everything else is built against.
2. 2Prefer subscriptions over polling where the protocol offers it. OPC UA and MTConnect can push updates on change; FOCAS, ADS, and LSV2 require polling — poll politely, on an interval the control can sustain, not as fast as the loop will go.
3. 3Treat every collector as read-only until proven otherwise. Write access (tool offset corrections, program upload) is a separate, much higher-stakes feature — don't bundle it into a monitoring project by default.
4. 4Handle disconnects as the normal case, not the exception. Machines reboot, networks hiccup, cables get unplugged during a changeover. A collector that can't reconnect gracefully will page someone at 2 a.m. for the wrong reason.
5. 5Store the raw payload alongside the normalized reading. Cheap to keep, invaluable when a dashboard shows something impossible and you need to know whether the source data or your parsing was wrong.
6. 6Audit every license before it ships. GPL vs. LGPL vs. MIT, a free SDK vs. a paid machine option — the same trap that catches PyQt projects catches machine-data projects too, and it's cheaper to catch in code review than in a legal notice.
7. 7Isolate collector traffic on its own network segment. FOCAS, ADS, and OPC UA ports have no business being reachable from the general office network — a VLAN or a jump host between the shop floor and everything else is not optional.
8. 8Start with one machine family, prove the model, then scale out. The controller-by-controller table above is a map, not a checklist — build the FANUC collector, get it feeding a real dashboard, and let that shape what the second controller's collector needs to match.

Once the data's flowing, the interesting work starts — OEE that updates itself, tool-life alerts, a dashboard nobody has to walk the floor to check. If you're staring at a specific controller from this list and want a second opinion on the fastest path in, get in touch.