LSV2 Protokolü: Heidenhain’in Sessiz Veri Dili

Bir TNC oturumunu tel düzeyinde açtığınızda geriye şaşırtıcı derecede az şey kalır: dört baytlık bir uzunluk, dört harfli bir komut ve komutun taşıdığı veri. Ne JSON, ne XML, ne de tanıdık bir HTTP başlığı. Heidenhain kontrollerinin dünyasına girdiğinizde karşınıza çıkan bu sade yapı, LSV2 protokolüdür.

Sadeliği yanıltıcı. LSV2, Heidenhain TNC kontrolleriyle dosya transferi, program durumu, eksen verisi ve PLC belleği okuma gibi işleri yapan özel bir TCP protokolüdür. Kamuya açık bir şartnamesi yoktur; öğrenilmesi çoğunlukla paket gözlemi, hata kodu denemeleri ve TNCremo gibi üretici yazılımlarının davranışını izlemekle mümkün olmuştur. Bu yazı, o sessiz dili mümkün olduğu kadar açık anlatmayı deniyor.^[1][2]

Bir Bakışta LSV2

LSV2 nedir, ne değildir?

LSV2, Heidenhain kontrolleriyle ağ üzerinden konuşmanın en alt katmanlarından biridir. TNCremo gibi bir PC yazılımı, arka planda bu protokolü kullanarak dosya gönderir, program listesini okur veya makine durumunu sorgular. Protokolün adı sıkça “DNC” ile birlikte anılır; ama ikisi aynı şey değildir. DNC bir iş akışı ve ürün ailesidir; LSV2 ise o iş akışının altındaki taşıma dili.^[1][6]

LSV2’yi MTConnect ile karıştırmak da yanlıştır. MTConnect açık, XML/HTTP tabanlı ve salt-okunur bir sözlüktür; LSV2 ise Heidenhain’e özel, ikili telegramlarla çalışan ve yazma yetkisi olan bir protokoldür. Biri fabrika genelinde ortak dil kurar, diğeri tek bir kontrol ailesinin içine girer. İkisi aynı katmanda değildir.^[1]

Sekiz baytlık başlık, dört harfli komut

LSV2’nin çerçevesi öğrenildiğinde şaşırtıcı derecede küçüktür. Her mesaj sekiz baytlık bir başlıkla başlar: dört baytlık uzunluk (big-endian) ve dört karakterlik komut. Uzunluk alanı, komutun kendisini kapsamaz; yalnızca arkasından gelen yükün boyutunu söyler. Komutlar daima dört ASCII karakterdir: A_LG, R_RI, S_RI, T_OK, T_ER gibi.^[2]

İstek:  [len:u32 BE] [A_LG] [kullanıcı adı + 0x00]
Yanıt:  [len:u32 BE] [T_OK] [veri]

İstek:  [len:u32 BE] [R_RI] [alt kimlik:u16 BE]
Yanıt:  [len:u32 BE] [S_RI] [veri]

Oturum açmak için iki yol vardır. A_LG, kullanıcı adıyla giriş yapar; P_LG ise parola tabanlı oturum açar. TNCremoNT uyumlu çalışan simülatörlerde parola alanı PASSWORD veya REMOTE gibi test değerleriyle karşılanır; bunlar gerçek üretim kimlik bilgisi değildir. Başarılı giriş T_OK, hata T_ER ile döner.^[1][2]

Dosya transferinde protokol iki mod sunar: ASCII ve binary. Binary mod, dosya adından sonra gelen 0x01 baytıyla etkinleşir. Bu ayrıntı, metin programları ile ikili veri arasındaki farkı korumak için önemlidir; yanlış modda gönderilen bir dosya kontrol tarafında bozulabilir. Dosya yolu ve adı da kontrolün kendi dosya sistemi kurallarına uymalıdır; istemcinin yerel yolunu doğrudan göndermek çoğu zaman çalışmaz.^[2]

Hata yönetimi de kendi içinde katmanlıdır. pyLSV2’nin belgelediği aralıklara göre 0–19 arası protokol ve iletim hataları, 20–99 arası telegram hataları, 100–200 arası ise blok transfer hataları için ayrılmıştır. İstemci T_ER yanıtı aldığında yalnızca “bağlantı koptu” dememeli; hata kodunu ve yanıt gövdesini loglayarak hangi katmanda sorun olduğunu ayırmalıdır. Aksi hâlde aynı belirti, üç farklı kök nedenden gelebilir.^[3]

