Modbus RTU ile Konuşurken 15 Dakikalık 'Sessizlik': Kablo Kopmadı, Baud Kopmuştu

Bir Modbus RTU ağı: bir PLC master, 8 slave (3 VFD, 4 RTU sensör kartı, 1 enerji sayacı). Sabah 08:00’de 8’in 8’i cevap veriyordu. 08:15’te 11. slave — yani enerji sayacı — cevap vermeyi durdurdu. Kablo sağlam, güç normal. Ama “cevap yok.”

Bu yazı o 15 dakikanın kısa notu.

Operatör “Kablo Kopmadı” Dedi. Haklıydı.

Operatör kabloyu kontrol etmişti: sağlam. Ben de “tamam, kablo sağlam” dedim. Ama “kablo sağlam” ile “timeout” arasında, sahada sık yapılan bir yanlış atama var:

Kablo sağlam → “kablo meselesi değil” → “o zaman ne?” → “kablo.”

Yani operatör “kablo sağlam” dediği anda, aklına başka bir şey gelmediği için “kablo”ya geri döndü. Oysa Modbus RTU’da, kablo sağlamken “cevap yok”un en sık sebebi kablo değil, baud ya da timeouttur.

1. Adım: Timeout’u 500ms’den 1500ms’e Çektim

PLC’de RTU master tarafındaki default timeout 500ms’ti. Aynen öyle: 500ms içinde cevap gelmezse “timeout” hatası verirdi. 8 slave’den 7’si 500ms içinde cevap veriyordu. 11. slave — enerji sayacı — veri paketi biraz uzun olduğu için 700ms’de cevap veriyordu. 500ms timeout, onu “yiyor”du, ama o günde bir kere de değil, her istekte yemişti.

Ama o gün 11. slave hiç cevap vermedi. Yani 700ms değil, hiç değil.

500ms timeout, “700ms cevabı” yese bile, “hiç cevap”ı da yutar. Yutma davranışı: 500ms bekle, cevap yoksa “timeout” ver. 700ms cevap gelse, o 200ms’lik gecikme “timeout” sayılmaz, “gecikme” sayılır. Ama “hiç cevap” gelse, 500ms doldu, “timeout.” İkisi aynı davranış — sadece “sebep” farklı.

Ben timeout’u 1500ms’e çektim. Sonra tekrar test ettim. 11. slave hâlâ “hiç” cevap vermedi. Yani timeout meselesi değildi.

2. Adım: Baud’ı Kontrol Ettim. 9600 Değil, 19200 Çıktı.

11. slave — enerji sayacı — RTU kartının baud ayarı 9600 olmalıydı. Master tarafında 9600’tü. Slave tarafında 19200’müş.

Baud mismatch, Modbus RTU’da “kablo sağlam ama cevap yok”un en klasik sebebidir. Kablo sağlam, ama iki uç farklı hızda konuşmaya çalışıyor. Master 9600’de “merhaba” diyor, slave 19200’de “merhaba”yı algılıyor — ama hız farklı olduğu için byte’lar kayıyor. Slave, masterin “merhaba”sını “gürültü” olarak algılıyor, cevap vermiyor.

Baud’ı slave tarafında 9600’e çevirdim. Cevap geldi. 15 dakikanın 14. dakikasında.

3. Adım: “Neden Değişmişti?” Sorusu

Bu asıl mesele. Baud neden 9600’den 19200’e değişmişti?

Cevap: iki hafta önce, başka bir mühendis, enerji sayacının “bağlantı hızını” 19200’e çekmişti — “hızlandırmak” için. Ama master tarafını 9600’de bırakmıştı. İki hafta boyunca, sayacın cevabı 19200’de gelmiş, master 9600’de beklemiş. 500ms timeout, “her istekte” 11. slave’yi “yutmuş” — ama o kadar sıklıkla yutmuştu ki, kimse “11. slave hiç cevap vermiyor” diyememişti. Çünkü 500ms timeout, “hızlı” bir hataydı; operatör “kablo sağlam” deyip geçmiş.

İki hafta önce “hızlandırma” yapan arkadaş, master tarafını da 19200’e çekseydi, hiçbir sorun olmazdı. Ya da slave tarafında baud’ı değiştirmeseydi. İkisi de basitti. Ama “bir uçta” hızlandırırsanız, diğer ucunu da aynı hıza çekmeniz gerekir. Modbus RTU, “asimetrik” hız kabul etmez.

Kural: Üç Katman, Tek Sıra

Bu 15 dakikadan sonra, Modbus RTU “sessizlik” durumunda benim kuralım üç adımlık hale geldi:

1. Kablo sağlam mı? — Fiziksel kontrol, multimeter. (5 dakika)
2. Timeout doğru mu? — Slave’in cevabı 500ms’den uzun alıyorsa, timeout’u 1500ms’e çek. (1 dakika)
3. Baud aynı mı? — İki ucun baud’ını aynı andan kontrol et. (1 dakika)

Toplam: 7 dakika. 15 dakikanın 7 dakikasında “kural”ı uygularsanız, kalan 8 dakikayı “sebep”i anlamaya harcarsınız.

“Timeout bir hata değil, bir sigortadır” cümlesini, bu yazının başlığına “sigorta” kelimesini koyarak başlattım. Ama asıl mesele: timeout’un “sigorta” olması için, “baud’un “sabit” olması gerekir. Baud kaysa, timeout “sigorta” değil, gürültü olur. Ve gürültü, 15 dakikalık sessizlik üretir.

---

Modbus’un “teknik” tarafını daha önce iki yazıda ele almıştık: Modbus Temelleri ve Haberleşme Protokolleri: Modbus. Bu yazı, o “teknik”in, sahadaki 15 dakikalık sessizlikle karşılaşan hali.

15 dakikalık sessizliğin yarısı, 7 dakikalık kuralın işidir. Diğer yarısı, “neden değişmişti?” sorusundur — slave cevap vermeyi bıraktığı günün iki hafta önceki bir “hızlandırma”sında gizliydi. Sahada en pahalı hatalar, çoğu zaman “başka birinin” imzasıyla gelir. Değişiklik tarihçesi tutun; yazılım tarafında program yorumları olarak bile olsa. İki hafta önce “kim” ne değiştirdiyse, o soru, 15 dakikalık sessizliğin 8 dakikasını kurtarır.