TCP sunucu modu, seri port sunucusunun bir ağ portunu dinlemesini ve bir bilgisayarın veya programın bağlantıyı etkin olarak başlatmasını beklemesini sağlar; bağlantı kurulduktan sonra her iki uç da seri baytları iletir. Bu mod, sayaç protokollerini otomatik olarak anlayan bir mod değildir ve seri cihazı doğrudan bir web sunucusuna da dönüştürmez. Aşağıda önce verinin cihazdan nasıl geçtiğini açıklıyor, ardından tutarlı bir yapılandırma örneği ve sorun giderme sırası sunuyoruz.
Sunucu ve istemci, bağlantıyı kimin başlattığını belirtir
Sunucu belirli bir adres ve portta bekler, istemci ise bağlantı isteğini başlatır. Bağlantı kurulduktan sonra veriler genellikle her iki yönde de iletilebilir; dolayısıyla “sunucu” yalnızca veri alabileceği, “istemci” de yalnızca veri gönderebileceği anlamına gelmez. Ağ portu, bir programın iletişim giriş noktası olarak seçtiği bir numaradır; makinenin arkasında ağ kablosunun takıldığı fiziksel bir soket değildir. Bilgisayarın sunucunun erişilebilir IP adresini ve dinleme portunu bilmesi, seri port sunucusunun da bağlantıyı kabul etmesi gerekir. Bağlantı yoksa seri cihazın gönderdiği verilerin nasıl arabelleğe alınacağı veya atılacağı modele ve yapılandırmaya bağlıdır; her zaman saklandığını varsayamazsınız. Önce rolleri anlayıp ardından çalışma modunu ayarlamak, iki cihazın da beklemesini veya ikisinin de yanlış hedeflere bağlantı başlatmasını önleyebilir.
Bir bayt gerçekte hangi aşamalardan geçer?
Örnek olarak bir bilgisayarın bir sayacı sorgulamasını ele alalım. Yazılım, protokol isteğini TCP katmanına iletir. Ağ arayüzü bunu aldıktan sonra sunucu, baytları ağ verisinden çıkarır ve UART seri denetleyicisine iletir. UART, baytları baud hızı, veri bitleri, eşlik biti ve durdurma bitlerine göre sürekli bir elektrik sinyaline dönüştürür; ardından ilgili RS232 veya RS485 devresi bu sinyali sayaca gönderir. Sayacın yanıtı ters yönde geri döner. Baud hızı, seri sembollerin zamanlamasını tanımlar; ağ hızı ne kadar yüksek olursa olsun, düşük hızlı bir sayacı kendiliğinden hızlandıramaz. Şeffaf iletim cihazları genellikle adresleri, işlev kodlarını veya ölçülen değerleri yorumlamaz; yorumlama işini uygulama yapar. Bir RS485 arayüzüne sahip olmak, yerleşik Modbus protokol dönüşümüne sahip olmak anlamına gelmez; bu iki yetenek ayrı ayrı kontrol edilmelidir.
Tek bir veri alma işlemi neden tek bir mesaj almak anlamına gelmez?
TCP, sıralı bir bayt akışı sağlar ve uygulamanın her gönderiminin sınırlarını korumaz. Bir program altı bayt gönderirse alıcı program bir okumada iki bayt, sonraki okumada dört bayt okuyabilir veya bunları başka birleşimler halinde bölebilir; aynı bağlantı üzerinden normal iletimde bayt sırasının yine de doğru olması gerekir. Bu, tek tek tam zarflardan çok sürekli bir su akışına benzer; ancak su akışı benzetmesi yeniden iletim ve tıkanıklık mekanizmalarını açıklayamaz. Uygulama, kendi protokolünün uzunluk, ayırıcı veya doğrulama kurallarına göre arabelleğe alma ve çerçeveleme yapmalı; bir okumayı bir istek veya yanıt olarak kabul etmemelidir. Cihazın seri veri paketleme süresi, verinin ne zaman gönderileceğini etkiler ancak TCP için kalıcı mesaj sınırları oluşturamaz.
Önce ağı yapılandırın, ardından aynı port örneğini kullanın
Sunucu adresinin 192.168.0.148, bilgisayar adresinin 192.168.0.166 olduğunu, karşılıklı iletişime izin veren aynı örnek alt ağda bulunduklarını ve dinleme portunun her yerde 4096 olarak kullanıldığını varsayalım. Örnek adresler ve portlar saha planına göre değiştirilmelidir; mevcut bir cihazın adresini doğrudan kullanamazsınız. Alt ağ maskesini ve ağ geçidini yapılandırırken alt ağlar arası erişimin gerekli olup olmadığını doğrulayın; aynı alt ağda bile VLAN'lar veya güvenlik duvarları cihazları birbirinden yalıtabilir. Sunucu 4096 olarak ayarlandıktan sonra istemci de 4096 hedefine bağlanmalıdır; bir adımda 4096, başka bir adımda 40080 yazamazsınız. Yapılandırmayı kaydedin ve yeniden başlatıldıktan sonra korunup korunmadığını kontrol edin. Menü adları ürün yazılımına bağlıdır; bu makale tüm modellerin aynı web arayüzüne sahip olduğunu varsaymaz.
Seri iletişim parametreleri ve elektriksel kablolama aynı derecede önemlidir
Örnekte 9600 baud, sekiz veri biti, eşlik yok ve bir durdurma biti kullanılabilir; ancak sayaç başka bir kombinasyon gerektiriyorsa sayaç kılavuzuna uyulmalıdır. Uyumsuz bayt biçimleri bozuk karakterlere, doğrulama hatalarına veya yanıt alınamamasına yol açar. RS232 genellikle gönderme, alma ve referans toprağı kullanırken RS485 diferansiyel hatlar kullanır; bu ikisi yalnızca bir adaptör kullanılarak doğrudan birbirine bağlanamaz. RS485 terminal adlandırması üreticiler arasında farklılık gösterebilir; bu nedenle A ve B harflerinden tahmin yürütmek yerine tanımlar kontrol edilmelidir. Güç kaynağı, yalıtım ve topraklama gereksinimlerini doğrulayın; saha veri yolu söz konusu olduğunda bakım koşulları altında çalışın. Yazılımın “bağlantı başarılı” göstermesi yalnızca TCP kanalının kurulduğunu kanıtlar; seri arayüz geriliminin, parametrelerin ve sayaç protokolünün doğru olduğunu kanıtlamaz.
Güvenli ve sonuçları açıklanabilir bir geri döngü testi yapın
Önce bağımsız bir test ortamında, düzgün çalıştığı bilinen bir seri cihaz veya seri hata ayıklama terminali kullanın, sunucuya bağlanın ve tutarlı parametreler kullanın. İstemci bilinen bir bayt dizisi gönderir, seri uç ise içeriği ve sıralamayı kontrol eder; ardından seri uç başka bir bayt dizisi gönderir ve istemci yanıtı kontrol eder. Onaltılık gösterim kullanılıyorsa “0” ve “1” metin karakterlerinin değil, bayt değerlerinin gönderildiğini doğrulayın. Gerçek bir sayaca bağlanmadan önce, bir eyleyiciye bilinmeyen komutlar göndermekten kaçınmak için sayacın kılavuzundaki salt okunur bir sorguyla doğrulama yapın. RS232 geri döngü ve RS485 test yöntemleri farklıdır; veri yolu terminallerini rastgele kısa devre etmeyin. Geri döngü testi, ağ ve seri taraflarını birbirinden ayırarak test etmeyi sağlayabilir ancak gerçek protokol ve yük kabul testlerinin yerini alamaz.
Eski yazılımın COM portu bir TCP sunucusuna nasıl bağlanabilir?
Özgün 2301 metni, eski programların seri arayüzü kullanmaya devam edebilmesi için sanal COM kullanılmasını öneriyordu. Bu fikir yararlıdır ancak tüm yazılımlar için 100% uyumluluğu olarak anlaşılmamalıdır. Sanal COM, bir bilgisayar sürücüsü tarafından yerel port olarak oluşturulur ve ardından seri port sunucusunun IP adresine ve hizmetin dinleme portuna eşlenir; program COM portunu açtığında sürücü ilgili ağ bağlantısını yönetir. Soketleri doğrudan kullanabilen programlar, protokole göre sunucuya bağlanabilir ve ek bir sanal COM katmanına ihtiyaç duymaz. Her iki yöntemde de portun başka bir işlem tarafından kullanılıp kullanılmadığı, parametreler, kontrol hatları, bağlantı kesintisinden sonra toparlanma ve yanıt süresi kontrol edilmelidir; yalnızca bir COM numarası göründüğü için başarı ilan edilemez.
Başka bir yöntem, sayacın bir bilgisayardaki gerçek bir seri porta bağlı kalması ve bu bilgisayarın diğer bilgisayarların erişimi için bir seri port paylaşım hizmeti çalıştırmasıdır. Bu, fiziksel seri portu uzak bir konuma taşımaz: paylaşımı sağlayan bilgisayar açık kalmalı, hizmet çalışıyor olmalı ve izinler doğru olmalıdır. Özel bir seri port sunucusu bu bilgisayara bağımlılığı azaltır ancak onun da güç, ürün yazılımı ve ağ koşulları vardır. Ağ, sistemin kurulabileceği alanı genişletir ancak bu, seri kablo uzunluğunun sınırsız olduğu veya tüm kontrol zamanlamalarının aynen korunabileceği anlamına gelmez. Birden fazla istemcinin paylaşım yapıp yapamayacağı ve erişim hakemliğinin nasıl çalıştığı yine modele ve uygulamaya göre doğrulanmalıdır.
Birden fazla istemci, zaman aşımları ve yeniden bağlantılar için açık kurallar gerekir
Bazı modeller birden fazla TCP istemcisine izin verir; seri yanıtların tüm istemcilere yayınlanıp yayınlanmadığı, yazma işlemlerinin kısıtlanıp kısıtlanmadığı ve erişim hakemliğinin nasıl çalıştığı kontrol edilmelidir. Birden fazla bilgisayarın aynı RS485 sayacını aynı anda kontrol etmesi, isteklerin karışmasına veya yanıtların yanlış oturuma iletilmesine neden olabilir. Bağlantı sayısını kontrol yeteneği olarak görmek yerine erişimi tek bir ana uygulamanın koordine etmesi en iyisidir. Ağ bağlantısı kesildikten sonra istemcinin genellikle kesintiyi algılaması, yeniden bağlanması ve uygulama durumunu geri yüklemesi gerekir; daha önce gönderilmiş bir kontrol komutunun yürütülüp yürütülmediği yalnızca bağlantının geri gelmesine bakılarak belirlenemez. Zaman aşımlarını ve yeniden denemeleri tasarlarken özellikle idempotent olmayan komutları tekrar tekrar yürütmekten kaçının; idempotentlik, tekrar yürütmenin sonucu ilave olarak değiştirmemesi özelliğidir.
Çalışmadığında hangi katman kontrol edilmelidir?
İstemci bağlanamıyorsa önce adresi, portu, dinleme modunu, erişim politikasını ve başka bir bağlantının portu meşgul edip etmediğini kontrol edin; bağlantı başarılı ancak seri veri yoksa kablolamayı, biçimi, sayaç adresini ve protokol isteğini kontrol edin. Veriler görülebiliyor ancak ayrıştırılamıyorsa bayt değerlerine, paketlerin arabelleğe alınmasına ve sağlama toplamlarına bakın; hemen baud hızını değiştirip şansınızı denemeyin. Üretim ekipmanının dinleme portunu doğrudan genel ağa açmayın; sistem tasarımına göre erişim kontrolü ve güvenli kanallar kullanın; TCP kendi başına şifreleme anlamına gelmez. Kabul testleri çift yönlü iletimi, bağlantı kesildikten sonra yeniden bağlanmayı, uzun süreli çalışmayı ve gerçek iş süreçlerini kapsar. Bağlantıyı, bayt aktarımını ve protokolün anlaşılmasını birbirinden ayırmak, yeni başlayanların her adımın gerçekte neyi doğruladığını açıkça anlamasını sağlar.
Çalışma prensibini doğrulama kaynakları:Resmî kaynak 1;Resmî kaynak 2. Bu makaledeki genel mekanizmalar ve örnekler, ilgili modelin kılavuzunun yerini almaz.
Çince teknik makaleden çevrilmiştir. Kaynağın ilk yayın tarihi: 2022-11-29. Kaynağın son güncellenme tarihi: 2026-10-13T19:15:07+08:00. Çince kaynağı okuyun