R_RI: kontrolün kısa hafızası

LSV2’de durum bilgisi tek bir dev blok hâlinde gelmez. İstemci, R_RI komutuna iki baytlık bir alt kimlik ekler; kontrol de S_RI yanıtıyla ilgili alanı döndürür. Saha uygulamalarında en çok kullanılan dört alt kimlik şunlardır:^[1][2]

Override alanında kritik bir ayrıntı var: ham değer 10000 = %100 demektir. Yani kontrol, yüzdeyi 1/100 ölçeğinde taşır. Bunu doğrudan “100” sanmak, panoda %1 ile %100’ü karıştırır. Uygulamalar arasında normalizasyon farkı da görülür: bazı sürücüler ham değeri 10000’e bölüp oran (1.0) üretir, bazıları 100’e bölüp yüzde (100.0) üretir. Veri sözleşmesi yazılmadan bu alan kullanılmamalıdır.^[2]

Seçili program yanıtı da benzer bir tuzak taşır. Program adı 4. bayttan sonra başlar; birden çok yol null karakteriyle ayrılır. İlk yol genellikle ana programdır, ama her kontrol ailesinde aynı sıra garanti değildir. İstemci, null ayırıcıyı ve boş yolları tolere etmelidir.^[2]

Oturum rolleri: kim neyi görebilir?

LSV2’de yetki yalnızca “bağlandı/bağlanmadı” değildir. Giriş sırasında seçilen rol, hangi komutların çalışacağını belirler. pyLSV2’nin belgelediği roller arasında INSPECT, FILE, DNC, MONITOR, DIAGNOSTICS, PLCDEBUG, SCOPE ve DATA bulunur. INSPECT ile eksen ve durum okunur; FILE ile dosya işlemleri yapılır; DNC ile program durumu sorgulanır; PLCDEBUG ise PLC’ye dokunabilir.^[3]

Bu roller, aynı protokolün farklı kapıları gibi düşünülmelidir. Bir istemciye yalnızca ihtiyacı olan rol verilmelidir. İzleme yapan bir toplayıcı için PLCDEBUG açmak, gereksiz bir yazma yüzeyi açar. Rol seçimi, protokolün teknik bir ayrıntısı değil, doğrudan güvenlik kararıdır.^[3]

İlk dönemeç: Basit çerçeve, kapalı doküman

LSV2’nin çerçevesi basit olduğu için “kolay protokol” sanılır. Oysa asıl zorluk, hangi alt kimliğin hangi veriyi döndürdüğünü, hangi rolün hangi komuta izin verdiğini ve sürümler arasında neyin değiştiğini bilmektir. Üretici bu bilgiyi kamuya açık bir şartname olarak yayımlamaz. pyLSV2 gibi projeler, TNCremo ile kontrol arasındaki trafiği gözlemleyerek ve hata kodlarını deneyerek bu boşluğu doldurur.^[1][2]

Bu tür bir kütüphaneyi üretimde kullanmadan önce iki şeyi ayırmak gerekir: protokolün nasıl çalıştığını öğrenmek ve onu üretim makinesinde çalıştırmak. pyLSV2 MIT lisanslıdır ve README’de üretim makinesinde kullanılmaması yönünde açık bir uyarı taşır. Bu uyarı, protokolün belgelenmemiş olmasından ve kontrol tarafındaki davranışın modelden modele değişebilmesinden kaynaklanır.^[1]

İkinci dönemeç: İki katmanlı yetki

LSV2’de yetki iki katmandır. Birinci katman giriş rolüdür; ikinci katman ise kontrolün lisanslı opsiyonlarıdır. Örneğin DNC rolüyle giriş yapmak tek başına yeterli olmayabilir; kontrol tarafında DNC Option 18 açık değilse yüksek seviyeli komutlar reddedilir. Bu durumda istemci bağlanır, hatta bazı temel yanıtları alır, ama makine durumu ve program bilgisi gibi alanlara ulaşamaz.^[6]

