Building a FANUC CNC Data Collection and OEE System Without Replacing Your Machines

Picture a machine shop with a dozen FANUC CNC turning centers and machining centers. At the end of each shift, the production supervisor walks around with a clipboard, writing down cycle counts from each machine's display. Someone else checks alarm logs to figure out why Machine 7 was down for two hours. By the time the data gets into a spreadsheet, it's already yesterday's news.

The machines themselves can tell you what's happening — FANUC CNC systems expose operational data through their communication interfaces. The challenge isn't the machines; it's getting that data out, making sense of it, and putting it somewhere people can actually use it.

This article walks through how to collect data from FANUC CNC machines, track production output by product, and calculate OEE (Overall Equipment Effectiveness) using an industrial smart gateway with local processing capabilities — all without replacing your existing equipment or building a custom software stack from scratch.

What You Can Actually Get from a FANUC CNC

Before designing any data collection system, you need to know what's available. FANUC CNC systems (0i, 30i, 31i, 32i series and others) can provide several categories of data through their communication interfaces:

Operational status:

• Run mode (AUTO, MDI, EDIT, JOG, HANDLE, REF)
• Execution state (running, stopped, held, alarm)
• Current program number and name
• Active alarm codes and messages

Production data:

• Cycle count or part count (depending on machine configuration)
• Cycle time
• Feed rate override
• Spindle load

Tool and coordinate data:

• Tool numbers and tool life values
• Work coordinate offsets
• Machine position

What you can't assume:

• Cycle count doesn't automatically equal good parts. A machine that ran 100 cycles might have produced 95 good parts and 5 scrap. The CNC doesn't know your quality process.
• Program name doesn't automatically map to a product. You need a lookup table.
• "Running" doesn't mean "producing good parts." A machine can run without cutting material.

The gateway reads what the machine makes available. Translating that into business metrics like "daily output by product" or "OEE" requires additional logic.

The Gateway as Data Bridge

An industrial smart gateway sits between your CNC machines and wherever you want the data to go — a local dashboard, a cloud platform, or both. For FANUC CNC data collection, the gateway handles:

1. Connecting to the CNC: Using FANUC's FOCAS protocol (or FOCAS2/Ethernet for newer systems), the gateway reads the variables you've configured.
2. Processing the data: Raw values from the CNC often need transformation. A cycle count might need to be reset at shift boundaries. A program name needs to be looked up in a product table.
3. Storing data locally: The gateway can run a local SQLite database, so you don't have to send everything to the cloud to get useful reports.
4. Serving dashboards: Built-in web interfaces can display real-time status, production summaries, and trends without requiring a separate application server.

For a typical FANUC CNC setup, you'd configure the gateway to read:

• Machine status variables (run/stop/alarm)
• Current program name
• Part count or cycle count (whichever the machine provides)
• Active alarms

The gateway polls these at whatever interval makes sense for your operation — every 5 seconds for real-time dashboards, every minute for production tracking, or on-change for status transitions.

From Cycle Counts to Production Records

Here's where most projects get stuck. The CNC gives you a cycle count, but your production system needs to know:

• What product was made?
• When did the shift start and end?
• Was this cycle a good part or scrap?

The gateway's local application framework can handle this logic without requiring a separate MES or database server.

Step 1: Build a product table.
In the gateway's local database, create a table that maps CNC program names to products. For example:

Program Name	Product ID	Product Name
O0012	P-2045	Shaft, Front
O0034	P-2046	Housing, Rear
O0078	P-2047	Bracket, Mount

This table is maintained by your production team. When a new part is introduced, they add a row.

Step 2: Capture production events.
The gateway reads the current program name and cycle count. When the cycle count increments, the gateway:

• Looks up the product from the program name
• Records a production event with timestamp, machine ID, product ID, and cycle count
• Stores this in the local SQLite database

Step 3: Handle shift boundaries and counter resets.
CNC cycle counters often reset at power cycle or when the operator clears them. Your logic needs to:

• Detect counter resets (current count < previous count)
• Define shift boundaries (e.g., 6 AM to 6 PM, or three 8-hour shifts)
• Aggregate cycles by shift, machine, and product

This logic runs in Lua scripts on the gateway. You're not writing a custom application server; you're configuring data processing rules.

Step 4: Display the results.
The gateway's web interface can show:

• Today's production by machine and product
• Shift summaries
• Trend charts of output over time

All of this runs locally on the gateway. You don't need a cloud subscription to see your production data.

Calculating OEE from CNC Data

OEE (Overall Equipment Effectiveness) is the product of three factors:

OEE = Availability × Performance × Quality

Each component requires different data:

Availability

Availability measures what percentage of planned production time the machine was actually running.

Availability = Run Time / Planned Production Time

You need:

• Planned production time: Shift duration minus planned breaks (e.g., 8 hours minus 30 minutes = 7.5 hours)
• Run time: Time the machine was in AUTO mode and not in alarm

The gateway tracks state transitions: when the machine goes from STOP to RUN, start counting. When it goes to ALARM or STOP, stop counting. Sum the run times for the shift.

What the gateway can't tell you automatically:

