LSV2-Protokoll: Heidenhains Telegrammsprache für TNC

Reduziert man eine TNC-Verbindung auf die reine Netzwerkebene, bleibt verblüffend wenig übrig: ein vier Byte langes Längenfeld, ein vierstelliges ASCII-Kommando und die eigentliche Nutzlast. Kein JSON-Ballast, kein XML-Schema, kein HTTP-Header. Betritt man die digitale Kommunikationswelt der Heidenhain-Steuerungen, begegnet einem diese minimalistische, zweckmäßige Struktur: das LSV2-Protokoll.

Seine Schlichtheit täuscht. LSV2 ist ein proprietäres, TCP-basiertes Telegrammprotokoll für Heidenhain-TNC-Steuerungen, mit dem Dateiübertragungen abgewickelt, Maschinenzustände abgefragt, Achspositionen ausgelesen und PLC-Register geprüft werden. Eine öffentlich zugängliche Spezifikation von Heidenhain existiert nicht. Das Verständnis dieses Protokolls stützt sich maßgeblich auf Paketanalysen, Fehlercode-Tests und die Beobachtung offizieller Werkzeuge wie TNCremo. Dieser Beitrag bereitet das Wissen darüber präzise und ingenieurmäßig auf.^[1][2]

LSV2 auf einen Blick

Abgrenzung: Was LSV2 leistet und was nicht

LSV2 fungiert als grundlegende Leitungsschicht für den Netzwerkdialog mit Heidenhain-Steuerungen. Software wie TNCremo verwendet dieses Protokoll im Hintergrund für Dateiübertragungen, Verzeichnisabfragen oder Zustandsprüfungen. Häufig wird LSV2 synonym mit „DNC“ genannt; beides ist jedoch sauber zu trennen: DNC beschreibt ein Gesamtkonzept und Heidenhains Integrationssoftware; LSV2 ist das darunterliegende binäre Transportprotokoll.^[1][6]

Ebenso verfehlt wäre die Gleichsetzung mit MTConnect. MTConnect ist ein offener, rein lesender XML/JSON-Standard über HTTP-REST zur herstellerübergreifenden Betriebsdatenerfassung. LSV2 hingegen ist ein proprietäres, zustandsbehaftetes Binärprotokoll ausschließlich für Heidenhain-Steuerungen, das Lese-, Schreib- und Dateitransferfunktionen bereitstellt. MTConnect vereinheitlicht den Blick über den gesamten Maschinenpark; LSV2 greift direkt in das Herz der Heidenhain-Steuerung.^[1]

Acht-Byte-Kopf und Vier-Zeichen-Befehle

Der Telegrammaufbau von LSV2 ist bemerkenswert straff. Jede Nachricht beginnt mit einem Acht-Byte-Header: eine 32-Bit-Ganzzahl (Big-Endian) für die Länge der Nutzlast, gefolgt von vier ASCII-Zeichen für den Befehl. Wichtig: Die Längenangabe umfasst ausschließlich die nachfolgenden Nutzdaten, nicht den Befehlskopf selbst. Die Befehle bestehen stets aus vier Zeichen, etwa A_LG, R_RI, S_RI, T_OK oder T_ER.^[2]

Anfrage:  [len:u32 BE] [A_LG] [Benutzername + 0x00]
Antwort:  [len:u32 BE] [T_OK] [optionale Daten]

Anfrage:  [len:u32 BE] [R_RI] [Sub-ID:u16 BE]
Antwort:  [len:u32 BE] [S_RI] [Status-Nutzlast]

Für die Authentifizierung stehen zwei Wege zur Verfügung: A_LG übergibt einen Benutzernamen ohne Kennwort; P_LG erfordert ein Passwort. In Prüfumgebungen mit TNCremoNT-Emulation trifft man häufig auf Test-Tokens wie PASSWORD oder REMOTE; für produktive Netze sind dies keine sicheren Zugangsdaten. Eine erfolgreiche Anmeldung bestätigt die Steuerung mit T_OK, Fehler werden mit T_ER und Fehlercode quittiert.^[1][2]

Bei der Dateiübertragung unterscheidet LSV2 zwischen ASCII- und Binärmodus. Der Binärmodus wird durch ein an den Dateinamen angehängtes Byte 0x01 aktiviert. Dieser Unterschied ist entscheidend: Werden Binärdateien im ASCII-Modus gesendet, droht Datenkorruption auf der Steuerung. Dateipfade müssen den internen TNC-Pfadvorgaben (wie TNC:\nc_prog\) entsprechen; lokale Pfade des PCs führen unweigerlich zu Abbrüchen.^[2]

