Collecting Fanuc CNC Data: FOCAS vs MTConnect

Fanuc controls a huge share of the CNC market, so “how do I get data off my Fanuc machines?” is one of the most common questions in industrial data. There are two mainstream answers — FOCAS and MTConnect — and they trade off depth against portability. This post compares them honestly and shows how a good middleware can use either.

FOCAS: deep, low-level, Windows-bound

FOCAS (FANUC Open CNC API Specifications) is Fanuc’s native library for talking to its controllers. You link against Fanuc’s fwlib30.dll and call C functions that read program numbers, tool data, spindle load, axis positions, alarms, and more directly from the control.

Strengths:

• Depth. Access to low-level controller data that higher-level protocols don’t expose.
• Direct. No intermediary; you’re talking to the Fanuc control’s own API.
• Real-time-ish. Tight polling of controller internals.

The catch:

• Windows-only. fwlib30.dll is a native Windows library. You can’t load it on Linux or ARM. Any FOCAS collector must run on Windows.
• Fanuc-specific. It only speaks to Fanuc controls — useless for a mixed fleet with Siemens, Haas, or Heidenhain.
• C API. Verbose; lots of boilerplate to read a single value.

MTConnect: standardized, cross-platform

MTConnect is an open, XML/HTTPS standard for machine monitoring. Many modern controls — Fanuc included — expose an MTConnect agent that streams a standardized data item model (spindle speed, feed, program, axis positions, controller mode).

Strengths:

• Cross-platform. Plain HTTP/XML over the network. Linux, ARM, a Raspberry Pi — anything that can do HTTP can read it.
• Standardized. A Haas MTConnect stream and a Fanuc MTConnect stream speak the same data-item vocabulary. One consumer works across vendors.
• Push/streaming. The agent streams samples and events; you don’t poll raw registers.

The catch:

• Shallower. Exposes the standardized subset, not every low-level controller internal FOCAS can reach.
• Requires an agent. The control needs an MTConnect agent running/enabled.

FOCAS vs MTConnect at a glance

The honest recommendation

• Use MTConnect when you have a mixed-vendor or cross-platform floor, you want one consumer for all machines, or you’re deploying on Linux/ARM edge devices. For most modern monitoring (OEE, uptime, anomaly detection), MTConnect gives you everything you need.
• Use FOCAS when you specifically need low-level Fanuc controller data that MTConnect doesn’t expose, and you have a Windows host available to run the collector.

How OpexFlow handles both

OpexFlow ships both a FOCAS adapter and an MTConnect adapter, and normalizes them to the same CanonicalMachineData shape — so downstream transforms and sinks don’t care which one produced the event.

The FOCAS adapter loads Fanuc’s fwlib30.dll directly. Because that’s a Windows-only native library, the adapter self-disables with a clear status on Linux/ARM rather than failing opaquely — you always know why it’s off. MTConnect, being HTTP-based, gives you cross-platform CNC on any OS.

That gives you a clean deployment pattern for a mixed floor:

• Fanuc machines needing deep data → FOCAS adapter on a Windows edge node.
• Everything else (and Fanuc machines where the standard subset is enough) → MTConnect, on Linux or ARM.

Either way, the data lands in the same normalized schema and fans out to your sinks — ClickHouse, Postgres/TimescaleDB, NATS, MQTT, or an HMAC-signed HTTP push. (See the adapter reference.)

Normalization is the real win

The painful part of CNC monitoring isn’t reading FOCAS or MTConnect — both are documented. It’s that FOCAS gives you Fanuc-shaped fields (SpindleRpm, AxesPosX) and MTConnect gives you standardized data items, and none of them match each other or your downstream schema. You end up writing vendor-mapping glue in every consumer.

OpexFlow collapses that: vendor fields map onto a canonical schema once, per source route, with either the native DSL or a sandboxed JS transform. The AI generator will write the mapping for you from a description like “map the Fanuc vendor fields in metadata to the canonical schema.” After that, every consumer sees the same spindle.speed, axes[].position, and metadata.tool.

The bottom line

FOCAS buys depth at the cost of a Windows-only, Fanuc-only collector. MTConnect buys portability and standardization at the cost of a shallower data set. You don’t have to pick one for the whole floor — pick per machine, and put a middleware above them that normalizes both to one shape. That’s how OpexFlow does CNC.

See how it works, read the docs, or request a license.

Related: OpexFlow as a Kepware alternative and building an ARM64 edge IoT gateway.