What Is FOCAS? The Proprietary Gateway to FANUC CNCs

April 2026. On an isolated test subnet, a software daemon emulating a FANUC Series 31i CNC controller was listening on port 8193. The engineering experiment was straightforward: establish communication between FANUC’s official client library and an emulated controller without relying on proprietary vendor runtime DLLs. The server emitted an initialization response matching the wire-level binary specification. The client library received the packet, analyzed its structure, and abruptly severed the socket. The log output retained a single diagnostic code: -16, denoting EW_PROTOCOL.

This rejection conveys the primary foundational lesson of FOCAS: it is not merely a raw network wire protocol, but a tightly coupled client library suite distributed by the CNC builder. The library enforces proprietary client-side handshake validations; simply imitating packet headers on the wire is rarely sufficient. Later that afternoon, a second architectural approach was deployed: bypassing the vendor library entirely and conversing directly across raw TCP sockets. That path exposed the internal mechanics of the protocol.

FOCAS is the proprietary API suite utilized to access CNC and PMC memory registers across FANUC machine tool controllers. In engineering documentation, it is cataloged as FOCAS1 and FOCAS2. It connects via Ethernet or high-speed HSSB (High Speed Serial Bus), instantiates a session handle, and executes read and write transactions through that handle. It is not an open semantic standard like MTConnect; its runtime libraries and specifications are distributed exclusively under commercial builder terms.^[1][2][3]

FOCAS at a Glance

What FOCAS Is, and What It Is Not

Confusing FOCAS with MTConnect leads to costly architectural missteps on the shop floor. MTConnect is an open, read-only semantic dictionary designed for multi-brand telemetry; FOCAS is a vendor-specific, deep-register API providing bidirectional control for FANUC machinery. One normalizes diverse equipment into a common sentence; the other unlocks the internal organs of a FANUC controller. They are complementary rather than competing technologies. Furthermore, FANUC’s commercial MT-LINK i suite delivers monitoring over Ethernet and OPC UA; this represents an enterprise application product rather than an alternative wire protocol.^[1][2][6]

FOCAS is also not a single monolithic dynamic link library. FWLIB32.DLL operates as the core routing facade; depending on the target controller generation, it must dynamically load series-specific satellite libraries such as FWLIB30i.DLL, FWLIB0iD.DLL, FWLIB0i.DLL, FWLIB16W.DLL, or FWLIBNCG.DLL. Identical client source code running against different controller generations will demand distinct combinations of satellite DLLs. Deploying FOCAS without cataloging controller firmware and hardware generations guarantees runtime failure.^[2][3]

Licensing and distribution parameters impose strict boundaries. The runtime libraries are not open source; they are distributed under builder agreements. Because public, verified price lists do not exist, integration budgets must allocate dedicated lines for software licensing and technical enablement directly through official machine tool channels.^[2]

Two Physical Transports, One Connection Handle

FOCAS supports two physical communication media: Ethernet and HSSB. Ethernet operates across standard TCP/IP networking, with TCP port 8193 serving as the universal default across modern installations. HSSB utilizes high-speed fiber-optic bus interface cards installed directly into the CNC backplane. In FANUC’s official function matrices, specific capabilities are demarcated with O (Ethernet & HSSB), E (Ethernet only), H (HSSB only), or X (unsupported). Not all functions run across both transports.^[1][2]

The programmatic lifecycle relies on an explicit session handle. A client application invokes cnc_allclibhndl3, providing the IP address, port number, and timeout threshold in seconds; upon success, the library returns an unsigned short handle identifier. All subsequent telemetry calls pass this integer handle. When transactions conclude, the client frees resources via cnc_freelibhndl. Re-establishing handles for every polling cycle introduces catastrophic latency; conversely, reusing stale handles across dropped network sockets generates silent, unhandled exceptions.^[3]

Wire-Level Mechanics: Packet Frame Architecture

The underlying wire-level frame structure of FOCAS over TCP has been rigorously documented by independent open implementations (notably pyfanuc) and verified through industrial packet captures. This analysis reflects empirical reverse engineering and functional code rather than official vendor publications.^[4][5]

Every network frame begins with a fixed 10-byte binary header: a 4-byte synchronization magic sequence A0 A0 A0 A0, followed by big-endian unsigned 16-bit fields for protocol version, frame type, and payload length. Recognized frame types govern the complete lifecycle:

Binary Header (10 bytes):
[A0 A0 A0 A0] [version:u16] [ftype:u16] [payload_len:u16]

0x0101 / 0x0102  Session Open Request / Response
0x0201 / 0x0202  Session Close Request / Response
0x2101 / 0x2102  Data Transaction Request / Response
0x2103           Observed Rejection / Protocol NAK

Within a data transaction frame (0x2101), the payload encapsulates discrete 28-byte sub-packets. Each sub-packet comprises a 2-byte length descriptor (typically 0x001C), three 2-byte command identifiers (c1, c2, c3), and five 32-bit parameters. Successful responses echo the command codes along with incoming data buffers; error conditions return a truncated 14-byte payload. This sub-packet architecture allows integrators to bundle multiple queries—status, active program, feed rate, spindle RPM, and active alarms—into a single TCP transmission, significantly reducing network overhead.^[4]

This operational command suite reveals why FOCAS is regarded as the ultimate diagnostic window for FANUC controls: across a single network connection, it exposes everything from physical spindle load to low-level ladder logic coils, well beyond what open schemas surface.