Die Fehlerbehandlung gliedert sich in definierte Bereiche: Laut pyLSV2-Dokumentation belegen die Codes 0–19 Verbindungs- und Ãœbertragungsfehler, 20–99 Telegramm- und Syntaxfehler sowie 100–200 Blocktransferfehler. Empfängt ein Client ein T_ER, genügt ein simples „Verbindung verloren“ nicht; der Code muss ausgewertet werden, um zwischen Socket-Abbrüchen, Dateisperren und fehlenden Berechtigungen zu unterscheiden.^[3]

Der R_RI-Befehl: Das Kurzzeitgedächtnis der Steuerung

Maschinendaten werden in LSV2 nicht in einem riesigen Gesamtdatenblock geliefert. Der Client sendet den Befehl R_RI (Read Running Info) zusammen mit einer 16-Bit-Sub-ID (Big-Endian); die Steuerung antwortet mit einem S_RI-Telegramm. Vier Sub-IDs stehen in der Praxis im Mittelpunkt:^[1][2]

Für die Sub-ID 25 gilt eine wesentliche Skalierungsregel: Der Rohwert 10000 entspricht 100%. Die Steuerung codiert Potentiometerstellungen in Hundertstel-Prozenten. Wer den Wert ungeprüft als Prozentzahl interpretiert, verfälscht Visualisierungen um den Faktor 100. Treiber lösen dies unterschiedlich: Manche normalisieren auf 1.0, andere rechnen in 100.0% um. Diese Konvention muss vor der Weiterverarbeitung vertraglich fixiert sein.^[2]

Bei Sub-ID 24 beginnt der Programmpfad nach Byte 4; mehrere geladene Programme sind durch Null-Bytes getrennt. Zwar steht das Hauptprogramm meist an erster Stelle, doch kann die Reihenfolge je nach Softwarestand variieren. Parser müssen Null-Bytes sauber auswerten und leere Pfade abfangen.^[2]

Sitzungsrollen: Wer darf was?

Berechtigungen erschöpfen sich in LSV2 nicht in einem binären Verbindungsstatus. Beim Login deklariert der Client eine Rolle, die den Befehlsumfang festlegt. Laut pyLSV2 existieren u. a. die Rollen INSPECT, FILE, DNC, MONITOR, DIAGNOSTICS, PLCDEBUG, SCOPE und DATA. Mit INSPECT lassen sich Achsen und Statuswerte lesen, FILE ermöglicht Dateioperationen, DNC fragt Programmdaten ab, während PLCDEBUG Schreib- und Lesezugriff auf PLC-Merker bietet.^[3]

Diese Rollen sind als Sicherheitsgrenzen zu verstehen. Ein reiner Erfassungsclient sollte ausschließlich INSPECT oder MONITOR anfordern. Die Vergabe von PLCDEBUG an automatisierte Dienste vergrößert die Angriffsfläche unbedacht. Die Rollenwahl ist kein reines Implementierungsdetail, sondern eine grundlegende Sicherheitsentscheidung.^[3]

Erste Wendung: Schlichte Struktur, geschlossene Spezifikation

Der minimalistische Acht-Byte-Kopf verleitet dazu, LSV2 für ein anspruchsloses Protokoll zu halten. Die wahre Hürde liegt jedoch in der fehlenden Dokumentation: Welche Sub-ID liefert welches Register, welche Softwareversion unterstützt welchen Telegrammtyp, und was bedeuten herstellerspezifische Fehlercodes? Da Heidenhain keine offene Referenz veröffentlicht, mussten Projekte wie pyLSV2 dieses Wissen mühsam rekonstruieren.^[1][2]

Vor dem produktiven Einsatz gilt es zu differenzieren: Protokollverständnis ist nicht gleichbedeutend mit Produktionsfreigabe. pyLSV2 unterliegt der MIT-Lizenz und enthält im README einen deutlichen Warnhinweis bezüglich des Einsatzes an Fertigungsmaschinen. Denn Firmware-Updates können interne Zeitabläufe verändern oder bisher tolerierte Befehlsfolgen abweisen.^[1]

Zweite Wendung: Zweistufige Berechtigungsprüfung

Die Rechtevergabe erfolgt in zwei getrennten Stufen. Die erste Stufe bildet die beim Login gewählte Rolle; die zweite Stufe hängt von den auf der Steuerung freigeschalteten Softwareoptionen ab. Für höherwertige Statusabfragen ist die DNC-Option 18 via SIK (System Identification Key) zwingend erforderlich. Fehlt diese Option, akzeptiert die Steuerung zwar den Login, weist aber Statusanfragen mit Zugriffsfehlern zurück.^[6]

