Skip to content
SOLUTION · CNC MACHINING

One operational view across every Fanuc, Brother, and Mazak on your floor.

Native FOCAS2, MTConnect, and Brother HTTP — plus Modbus TCP for the PLCs in front of older CNCs. Canonical CNC vocabulary across vendors. No per-machine custom scripting. From the spindle to the dashboard, on one foundation.

Live integrations: FOCAS2 · MTConnect · Brother HTTP · Modbus TCP — and OPC UA Client and Siemens S7 for the rest of the floor. FANUC MT-LINKi REST on the roadmap.

THE CNC SHOP REALITY

Most shops don't have a CNC problem. They have an integration problem.

Modern CNC shops don't have a CNC problem. They have an integration problem. A single shop floor typically runs three to seven different CNC vendors — Fanuc lathes from one era, Brother machining centers from another, an Okuma multi-axis, a Mazak Integrex, maybe a Heidenhain or two. Each vendor ships its own diagnostic software. Each diagnostic tool produces its own dashboard. Each dashboard speaks its own dialect.

The result is predictable: production managers stitch OEE numbers together from spreadsheets. Maintenance learns about an alarm from the operator who happened to walk by. Tool changes get scheduled from clipboard memory. Cycle-time variance shows up in retrospect, after the shift is already lost. The data is on the floor — it just doesn't reach the people who need it.

Replacing the controllers isn't the answer. They cost too much, they're already validated for the parts they're running, and operators know them by feel. The data layer is what needs to modernize, not the iron. The shops that get there put one protocol-agnostic runtime in front of every controller, normalize every signal to one vocabulary, and let the existing systems keep doing their jobs.

"The data is on the floor — it just doesn't reach the people who need it."

HOW ELPIS SOLVES CNC INTEGRATION

How this differs from per-vendor CNC monitoring tools. Every CNC vendor ships a monitoring tool — and each one works, for the vendor it ships with. They each speak vendor-specific vocabulary, render their own dashboard, and report on their own schedule. Run a mixed-vendor floor and you run all of them at once, reconciling by hand. Elpis puts one protocol-agnostic runtime in front of every controller, normalizes every signal to canonical CNC vocabulary, and feeds one operational view for the whole floor. Same Fanuc, same Brother, same Mazak. Same production team. One OEE definition across them all. The per-vendor tools stay where they are; Elpis adds the cross-vendor layer.

EdgeConnect speaks every controller you own.One service running on a small box in your control cabinet polls each CNC over its native protocol — FOCAS2 for Fanuc, MTConnect for the open-standard machines, Brother HTTP for Brother's built-in web interface, and Modbus TCP for older CNCs fronted by a PLC. OPC UA Client and Siemens S7 cover the rest of the floor; FANUC MT-LINKi REST integration is on the roadmap. No per-machine custom scripting; no per-vendor middleware. This is the Connectivity & Edge capability applied to a CNC floor — see the underlying capability story → /capabilities/connectivity-edge.
Every tag normalizes to the same vocabulary.A spindle-RPM reading from a Fanuc 0i, a Brother S700Xd1, and an Okuma OSP all become the same canonical spindle_rpm in the pipeline. A Fanuc cycle-complete signal, a Brother cycle signal, and a Mazak cycle signal collapse the same way into a canonical cycle_time — the exact signal EREMOS V2 turns into OEE. The same applies to feed rate, parts count, tool number, axis positions, and alarm codes. One semantics, many vendors.

The next CNC vendor added to your floor should not require a new monitoring stack.

And that canonical stream is what finally gives you one operational picture.EdgeConnect publishes the normalized signals to MQTT (Mosquitto, HiveMQ, AWS IoT Core, or your existing broker), and EREMOS V2 turns them into the things a production manager lives in — OEE Segments computed from cycle-time and parts-count signals, every alarm tracked as a persistent record with incident workflows, downtime visible as it happens instead of in retrospect, and shift reports your team will actually read. This is the Operational Intelligence capability → /capabilities/operational-intelligence. Because every machine's signals arrive in the same canonical shape, the OEE math is the same across every machine, every shift, and every vendor — so the number holds up whether you're comparing two cells or defending it in a customer audit.
Nothing depends on the cloud.EdgeConnect runs offline. If your network or broker goes down, the platform buffers locally with per-route store-and-forward and replays in source order on reconnect — no lost cycles, no missing parts counts, no apologetic emails to the operations team. Three-way diagnostics (source / pipeline / sink) tell the OT team exactly which leg broke before the production team feels the symptom.
WHAT'S INCLUDED

