Ağ Gecikmesi 8ms, Scan Time 10ms: Hangisi Kazanır?
Mersin'de bir Profinet ağı, 8ms gecikme veriyordu. PLC scan time 10ms. 'Ağ scan'dan hızlı, sorun yok' dedik. 2 hafta sonra hat durdu: 8ms gecikme, 3. slave'de 12ms'ye çıkıyordu. Ortalama değil, maksimum gecikme önemli.
Pazartesi, 10:00. Mersin, bir otomotiv yan sanayi. Profinet ağı: 1 CPU 1515-2 PN, 7 ET200SP slave, 1 HMI. Scan time: 10ms.
Ağ gecikmesini ölçtüm: ortalama 8ms. “Ağ scan’dan hızlı, sorun yok” dedik. 2 hafta sorunsuz çalıştı.
Sonra hat durdu. 3. slave (bir motor sürücüsü) “communication timeout” verdi. Gecikme: 12ms. Scan time 10ms. 12 > 10, timeout.
Ortalama 8ms, Maksimum 12ms
Profinet, cyclic ve acyclic trafiği aynı hat üzerinde taşır. Cyclic: PLC ↔ slave, her scan’da. Acyclic: HMI, diagnostik, firmware update.
Ortalama 8ms, cyclic trafiğin gecikmesi. Ama acyclic trafik, cyclic’ı erteleyebilir. HMI, 10ms’de bir ekran yenileme yapıyor. Bu yenileme, 2ms’lik bir acyclic frame üretiyor. Frame, switch’te 1ms kuyrukta bekliyor. Cyclic frame, bu 1ms’yi bekliyor.
7 slave × 1ms kuyruk = 7ms ek gecikme. 8ms + 7ms = 15ms. Ama switch, QoS (Quality of Service) ile cyclic’ı önceliklendiriyor. 15ms değil, 12ms.
12ms > 10ms scan time. Timeout.
Neden 2 Hafta Dayandı?
HMI’nin ekran yenileme periyodu 10ms. PLC scan’ı da 10ms. İki periyot, başlangıçta faz kaymalı (HMI 0ms’de, PLC 5ms’de). Cyclic frame, acyclic frame’le çakışmıyor. Gecikme 8ms.
2 hafta sonra, termal genleşme, kablo titreşimi, switch’in iç zamanlayıcısı — faz kayması yavaş yavaş kaydı. HMI ve PLC, aynı 10ms penceresinde frame göndermeye başladı. Çakışma. Gecikme 12ms.
Bu, bir beat frequency sorunu. 10ms ve 10ms, aynı frekans. Faz kayması, yavaş yavaş 0’a yaklaşıyor. 0’da tam çakışma.
Çözüm: Scan Time’ı 12ms Yap
Scan time 10ms → 12ms. Maksimum gecikme 12ms. 12 = 12, sınırda. Biraz daha pay bırak: 15ms.
Ama 15ms scan time, proses kontrolü için yeterli mi? Motor sürücüsü, 15ms’de bir komut alıyor. Hız kontrolü, 15ms’de bir güncelleniyor. Bu uygulamada (bant konveyör, 0.5m/s) 15ms yeterli. 0.5m/s × 15ms = 0.75mm. Konveyör, 0.75mm’lik bir adım atıyor. Görünmez.
Ama yüksek hassasiyetli bir uygulamada (robotik, 10mm/s) 15ms, 0.15mm’lik bir adım. Bu da görünmez. Ama 100mm/s’de 1.5mm. Bu, bir tolerans hatası.
QoS Ayarı: Cyclic’a Öncelik Ver
Profinet switch’te QoS ayarı: cyclic trafiğe yüksek öncelik, acyclic’a düşük öncelik. Bu, acyclic frame’in cyclic’ı ertelemesini engeller.
Ama QoS, switch’in buffer kapasitesine bağlı. Switch, 16KB buffer’a sahipse ve 7 slave’den aynı anda frame geliyorsa, buffer dolar. QoS, buffer’ın içindeki sıralamayı değiştirir, ama buffer’ın dolmasını engellemez.
Çözüm: switch’in buffer’ını kontrol et. 7 slave × 150 byte (tipik Profinet frame) = 1050 byte. 16KB buffer, 15 frame alır. 7 slave, 7 frame. 8 frame pay var. Yeterli.
Ama HMI’nin 2ms’lik acyclic frame’i, 1 frame. 7 + 1 = 8 frame. 8 < 15. Yeterli.
Peki neden 12ms? Cevap: switch’in işleme gecikmesi. Frame, switch’e gelir, QoS sırasına girer, işlenir, çıkar. Bu işlem 1–2ms. 7 slave × 2ms = 14ms. Ama switch, frame’leri paralel işler, 14ms değil, 2ms.
2ms işleme + 8ms hat gecikmesi = 10ms. HMI çakışması +2ms = 12ms.
Bir Daha Olmasın
- Scan time: 15ms (pay bırak)
- HMI ekran yenileme: 20ms (PLC scan’ı ile aynı frekansta olmasın)
- Switch QoS: cyclic yüksek öncelik
- Switch buffer: 16KB (yeterli, ama 32KB daha güvenli)
Ayrıca Profinet diagnostik’te “jitter” izliyorum. Jitter, gecikmenin değişkenliği. Ortalama 8ms, jitter 4ms → maksimum 12ms. Jitter 2ms → maksimum 10ms. Jitter’ı 2ms’in altında tutmak, scan time’ı 10ms’de tutmamı sağlar.