Ohne Option 18 müssen Betreiber jedoch nicht gänzlich auf Daten verzichten: Grundlegende Maschinenzustände lassen sich alternativ über symbolische PLC-Merker oder Speicherwörter erfassen. Zwar erfordert dies genaue Kenntnisse der herstellerspezifischen PLC-Belegung, bietet aber eine funktionierende Lösung für Altmaschinen ohne kostspieliges Software-Upgrade. Den Unterschied zwischen Netzwerkverbindung und Ausleseberechtigung zu kennen, gehört zu den wichtigsten Erkenntnissen der Heidenhain-Integration.^[6]

Dritte Wendung: Steuerungsgenerationen und Portvielfalt

LSV2 als einheitliches Protokoll zu bezeichnen, blendet entscheidende Generationsunterschiede aus. Zwischen iTNC 530, TNC 640, TNC7, CNCpilot 640 und MillPlus IT variieren Befehlssätze, Timeouts und Transportwege erheblich. Moderne Einheiten leiten LSV2-Traffic zunehmend über verschlüsselte SSH-Tunnel (Port 22), während ältere Systeme unverschlüsselt auf Port 19000 antworten.^[1][5]

Hinzu kommen softwareabhängige Portkonfigurationen. Bei TNC640-DNC-Installationen wurden Verbindungsprofile auf Port 19003 beobachtet, während das reine LSV2 auf 19000 lauschte. Port 19003 gehört zur Heidenhain-DNC-COM-Schicht und ist kein allgemeingültiger Alternativport. Portnummern dürfen daher nicht unbedacht verallgemeinert werden.

Auch beim Dateitransfer reagieren Steuerungen unterschiedlich. Während ein Modell Dateien problemlos streamt, fordert ein anderes gesonderte Authentifizierungsmethoden. Ein „LSV2-fähig“ ohne Angabe von Steuerungsmodell und Softwarestand greift daher technisch zu kurz.

Architekturvergleich: LSV2 vs. DNC COM vs. MTConnect

Die Technologieauswahl muss sich am betrieblichen Bedarf orientieren: Sollen NC-Dateien automatisiert übertragen werden, scheidet MTConnect aus. Geht es dagegen rein um passive Kennzahlen, birgt das Freischalten der schreibfähigen LSV2-Schnittstelle unnötige Risiken.

Sieben Praxisregeln für die Werkshalle

1. Fernzugriff an der Steuerung aktivieren: Ohne Freigabe für externe Kommunikation und korrekte Zugangsdaten schlägt jeder Login fehl.
2. Port und Verschlüsselung prüfen: Zunächst Port 19000 testen; bei neueren TNC640/TNC7-Steuerungen SSH-Tunnelung auf Port 22 vorsehen.
3. Prinzip der geringsten Rechte anwenden: Monitoring auf INSPECT oder MONITOR beschränken; Dateizugriff über FILE isolieren; PLCDEBUG meiden.
4. Lizenzstatus von Option 18 klären: DNC-Option via SIK prüfen; falls nicht vorhanden, Ausleselogik auf PLC-Merker aufsetzen.
5. Mehrfachverbindungen vermeiden: Parallele Zugriffe mehrerer Erfassungssysteme können die Verbindung destabilisieren; Datenabfragen an einem zentralen Edge-Knoten bündeln.
6. Override-Skalierung dokumentieren: Den Rohwert (10000 = 100%) in der Schnittstellenspezifikation eindeutig definieren, um Darstellungsfehler zu vermeiden.
7. Telegrammfehler detailliert protokollieren: Alle T_ER-Antworten mit Zahlencode erfassen, um Leitungsfehler von Zugriffssperren zu unterscheiden.

Fazit: Einfachheit bedeutet nicht Beliebigkeit

Das Grundgerüst von LSV2 passt in acht Byte; die Komplexität entfaltet sich in den Sitzungsrollen, Lizenzhürden und Versionsspezifika. Aus einem kurzen Header auf ein anspruchsloses Protokoll zu schließen, heißt das Torscharnier zu betrachten, ohne das dahinterliegende Gebäude zu kennen.

Welche Rolle nutzt Ihre Datenerfassung an der TNC-Steuerung? Und ist das Auslesen über PLC-Merker bei Maschinen ohne DNC-Option bei Ihnen eine dokumentierte Lösung oder ein Provisorium?

Dieser Beitrag ist Teil unserer Serie zu CNC-Steuerungsprotokollen. Grundlagen zur seriellen Datenübertragung finden Sie im RS-232-Dossier; Signalphysik erläutert unsere Analyse zu I2C, SPI und UART.