Was ist FOCAS? Die herstellereigene API für FANUC-CNCs

April 2026. In einem isolierten Testnetzwerk lauschte ein kleiner Serverprozess, der eine FANUC Series 31i Steuerung nachbildete, auf Port 8193. Das Ziel war klar definiert: Die originale FANUC-Clientbibliothek sollte ohne die herstellereigenen Windows-DLLs mit einer emulierten Steuerung kommunizieren. Der Server antwortete mit einem Initialisierungspaket, das der realen Telegrammstruktur exakt entsprach. Die Clientbibliothek analysierte die Antwort und verweigerte umgehend die Verbindung. Im Fehlerprotokoll blieb eine einzige Diagnosezeile zurück: -16, die Fehlerkonstante EW_PROTOCOL.

Diese Zurückweisung verdeutlicht die grundlegendste Lektion zu FOCAS: Es handelt sich nicht um ein bloßes Leitungsnetzwerkprotokoll, sondern um ein geschlossenes Software-Ökosystem aus herstellereigenen Bibliotheken. Die Bibliothek validiert serverseitige Antworten nach internen Kriterien; das bloße Nachahmen von TCP-Telegrammen reicht nicht aus. Am selben Nachmittag wurde ein alternativer Weg erprobt: Die Hersteller-DLLs wurden vollständig umgangen und direkt über reine TCP-Sockets kommuniziert. Dieser Ansatz legte die verborgene Struktur des Protokolls offen.

FOCAS bezeichnet die herstellereigene API-Familie von FANUC für den direkten Zugriff auf CNC- und PMC-Registerdaten. In der Fachliteratur wird sie unter den Bezeichnungen FOCAS1 und FOCAS2 geführt. Sie verbindet sich über Ethernet oder Hochgeschwindigkeits-HSSB-Lichtwellenleiter, initialisiert ein Sitzungshandle und wickelt alle Lese- und Schreibzugriffe über dieses Handle ab. Es ist kein offener Standard wie MTConnect; Spezifikationen und Bibliotheken unterliegen proprietären Herstellerbedingungen.^[1][2][3]

FOCAS auf einen Blick

Was FOCAS ist – und was nicht

FOCAS mit MTConnect gleichzusetzen, führt in der Werkshalle zu folgenschweren Architekturfehlern. MTConnect ist ein offenes, rein lesendes Wörterbuch für die herstellerübergreifende Telemetrie; FOCAS ist eine herstellerspezifische, tiefgreifende API mit Lese- und Schreibrechten für FANUC-Maschinen. MTConnect lässt heterogene Maschinen in einer einheitlichen Sprache sprechen; FOCAS öffnet das Innenleben einer konkreten FANUC-Steuerung. Beide Technologien konkurrieren nicht, sondern ergänzen sich auf verschiedenen Architekturschichten. Auch FANUCs kommerzielle Software MT-LINK i stellt Monitoring über Ethernet und OPC UA bereit; dabei handelt es sich um ein fertiges Anwendungsprodukt, nicht um ein alternatives Leitungsprotokoll.^[1][2][6]

FOCAS besteht zudem nicht aus einer einzelnen statischen DLL-Datei. Die Bibliothek FWLIB32.DLL bildet die zentrale Fassade; je nach Steuerungsgeneration müssen zusätzliche Satellitenbibliotheken wie FWLIB30i.DLL, FWLIB0iD.DLL, FWLIB0i.DLL, FWLIB16W.DLL oder FWLIBNCG.DLL im Suchpfad bereitliegen. Derselbe Client-Quellcode verlangt an einer 0i-F eine andere DLL-Zusammenstellung als an einer 30i-B. Die Aussage „FOCAS ist installiert“ ist ohne Angabe von Steuerungsmodell und Softwareversion unvollständig.^[2][3]

Auch die Lizenzgrenzen sind zu beachten. Die Bibliotheken sind nicht quelloffen; die Nutzung unterliegt Vereinbarungen mit dem Maschinenhersteller. Da keine verifizierten öffentlichen Preislisten vorliegen, gehört die Lizenzierung als eigener Budgetposten in jede Projektplanung.^[2]

Zwei Transportwege, ein zentrales Verbindungshandle

FOCAS unterstützt zwei physikalische Übertragungswege: Ethernet und HSSB. Ethernet arbeitet standardmäßig über TCP Port 8193. HSSB nutzt proprietäre Lichtwellenleiterkarten, die direkt in den CNC-Baugruppenträger eingesteckt werden. In den offiziellen Funktionsmatrizen von FANUC werden unterstützte Schnittstellen mit O (Ethernet & HSSB), E (nur Ethernet), H (nur HSSB) oder X (nicht unterstützt) gekennzeichnet. Nicht jeder Funktionsaufruf ist über beide Kanäle verfügbar.^[1][2]