From EdgeConnect (edge runtime, Windows service today)

  • FOCAS2 collector — Fanuc CNCs (0i, 16i, 18i, 21i, 30i, 31i, 32i). Axes, spindle, alarms, tool, production counters, programs.
  • MTConnect collector — the industry-standard CNC streaming protocol; covers most modern multi-vendor CNCs.
  • Brother HTTP collector — Brother S700Xd1 and similar via the built-in web-monitoring interface.
  • Modbus TCP collector — for older CNCs fronted by a PLC gateway.
  • Also today: OPC UA Client and Siemens S7 for the rest of the floor. On the roadmap: FANUC MT-LINKi REST. Full matrix → /edgeconnect.
  • Canonical CNC vocabularyrunning, spindle_rpm, feed_rate, parts_count, cycle_time, axis positions, tool number/offsets, alarm codes — the same names regardless of which CNC produced them.
  • Per-route store-and-forward buffering — never lose a cycle or a parts-count update because the broker was down.
  • Three-way diagnostics — source / pipeline / sink. Operators always know where the data flow broke.
  • Connectivity Studio — web admin to add machines, configure tag maps, run Test Connection probes before go-live.

EdgeConnect ships as a Windows service today; CNC shops typically run it on a small box in the control cabinet. A Linux runtime is near-term roadmap, arriving on the Edge Gateway appliance for shops that prefer a turnkey DIN-rail box. The appliance is an option, not a requirement.

From EREMOS V2 (intelligence layer, consuming the canonical stream)

  • OEE Segments — RUNNING, PLANNED_STOP, UNPLANNED_STOP, IDLE, SETUP. Computed from edge-collected signals; auditable.
  • Persistent alarm tracking — every CNC alarm becomes a tracked record with open/close state and incident grouping.
  • Tool-life ingestion — a dedicated path for tool-wear telemetry, so maintenance gets ahead of failures.
  • Shift reports — PDF and Excel, built from edge-collected signals, not operator memory.
  • Multi-tenant — one platform, many sites or business units; tenant data does not blend.
  • Dashboards split by device class — CNC, PLC, meter. Mixed fleets render cleanly.
COMMON QUESTIONS

What production managers ask before scoping a CNC floor.

Does this replace the software our CNCs already came with?

No. The vendor diagnostic tools stay where they are — Elpis sits beside them and adds the cross-vendor layer. EdgeConnect collects from each controller over its native protocol and normalizes every signal to one canonical CNC vocabulary, so your downstream view is consistent regardless of which machine produced the data. It also doesn't replace your SCADA, MES, or historian; those keep their jobs and consume canonical signals instead of vendor-specific ones.

Which CNC controllers do you collect from today?

Today: Fanuc over FOCAS2 (0i, 16i, 18i, 21i, 30i, 31i, 32i), the open-standard machines over MTConnect, Brother over Brother HTTP, and older CNCs fronted by a PLC over Modbus TCP. OPC UA Client and Siemens S7 cover the rest of the floor. FANUC MT-LINKi REST integration is on the roadmap. The exact controller mix is confirmed during the scoping call.

Can we defend the OEE numbers in a customer audit?

Yes — that's the point of computing OEE on canonical signals. EREMOS V2 derives OEE Segments from edge-collected cycle-time and parts-count signals, each timestamped at the edge and retained. The math is the same across every machine and every shift, so the number a customer audit asks about traces back to the actual signals, not a hand-reconciled spreadsheet. And the OEE definition stays yours — segment classification, shift schedule, and targets are configured to how your shop already defines OEE.

What happens when the network or the broker drops?