• Why the machine stopped. An alarm code tells you something went wrong, but not whether it was a tool break, material issue, or operator error. You need a separate reason-capture process (operator input, maintenance logs) to calculate downtime causes.
• Whether the machine was "planned down" for maintenance. You need to subtract planned maintenance from planned production time.

Performance

Performance measures how fast the machine ran compared to its ideal or designed speed.

Performance = (Ideal Cycle Time × Total Count) / Run Time

You need:

• Ideal cycle time: The theoretical time to produce one part at design speed. This comes from your process engineering, not the CNC.
• Total count: From the CNC's cycle counter.
• Run time: From availability calculation.

If the ideal cycle time is 60 seconds and the machine produced 300 parts in 7 hours (25,200 seconds) of run time:

Performance = (60 × 300) / 25200 = 18000 / 25200 = 0.714 or 71.4%

The machine was running, but not at full speed. Maybe the operator reduced feed rate, or there were minor stops not captured as alarms.

Quality

Quality measures what percentage of produced parts were good.

Quality = Good Parts / Total Parts

This is where CNC data alone falls short. The CNC doesn't know which parts were scrap. You need:

• Operator input at the machine (entering scrap count)
• Inspection system data
• Or a separate quality tracking process

If you can't get quality data automatically, you have two options:

1. Manual entry: Operators enter scrap count at the end of each shift via a simple form on the gateway's web interface.
2. Estimate from process data: If you have a stable process, you might estimate scrap rate from historical data, but this is not a substitute for actual measurement.

For a realistic OEE implementation, plan to capture quality data separately. The gateway can store and include it in the calculation, but it can't generate it from CNC data alone.

Putting It Together

The gateway's local application can:

• Track machine state and calculate availability
• Read cycle counts and calculate performance (if you have ideal cycle times)
• Store quality data (if you have a way to capture it)
• Calculate OEE and display trends

All of this runs on the gateway itself. You don't need a separate server or cloud platform to see your OEE numbers.

Implementation Checklist

Before you start connecting gateways to your FANUC CNCs, make sure you have:

For each machine:

• [ ] Exact CNC model and control series (0i-F, 30i-B, etc.)
• [ ] Communication interface available (Ethernet for FOCAS2/Ethernet, or serial for older FOCAS)
• [ ] FOCAS library access enabled on the CNC (this is a FANUC option, not always enabled by default)
• [ ] List of variables you can read (program name, cycle count, status, alarms)
• [ ] Understanding of what "cycle count" means on each machine (does it reset? does it include setup cycles?)

For your production process:

• [ ] Product-to-program mapping table
• [ ] Shift definitions and boundaries
• [ ] Ideal cycle times for each product (from process engineering)
• [ ] A plan for capturing quality data (manual entry, inspection system, etc.)
• [ ] Agreement on what "planned downtime" includes

For the gateway setup:

• [ ] Network connectivity between gateway and CNC (Ethernet or serial)
• [ ] IP addresses and communication parameters configured
• [ ] Lua scripts for data processing (product lookup, shift aggregation, OEE calculation)
• [ ] Local database schema for production records
• [ ] Dashboard layout for real-time status and production summaries

What This Doesn't Do

It's worth being clear about what this approach doesn't cover:

• It doesn't replace your MES or ERP. The gateway collects and processes data, but it's not a full manufacturing execution system. If you need work order tracking, material consumption, or detailed routing, you need a separate system.
• It doesn't automatically know why machines stopped. Alarm codes tell you something went wrong, but not the root cause. You still need operator or maintenance input for downtime analysis.
• It doesn't measure quality automatically. The CNC doesn't know if a part is scrap. You need a separate quality capture process.
• It doesn't guarantee your CNC exposes the data you need. Some FANUC systems have restricted variable access or require additional licenses. Check your specific machine's capabilities before designing your system.

Start with One Machine, One Metric

If you're new to CNC data collection, don't try to calculate OEE across your entire shop on day one. Start with:

1. Pick one FANUC CNC that's representative of your fleet.
2. Connect the gateway and read basic status (run/stop/alarm) and cycle count.
3. Display real-time status on a dashboard so people can see the machine's state without walking to it.
4. Track daily cycle count and compare it to manual counts to validate your data.
5. Add product mapping once you trust the data collection.
6. Calculate availability before attempting full OEE.

Each step gives you usable value. You don't need to build the whole system before it's useful.

The Payoff

Once data collection is working, the production supervisor doesn't need to walk the floor with a clipboard. They check a dashboard that shows:

• Which machines are running, stopped, or in alarm
• Today's production count by machine and product
• Shift-to-date output compared to target
• Availability trends over the past week

The data is already there in the CNC. The gateway just makes it accessible.

For a machine shop with FANUC CNCs, the path from "walking around with a clipboard" to "real-time production dashboard" doesn't require replacing machines or building custom software. It requires understanding what data is available, how to collect it, and how to turn raw counts into meaningful metrics.

The gateway handles the data collection and processing. Your team handles the process knowledge — what the numbers mean, why machines stop, and what to do about it.

For a practical application overview, see Woody's FANUC CNC data collection and OEE scenario, which outlines the gateway's role and the conditions to confirm before connecting your machines.

---

This article is based on real-world implementation patterns for FANUC CNC data collection using industrial smart gateways. Specific CNC models, variable access, and communication protocols should be verified against your actual equipment.