Opsiyon yoksa veri yok değildir; veri başka bir katmanda durur. Heidenhain tarafında yaygın çözüm, aynı bilgileri PLC sembolik adreslerinden okumaktır. Bu yol daha sınırlıdır ve kontrol tarafında hazırlık gerektirir; ama DNC opsiyonu olmayan eski makinelerde tek seçenek olabilir. “Bağlanmak” ile “veri almak” arasındaki fark, LSV2 makalesinin en pratik dersidir.^[6]

Üçüncü dönemeç: Tek protokol yanılsaması

LSV2’den söz ederken “tek protokol” demek kolaydır; sahada ise nesil farkları vardır. iTNC 530, TNC 640, TNC7, CNCpilot 640 ve MillPlus IT aynı ailenin farklı üyeleridir; komut desteği, oturum davranışı ve güvenli taşıma biçimi değişebilir. Yeni kontrollerde SSH tüneli (22) üzerinden LSV2 taşımak mümkündür; eski kontrollerde doğrudan 19000 portu kullanılır.^[1][5]

Bir de DNC ürün ailesinin kendi bağlantı profili var. Gözlemlediğimiz TNC640 DNC yapılandırmasında bağlantı profili 19003 portuna işaret ediyordu; ham LSV2 ise 19000’de çalışıyordu. Bu, “19003 LSV2’nin alternatif portudur” demek değildir; DNC COM katmanının kendi bağlantı yapılandırması olabilir. Makalede bu ayrım korunmalı, port numarası genellenmemelidir.

Aynı yanılsama dosya tarafında da geçerli. Bir kontrol dosya transferini kabul ederken diğeri oturum rolünü veya parola yöntemini farklı yorumlayabilir. Bu yüzden “LSV2 destekliyor” ifadesi, kontrol modeli ve yazılım sürümü belirtilmeden eksik kalır.

LSV2 mi, DNC COM mi, MTConnect mi?

Seçim, “hangisi daha modern” sorusuyla değil, “hangi yetkiye ihtiyacım var” sorusuyla yapılmalı. Dosya gönderecekseniz MTConnect yetersizdir; yalnızca durum izleyecekseniz LSV2’nin yazma yüzeyini açmanın anlamı yoktur.

Kurulumda yedi adım

1. Kontrol tarafında erişimi açın: Harici erişim izni ve gerekli kullanıcı/parola yapılandırması olmadan oturum kurulamaz.
2. Portu doğrulayın: Önce 19000/TCP’yi deneyin; yeni kontrolde SSH tüneli gerekiyorsa 22’yi kullanın.
3. Rolü en dar seviyede seçin: İzleme için INSPECT veya MONITOR; dosya için FILE; PLC yazma için ayrı yetki.
4. DNC opsiyonunu kontrol edin: Yüksek seviyeli komutlar reddediliyorsa DNC Option 18 durumunu ve PLC alternatifini değerlendirin.
5. Tek oturum politikası belirleyin: Aynı kontrolü birden çok istemcinin yoklaması, oturum çakışmalarına yol açabilir; toplayıcıyı tek noktada tutun.
6. Override birimini sözleşmeye yazın: Ham 10000 = %100; tüketici tarafında oran mı yüzde mi kullanılacağını netleştirin.
7. Hataları görünür kılın: T_ER ve hata kodlarını loglayın; sessiz yeniden denemeleri ve boş yanıtları ayırt edin.

Sonuç: Sadelik, gizliliği saklamaz

LSV2’nin çerçevesi sekiz bayta sığar; ama protokolün tamamı bu sekiz baytta değildir. Roller, lisans opsiyonları, nesil farkları ve hata kodları, asıl mühendislik yükünü taşır. Basit bir çerçeve görüp “protokolü çözdüm” demek, kontrolün kapısını değil, kapının menteşesini görmek gibidir.

Bir sonraki soru şu: TNC’nizde hangi rolü açtınız ve o rol gerçekten gerekli mi? Ve DNC opsiyonu yokken veriyi PLC’den okumak, sizin için geçici bir çözüm mü, yoksa kalıcı mimari mi?

Bu yazı, CNC kontrol protokolleri serisinin üçüncü parçası. Seri haberleşmenin fiziksel katmanı için RS-232 rehberimize, gömülü protokol fiziği için I2C/SPI/UART makalemize göz atabilirsiniz.