CNC Control Protocols: FOCAS, LSV2, DNC, Mazak & MTConnect

Three brands, three languages on a single factory floor. A FANUC CNC controller communicates via port 8193 using its proprietary API; a Heidenhain TNC answers on port 19000 with concise four-letter telegrams; and a Mazak delivers MTConnect output via a SMARTBOX gateway without exposing the CNC kernel. Across the same production line, three distinct data cultures coexist side by side.

The CNC control protocols guide was structured to place these distinct languages onto a single architectural map. Its purpose is not merely memorizing command sets; it demonstrates which operational problem belongs to which protocol layer, which pathways offer read-only versus write authorization, and where essential security boundaries must be drawn. This guide consolidates five major protocol families into a unified decision framework: FOCAS, LSV2, Heidenhain DNC, Mazak SMARTBOX, and MTConnect.

Guide at a Glance

Which problem are you solving?

Protocol selection begins not with brand loyalty, but with your specific operational data requirement. The following routing matrix connects four common industrial scenarios directly to the relevant technical dossier.

Five Protocols, One Map

Architectural Comparison

How to Read This Guide

Engineers and managers approach manufacturing data from distinct vantage points. If you are an executive or plant director evaluating plant architecture, focus first on the comparison matrix and the five-step deployment methodology. If you are an OT or automation engineer, examine the wire-level transport, memory layouts, and permission boundaries detailed in the dedicated FOCAS, LSV2, and DNC dossiers. If your responsibility lies in MES, analytics, or SCADA, start with the MTConnect dictionary and Mazak gateway sections. This guide does not crown a generic “winner”; it establishes the appropriate architectural layer for each problem domain.

Three Frequently Confused Concepts

• Protocol vs API vs Standard: FOCAS is an API library; LSV2 is a wire protocol; MTConnect is a semantic dictionary. Referencing all three under the broad term “protocol” obscures critical differences in abstraction.
• Port vs Connection Lifecycle: Port numbers such as 8193 or 19000 are merely socket endpoints. The session authentication, privilege levels, and licensing handshake operating behind that socket dictate true data flow. An open TCP port does not guarantee data availability.
• Read vs Write Boundaries: Certain interfaces accommodate bidirectional read and write operations, whereas MTConnect is deliberately read-only. Operational authorization influences system security far more than protocol syntax.

First Turn: It Is a Question of Layer, Not Protocol

These five technologies do not inhabit the same tier of the OSI stack. FOCAS and LSV2 function as direct transport and API layers; they interface intimately with controller registers. Heidenhain DNC functions as a software product and licensing layer; it wraps LSV2 mechanics within COM objects and desktop utilities. Mazak SMARTBOX operates as a hardware gateway layer; it isolates the machine network while emitting standardized telemetry. MTConnect resides at the semantic abstraction layer; it assigns uniform industrial meaning to raw variables regardless of the underlying transport.

Failing to recognize these operational layers results in misleading debates, such as framing choices as “MTConnect versus FOCAS.” The accurate question is: At what abstraction layer does your system require this data? If your application must inject tool offsets or manipulate PMC logic, FOCAS, LSV2, or DNC are mandatory. If your platform aggregates operational telemetry across dozens of machines, MTConnect is the optimal choice. If you must connect sealed Mazak CNCs without violating warranty boundaries, SMARTBOX provides the validated pathway.

Second Turn: The Read/Write Safety Boundary

Write capability represents the critical dividing line in manufacturing networks. FOCAS, LSV2, and DNC permit remote applications to alter CNC parameters, shift coordinate systems, overwrite G-code files, and toggle PLC memory coils. While essential for advanced automation cells, this capability introduces physical operational risk. An erroneous offset or corrupted register can cause catastrophic spindle crashes, damage tooling, or endanger operators. MTConnect intentionally eliminates this entire risk surface: it is architecturally read-only.^[1]

None of the guides in this series furnish instructions for executing unvalidated write routines. Instead, we establish governance and architectural safeguards: any client process possessing write authority must reside on a segmented subnet, enforce strict cryptographic authentication, and require human operational verification. It should never share a process boundary with passive telemetry collectors.

Third Turn: Licensing and Engineering Overhead

FOCAS, LSV2, and Heidenhain DNC operate within proprietary ecosystems; developer libraries, hardware dongles, or SIK software licenses must be sourced directly from the manufacturer. Conversely, MTConnect is open and royalty-free. However, “royalty-free” does not equate to zero implementation cost. Setting up adapter processes, aligning data tags, configuring network subnets, and managing schema versions demand substantial engineering labor. Over the life of a project, the total cost of ownership is dominated by tag normalization and dialect maintenance rather than initial license fees.

Technical documentation reflects the same trade-off. With proprietary systems, implementation relies on official vendor manuals and commercial technical support. With open standards, engineering teams leverage community repositories, reference C++ agents, and open-source model browsers. Regardless of which avenue you select, maintaining a rigorous version matrix is mandatory: CNC firmware versions, agent builds, and client collectors must remain tightly synchronized.

Where to Begin: A Five-Step Methodology

1. Audit Controller Fleet: Catalog machine makes, models, controller generations, and installed network cards. A generic “FANUC” designation is insufficient; a Series 0i-F differs fundamentally from a 30i-B.
2. Define Exact Data Requirements: Determine whether operations require read-only monitoring or bidirectional writing. Document specific fields: part counts, spindle overrides, PMC alarms, or coordinate positions.
3. Enforce Network Segmentation: Establish strict firewalls between the operational machine subnet, edge gateways, and enterprise IT networks. Isolate write-capable systems entirely.
4. Execute a Single-Machine Pilot: Validate end-to-end communication on a single machine tool before attempting plant-wide deployment. Observe physical behavior under real machining conditions.
5. Establish Formal Semantic Contracts: Document precise dataItemId mapping, engineering units, scaling factors, timestamp accuracy, and error handling policies. Undocumented configurations degrade within months.

Upcoming: Deep-Dive Technical Dossiers

This hub serves as the architectural overview. The accompanying technical dossiers examine the internal mechanics of each protocol family alongside verified implementation patterns.

Deployment Case Studies: Aggregating OEE across FANUC cells; secure G-code distribution to Heidenhain TNCs; unifying Mazak and FANUC equipment within a centralized dashboard; monitoring energy draw and cycle times via MTConnect; connecting legacy equipment through SENSOR BOX hardware. All examples incorporate real-world operational constraints and verified documentation.

Security and Operational Ethics

Conclusion: The Strategic Question

In manufacturing data integration, the defining question is never simply “which protocol?” It is “which architectural layer, what authorization level, and which security boundary?” FOCAS offers register depth, LSV2 delivers lean simplicity, Heidenhain DNC provides vendor-supported integrity, Mazak offers turnkey gateway isolation, and MTConnect provides a unified vocabulary. The optimum architecture depends entirely on your operational goals.

Where does manufacturing data currently reside on your shop floor: trapped inside CNC controllers, guarded behind physical gateways, or normalized into an open enterprise schema? And do your operational requirements necessitate passive telemetry collection, or are you prepared to govern the rigorous safety responsibilities of remote write execution?