First Turn: It Is a Library Ecosystem, Not a Standalone Protocol

The primary error when planning FOCAS integrations is regarding it as a plain socket protocol. At the developer layer, engineers interact with structured C function calls: cnc_statinfo, cnc_absolute, cnc_rdprgnum, cnc_exeprgname, cnc_rdopnlsgnl, cnc_rdmacro, and pmc_rdpmcrng. At the lower tier, these calls are marshaled through Windows DLLs into TCP streams tailored to specific CNC hardware generations.^[1][2]

A software implementation operating flawlessly on a Series 30i-B may fail on a Series 0i-F. FANUC’s function matrices detail which calls are supported across which controller family; entries marked X indicate complete lack of firmware support. When field engineers report that “FOCAS is down,” the issue is almost universally a missing satellite DLL or an invocation of an unsupported function call on that specific CNC model.^[1]

Second Turn: Write Authorization and Physical Safety

The most capable capability of FOCAS is simultaneously its greatest operational liability: remote write authorization. FOCAS can write machine parameters, coordinate work offsets, tool wear matrices, macro variables, and PLC memory bits. While invaluable for automated tool wear feedback, this represents an acute physical hazard. A corrupted tool length offset or miscalculated datum shift can plunge a cutting tool into a chuck fixture at maximum rapid traverse, wrecking expensive equipment and endangering operators.^[2]

This technical publication does not provide recipes for unvalidated write execution. We define strict architectural boundaries: client applications with write privileges must reside on an isolated VLAN, mandate multifactor authentication, log all transactions to audit trails, and incorporate pre-execution dry-run validations on digital simulators. FANUC’s cybersecurity advisories reinforce that remote write access must be treated with rigorous industrial scrutiny.^[7]

Third Turn: The DLL Barrier and Two Integration Paths

Returning to our opening software experiment: FANUC’s official client library rejected the emulated controller’s response with error -16 EW_PROTOCOL. Deep packet inspection indicates that the vendor library establishes dual sockets per session and utilizes proprietary handshake tokens during initialization, cross-checking responses against internal firmware signatures. Knowing the packet layout alone does not permit effortless emulation.

This establishes two distinct engineering pathways for FOCAS integration: utilizing the official vendor DLLs, or implementing a custom wire-level socket client (such as pyfanuc). Clean-room TCP implementations provide platform independence across Linux, ARM, and container environments, but operate entirely without vendor certification and may exhibit compatibility anomalies across older controller generations.^[4][5]

The practical integration conclusion is clear: choosing your client execution model is more consequential than configuring socket addresses. The vendor library represents the certified, fully supported path; custom TCP sockets minimize platform dependencies but transfer reverse-engineering maintenance risks entirely to your software team. Mixing both methodologies on the same production line invites dual maintenance overhead.

Behavioral divergences on simulation software like NCGuide further underscore this reality. In bench testing, specific calls like CMD_READ_OPNLSGNL (0x61) returned error E6, CMD_READ_MACRO (0x15) triggered 0x2103 rejections, and CMD_READ_PMC (0x02) provoked unexpected socket drops, while active T-codes were reliably extracted at byte offset 24 within CMD_READ_MODAL_AUX (0x22) payloads. Integrators must validate behavior against physical controller iron.

FOCAS vs. MTConnect: Strategic Trade-Offs

Optimal enterprise architectures frequently harmonize both technologies: deploying FOCAS at the machine edge for FANUC-specific diagnostics and controlled parameter updates, while surfacing normalized operational metrics plant-wide via an MTConnect adapter. Segregating control-tier writers from telemetry-tier readers remains the golden rule of industrial reliability.^[8]

Seven Rules for Production Implementation

1. Verify Hardware Ethernet Capabilities: FOCAS is not enabled by default on all machines; confirm the presence of Ethernet hardware options and supported CNC system software versions.
2. Restrict Network Ports via Firewalls: Restrict TCP port 8193 strictly to authorized data collection gateways; isolate machine subnets from office LANs.
3. Map the Satellite DLL Dependencies: Match controller series precisely against FWLIB32 satellite DLL requirements; guarantee 32-bit versus 64-bit runtime consistency.
4. Govern Connection Handle Lifecycles: Maintain persistent handles during polling routines; release handles cleanly upon exit; implement explicit reconnection logic when sockets fault.
5. Enforce Timeout and Back-Off Policies: Avoid saturating controller backplanes with high-frequency queries; incorporate exponential back-off upon receiving communication errors.
6. Physically Isolate Write-Capable Systems: Systems authorized to execute parameter updates must operate under dedicated credentials on segmented physical networks.
7. Log and Monitor Protocol Diagnostics: Capture all return codes (including EW_PROTOCOL and EW_SOCKET); expose silent retry loops to operational monitoring.

Conclusion: True Operational Control Means Knowing When Not to Write

The true value of FOCAS is not measured by the hundreds of functions exposed in its API manuals, but by the disciplined judgment governing their application. The exact same handle that reads an axis position can overwrite a workpiece offset. Establishing that boundary is not a software problem, but an institutional governance responsibility.

Does your data collection pipeline connecting to FANUC equipment operate purely in read-only telemetry mode? And if remote write authority is active, are your operational rollback plans and safety interlocks formally verified?

This article forms part of our CNC Control Protocols series. To understand open shop-floor telemetry, examine our MTConnect Guide; for hardware-level serial transmission, explore our RS-232 Dossier; for embedded bus physics, read our I2C, SPI & UART Analysis.