Das Programmiermodell stützt sich auf ein Sitzungshandle. Eine Anwendung ruft cnc_allclibhndl3 mit IP-Adresse, Port und Timeout in Sekunden auf und erhält ein vorzeichenloses Short-Handle zurück. Alle nachfolgenden Funktionsaufrufe übergeben diese Kennung. Nach Abschluss der Abfragen wird die Verbindung über cnc_freelibhndl ordnungsgemäß geschlossen. Das ständige Neuöffnen von Handles für jede Einzelabfrage führt zu untragbaren Latenzen; das Weiterverwenden verwaister Handles nach Netzwerkunterbrechungen provoziert fatale Ausnahmen.^[3]

Telegrammaufbau auf Leitungsebene

Das binäre Leitungsprotokoll von FOCAS über TCP wurde durch unabhängige Open-Source-Implementierungen (insbesondere pyfanuc) und strukturierte Trace-Analysen fundiert offengelegt. Diese Erkenntnisse basieren auf Reverse-Engineering und lauffähigem Code, nicht auf offiziellen Datenblättern.^[4][5]

Jedes Datenpaket beginnt mit einem 10-Byte-Kopf: Vier Synchronisationsbytes A0 A0 A0 A0, gefolgt von Versionsnummer, Rahmentyp und Nutzdatenlänge in Big-Endian-Darstellung. Die wichtigsten Rahmentypen steuern den Kommunikationszyklus:

Binärer Header (10 Bytes):
[A0 A0 A0 A0] [version:u16] [ftype:u16] [payload_len:u16]

0x0101 / 0x0102  Sitzungsstart Anfrage / Antwort
0x0201 / 0x0202  Sitzungsende Anfrage / Antwort
0x2101 / 0x2102  Datentransaktion Anfrage / Antwort
0x2103           Protokollabweisung / NAK

In Datentransaktionspaketen (0x2101) sind 28-Byte-Subpakete eingebettet. Jedes Subpaket umfasst eine Längenangabe (typischerweise 0x001C), drei 2-Byte-Befehlscodes (c1, c2, c3) und fünf 32-Bit-Parameter. Erfolgreiche Antworten spiegeln die Befehlskennungen zusammen mit den Ergebnisdaten; Fehlerfälle antworten mit einem verkürzten 14-Byte-Paket. Dieser Aufbau gestattet es, mehrere Registerabfragen (Status, NC-Programm, Vorschub, Spindeldrehzahl, Alarme) in einem einzigen TCP-Paket zu bündeln, was den Netzwerk-Overhead drastisch reduziert.^[4]

Die Befehlsübersicht belegt, warum FOCAS als tiefste Diagnoseschnittstelle für FANUC gilt: Über ein einziges Socket-Handle werden Werte von physikalischen Spindellasten bis hin zu internen SPS-Merkern transparent ausgelesen.

Erster Wendepunkt: Bibliotheksverbund statt reines Protokoll

Der häufigste Planungsfehler besteht darin, FOCAS als schlichtes Netzwerkprotokoll zu betrachten. Auf Entwicklungsebene arbeitet man mit strukturierten C-Funktionen: cnc_statinfo, cnc_absolute, cnc_rdprgnum, cnc_exeprgname, cnc_rdopnlsgnl, cnc_rdmacro und pmc_rdpmcrng. Auf Betriebssystemebene werden diese Aufrufe über Windows-DLLs in TCP-Ströme umgesetzt, die exakt zur Hardwaregeneration der CNC passen müssen.^[1][2]

Code, der an einer Series 30i-B fehlerfrei läuft, kann an einer Series 0i-F unvermittelt scheitern. Die Funktionsmatrizen von FANUC weisen aus, welche Befehle von welcher Serie unterstützt werden; ein X bedeutet fehlende Unterstützung. Wenn Anwender melden, dass „FOCAS nicht funktioniert“, liegt die Ursache fast immer in einer falschen DLL-Kombination oder einem nicht implementierten Funktionsaufruf auf der jeweiligen Steuerung.^[1]

Zweiter Wendepunkt: Schreibrechte und physische Betriebssicherheit

Die mächtigste Eigenschaft von FOCAS birgt zugleich das größte Gefahrenpotenzial: das Schreiben von Daten. Über FOCAS können Maschinenparameter, Werkzeugkorrekturen, Nullpunktverschiebungen, Makrovariablen und SPS-Merker verändert werden. Dies ist für automatisierte Fertigungszellen unverzichtbar, eröffnet jedoch ein direktes Schadensrisiko. Ein falsch formatierter Korrekturwert kann das Werkzeug im Eilgang in die Spannvorrichtung rammen, Spindeln zerstören und Bediener verletzen.^[2]

Dieser Fachartikel vermittelt keine Anleitungen für ungesicherte Schreibzugriffe. Stattdessen fordern wir strenge organisatorische und netzwerktechnische Hürden: Schreibberechtigte Systeme müssen in einem separaten VLAN betrieben werden, kryptografisch gesichert sein und manuelle Freigaben verlangen. FANUCs eigene Sicherheitshinweise belegen, wie sorgfältig dieser Angriffsvektor überwacht werden muss.^[7]

Dritter Wendepunkt: Die DLL-Barriere und zwei Integrationswege