Per-route store-and-forward. Every signal queues at the source with its quality code preserved, and replays in source order when connectivity returns — no lost cycles, no missing parts counts. Three-way diagnostics surface immediately during the outage. Shops on an isolated network operate the same way; cloud connectivity is opt-in, not required.

How long until something is actually running?

A first machine is usually streaming real cycle-time and alarm data within the first few days — one CNC, one shift, one OEE definition — and a cell follows over the next few weeks. The full rollout cadence is below. We run the proof of value on your real protocols against your real signals, not on canned data.

What about the older Fanuc machines and the ones behind a PLC?

The older Fanuc controllers (16i / 18i and similar) are collected over FOCAS2 the same as the newer ones — the protocol coverage doesn't quietly drop your oldest iron. CNCs that don't expose a native data interface are collected over Modbus TCP through the PLC in front of them. Bring the controller list to the scoping call and we'll confirm the collection path per machine.

OUTCOMES YOU CAN HOLD US TO

What changes when this lands.

  • One OEE truth across mixed-vendor CNCs — no more reconciling numbers from three vendor dashboards by hand
  • Tool wear trended ahead of failure — tool-life telemetry flags wear before a tool fails mid-cycle
  • Cycle-time variance trended over shifts, days, and weeks — root-cause analysis becomes possible, not just retrospective
  • Alarm patterns visible across the floor — recurring faults surface as patterns, not isolated HMI incidents
  • New CNC vendors added without a new dashboard — the next Brother, Mazak, or Heidenhain plugs into the same platform
  • Cut the manual report-stitching — shift handover becomes a record built from edge-collected signals, not a phone call
  • Audit-ready production history — every reading timestamped at the edge and retained; OEE traces back to real signals
TYPICAL ENGAGEMENT

How CNC shops typically roll this out.

WEEK 1 — PROOF OF VALUE

One CNC, one shift, one OEE definition. EdgeConnect on a small Windows box in your control cabinet, polling that machine over FOCAS2 or Brother HTTP. Data to a Mosquitto broker we set up alongside, or your existing MQTT broker. EREMOS V2 displaying real cycle-time and alarm data, typically within the first few days.

WEEKS 2–4 — EXPANSION TO A CELL

Add the rest of the machines on one line or cell. Tag-map authoring done together with your team — your operators know the names that matter. Shift-report templates configured; OEE Segments aligned to your shift schedule.

WEEKS 5–8 — FLEET ROLLOUT

Remaining CNCs onboarded. Multi-site or multi-line aggregation in EREMOS V2 where applicable. Alerting routed to the channels your operations team already uses.

ONGOING

New CNC vendor added to the floor? The platform already handles it — FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, and Siemens S7 all ship today; FANUC MT-LINKi REST is on the roadmap. The next machine plugs into the same platform, not a new monitoring stack.

ARCHITECTURE FOR THIS SOLUTION

How the pieces fit together for a CNC floor.

CNC controllers Fanuc · Brother · Mazak NATIVE PROTOCOLS EdgeConnect canonical CNC vocabulary store-and-forward · 3-way diag CANONICAL EREMOS V2 OEE Segments · alarms shift reports · multi-tenant SCADA / MES / historian BESIDE, NOT REPLACING
For a CNC floor, EdgeConnect carries the floor-side; the Acquisition peer (mDAQ + mTracker + VAS + E-IDOS) is not required for this solution. See the full peer-architecture story → /architecture
TRUST POSTURE

Nothing depends on the cloud. EdgeConnect runs offline by default — license validates locally, no phone-home. If your network or broker drops, per-route store-and-forward buffers locally and replays in source order on reconnect. Shops on an isolated network install and run the platform the same way as shops with internet; cloud connectivity is opt-in, not required.

Per-gateway identity + hash-chained configuration audit. Each plant runs its own EdgeConnect runtime with a per-gateway UUID established at first start. Every change — a new machine added, a tag-map edit, a threshold change — is captured with actor identity and timestamp in a tamper-evident, replay-ready audit chain.

Read the full operational trust posture → /security

NEXT STEP

Bring us your CNC floor.

A controller mix, a target broker, an OEE definition — that's all we need to scope a proof of value. We run demos on real protocols against your real signals. No canned data, no slideware, no vague promises.