How to Collect Data from FANUC CNCs Without Writing Custom Scripts

If you run a shop with FANUC controls, you already know the data is in there — spindle speed, feed rate, cycle counts, alarms, run state. The hard part isn't that the data doesn't exist. It's getting it out reliably, from every machine, in a form your team can actually use.

Most teams start by writing a script. It works on one machine, in a demo, on a good day. Then it meets the floor. This article is about why that happens — and what a maintainable approach looks like instead.

First, the basics: what FOCAS2 actually is

FANUC machines expose their data through FOCAS2 — FANUC's official Open CNC API. It's the supported, documented way to read live values from a FANUC control over Ethernet: positions, speeds, modal states, part counts, diagnostic and alarm data.

That's the good news: you don't need to tap PLC I/O or scrape an HMI. There's a real API.

The catch is that FOCAS2 is a low-level C library, not a friendly data feed. You connect, you acquire a handle, you call specific functions for specific data, you interpret raw return values, and you manage the connection lifecycle yourself. Done once, for one machine, it's a weekend project. Done for a floor, every day, forever — it's a different story.

Why custom FANUC scripts break down on a real floor

Four things turn a working script into a maintenance burden:

1. Handles are a limited resource. A FANUC control allows only a small number of concurrent FOCAS2 connections. If your script doesn't acquire, reuse, and release handles carefully — and recover when one is lost — you'll eventually exhaust them and the machine stops answering. This is the single most common reason home-grown FANUC collectors silently die.
2. Every FANUC generation is a little different. A 0i, a 16i/18i/21i, and a 30i/31i/32i don't all expose the same data the same way. A script tuned to your newest machine often returns garbage — or nothing — on your oldest one. The fix is per-model handling, and that logic has to live somewhere and be maintained by someone.
3. Raw values aren't insights. FOCAS2 hands you machine-specific numbers. Turning "register X on this model" into a clean, consistently-named spindle_rpm or cycle_time — the same name on every machine, regardless of generation — is work. Skip it, and your dashboard ends up with twelve different names for the same thing.
4. The floor is hostile. Networks blip. Machines power off mid-cycle. Firmware gets updated. A collector that doesn't reconnect cleanly, buffer through an outage, and pick up where it left off will quietly lose data exactly when you need it most.

None of these are unsolvable. But solving all four, for every machine, and keeping them solved as the floor changes — that's not a script. That's a product nobody on your team signed up to own.

A more maintainable approach: a protocol-agnostic runtime

The alternative is to let purpose-built software own the protocol, so your team owns the configuration instead of the code.

That's what EdgeConnect does. It's a protocol-agnostic edge runtime that connects to FANUC controls over FOCAS2 — across every generation from 0i to 30i/31i/32i — manages the handle lifecycle and reconnection for you, and normalizes every reading into one canonical vocabulary at the edge. A spindle reading from a 2009 machine and a 2024 cell become the same canonical signal, so everything downstream stops caring which machine produced it.

And FANUC is just one of the controllers it speaks. The same runtime collects over MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, and Siemens S7 today — so a mixed-vendor floor lands in one consistent data model instead of six integration projects. (FANUC MT-LINKi REST integration is on our roadmap.)

You can read more about how that normalization works in our Connectivity & Edge capability overview.

What you do with the data once it flows

Clean, consistently-named machine signals are the foundation for the things people actually want:

• OEE computed against your definition of running, planned stop, and unplanned stop — not a vendor preset.
• Alarm and downtime visibility across the whole floor, in one place.
• Operational reporting that replaces the manual spreadsheet.

In the Elpis stack, EdgeConnect handles the collection and EREMOS V2 turns the canonical stream into OEE, alarms, and reports. The point is that the math is built on real, traceable signals — the number an audit asks about traces back to a named value from a specific machine.

What this is not

• It's not a rip-and-replace. This sits beside your existing SCADA, historian, and MES, feeding them clean signals. It doesn't take over control logic, operator HMIs, or alarm acknowledgment.
• It's not a claim that every protocol ships today. The supported set is explicit and grows by shipping collectors, not by marketing. FANUC, MTConnect, Brother, Modbus, OPC UA, and S7 are live now.
• It's not magic. Collecting data is the first step. Good OEE still depends on you defining what "running" means for your process — software can't decide that for you.

Where to start

If you have FANUC machines and you're tired of either flying blind or babysitting a fragile script, the practical next step is to scope your actual controller mix — which FANUC generations, plus whatever else is on the floor — and confirm what each one can expose.

Elpis IT Solutions builds an Industrial Intelligence Ecosystem — from shop-floor signal to enterprise decision. Operating across India and the Middle East.