Kommen wir auf das anfängliche Experiment zurück: Die offizielle FANUC-Bibliothek verweigerte die Kommunikation mit der emulierten Steuerung und meldete -16 EW_PROTOCOL. Detaillierte Analysen zeigen, dass die Herstellerbibliothek zwei Sockets pro Verbindung aufbaut und beim Initialisieren proprietäre Handshake-Token austauscht. Das bloße Wissen um die Telegrammstruktur erlaubt somit keinen trivialen Nachbau.

Daraus ergeben sich zwei grundlegende Integrationspfade: Die Verwendung der offiziellen Hersteller-DLLs oder der Einsatz eigenständiger Socket-Clients (wie pyfanuc). Direkte TCP-Implementierungen ermöglichen Plattformunabhängigkeit unter Linux, ARM und Docker, arbeiten jedoch ohne Herstellerzertifizierung und können bei älteren Steuerungsgenerationen unerwartete Abweichungen zeigen.^[4][5]

Für die Praxis bedeutet dies: Die Wahl des Client-Modells ist entscheidender als die IP-Konfiguration. Die Herstellerbibliothek bietet die vollumfänglich unterstützte, stabile Basis; eigene TCP-Treiber minimieren Abhängigkeiten, übertragen das Risiko von Protokollinkompatibilitäten jedoch vollständig auf das interne Softwareteam. Beide Ansätze in einer Fertigungslinie zu vermischen, verdoppelt den Wartungsaufwand.

Auch auf Simulatoren wie NCGuide zeigen sich Abweichungen. In Prüfstandstests quittierte CMD_READ_OPNLSGNL (0x61) mit E6, CMD_READ_MACRO (0x15) mit Abweisung 0x2103 und CMD_READ_PMC (0x02) mit Socket-Abbrüchen, während T-Codes zuverlässig bei Byte-Offset 24 in CMD_READ_MODAL_AUX (0x22) ausgelesen wurden. Laborergebnisse müssen daher stets an realer Maschinenhardware nachgewiesen werden.

FOCAS oder MTConnect: Strategischer Systemvergleich

Moderne Industriearchitekturen kombinieren beide Ansätze: FOCAS wird auf Edge-Ebene für detaillierte FANUC-Diagnosen und autorisierte Sollwertvorgaben genutzt, während ein MTConnect-Adapter normierte Kennzahlen werksweit bereitstellt. Steuernde Schreibprozesse strikt von passiven Telemetrieprozessen zu entkoppeln, bleibt das oberste Sicherheitsgebot.^[8]

Sieben Regeln für die Produktionspraxis

1. Ethernet-Option verifizieren: FOCAS ist nicht ab Werk auf jeder Steuerung freigeschaltet; prüfen Sie die Hardwareoptionen und den Softwarestand der CNC.
2. Portzugriff per Firewall beschränken: TCP-Port 8193 ausschließlich für autorisierte Erfassungsserver freigeben; Maschinennetze vom Büronetzwerk isolieren.
3. DLL-Abhängigkeiten exakt zuordnen: Die jeweilige CNC-Serie exakt mit den benötigten FWLIB32-Satelliten-DLLs abgleichen; 32-Bit- versus 64-Bit-Kompatibilität sichern.
4. Handle-Lebenszyklus kontrollieren: Handles über Abfragezyklen hinweg offenhalten; bei Beendigung sauber freigeben; Wiederverbindungslogik bei Socket-Fehlern implementieren.
5. Timeouts und Abfrageraten drosseln: Die Steuerung nicht mit hochfrequenten Anfragen überlasten; bei Übertragungsfehlern exponentielles Back-off einsetzen.
6. Schreibberechtigte Systeme isolieren: Systeme mit Schreibzugriff müssen über separate Benutzerkonten und getrennte Netzwerksegmente geführt werden.
7. Diagnosecodes überwachen: Alle Fehlercodes der Bibliothek (einschließlich EW_PROTOCOL) lückenlos protokollieren und auswerten.

Fazit: Beherrschung zeigt sich im bewussten Verzicht auf Schreibzugriffe

Der Nutzen von FOCAS bemisst sich nicht nach der Vielzahl dokumentierter Bibliotheksfunktionen, sondern nach dem Urteilsvermögen, welche Funktion unter welchen Sicherheitsvorgaben genutzt wird. Dasselbe Handle, das eine Achsposition liest, kann auch einen Werkstücknullpunkt überschreiben. Diese Grenze zu ziehen, ist keine Softwarefrage, sondern eine organisatorische Führungsaufgabe.

Arbeitet Ihre Datenerfassung an FANUC-Maschinen als reiner Leseclient? Und sind im Falle von Schreibbefehlen Ihre Rollback-Prozesse und Sicherheitsverriegelungen lückenlos dokumentiert?

Dieser Fachbeitrag ist Teil unserer Reihe zu CNC-Steuerungsprotokollen. Einzelheiten zu offenen Standards finden Sie in unserem MTConnect-Leitfaden; Grundlagen zur seriellen Hardwareübertragung in unserem RS-232-Dossier; Signalphysik erläutert unsere Analyse zu I2C, SPI und UART.