PLC Döngüsü 4 ms'ye Çıktı, Kimse Fark Etmedi: Ta Ki Bir Kapak 2 ms Geç Kapanana Kadar
Adana'da bir tesiste S7-1500'ün döngü süresi, yeni bir blok eklendikten sonra 1.2 ms'den 4 ms'e çıktı. Hiçbir alarm vermedi, hat durmadı. Ama bir kapak, 2 ms geç kapanınca bir ürün çarpıştı. Döngü süresinin 'alarm' vermeden nasıl büyüdüğünü, 'en kötü döngü' ile 'ortalama döngü' farkını ve 4 ms'nin neden görünmez kaldığını kendi saha vakamla anlatıyorum.

Adana’da bir tesis. S7-1500, hat üzerindeki kapakları, konveyör hızını ve bir robotun senkronunu yönetiyordu. Döngü süresi, kurulumdan beri 1.2 ms’di. Stabil. Kimse bakmıyordu, çünkü “çalışıyordu”.
Bir gün, bir mühendis, programa yeni bir blok ekledi: bir “enerji optimizasyonu” bloğu. Konveyörün hızını, anlık yüküne göre ince ayarlayan, 200 satırlık, içi döngülü bir blok. Ekledi, test etti, “çalışıyor” dedi, çıktı.
O gün hiçbir şey olmadı. Hiçbir alarm vermedi. Hat durmadı. Operatör bir şey demedi.
Ama döngü süresi, 1.2 ms’den 4 ms’e çıkmıştı.
Ve bu, üç hafta sonra, bir kapağın 2 ms geç kapanmasıyla patladı.
4 ms Neden Alarm Vermedi?
S7-1500’ün döngü süresi, değişkendir. Her döngü, aynı sürede bitmez. I/O takası, program akışı, aritmetik yük — hepsi döngüden döngüye değişir. CPU, bu değişkenliği izler ama alarm vermez.
Neden alarm vermez? Çünkü “döngü süresi uzadı” bir arıza değil, bir performans meselesidir. CPU, “ben hâlâ çalışıyorum, döngümü tamamlıyorum” der. “Ama döngüm 1.2 ms’den 4 ms’e çıktı” demez. Bu bilgi, TIA Portal’daki “Cyclic time” ekranında durur. Ama kimse o ekrana bakmaz. Çünkü alarm yok.
4 ms, “hat durduracak” bir süre değildi. Hat, 4 ms’de de çalışıyordu. Konveyör dönüyordu, kapaklar kapanıyordu, robot gidiyordu. Ama 2 ms yavaş gidiyordu. Ve bu 2 ms, görünmezdi.
‘Ortalama Döngü’ ile ‘En Kötü Döngü’
Burada kritik bir ayrım var:
- Ortalama döngü süresi: Tüm döngülerin ortalaması. 4 ms.
- En kötü döngü süresi (worst-case): En yavaş döngü. Bizim vakamızda 6 ms.
“Enerji optimizasyonu” bloğu, her döngüde aynı süreyi almıyordu. Konveyörün yükü değiştiğinde, bloğun iç döngüsü daha çok tur atıyordu. Yük düşükken 3 ms, yük yüksekken 6 ms. Ortalama 4 ms, en kötü 6 ms.
Ve o 2 ms’lik gecikme, en kötü döngüde oldu. Yani, 6 ms’lik bir döngüde, kapak komutu, 1.2 ms’lik “eski” döngüye göre 4.8 ms geç gönderildi. Ama kapak mekanizması, 1.2 ms’lik döngüye göre kalibre edilmişti. 4.8 ms’lik gecikme, kapağın “2 ms geç” kapanması demekti. (Mekanik tarafta, 4.8 ms’lik elektrik gecikmesi, 2 ms’lik mekanik gecikmeye denk geliyordu — redüktör oranı, kollar, sürtünme.)
Kapak 2 ms Geç Kapanınca Ne Oldu?
Kapak, konveyör üzerindeki bir ürünü “bastırmak” için kapanıyordu. 2 ms geç kapanınca, ürün, kapağın “altına” girmişti. Kapak, ürünü bastırmadı, ezdi. Ürün, çarpıştı. Hat, manuel müdahaleyle durdu.
Operatör, “kapak arızalı” dedi. Kapak mekanizmasını kontrol ettik. Sağlamdı. Sinyali kontrol ettik. Sağlamdı. PLC’yi kontrol ettik. “Çalışıyor” diyordu.
Sonra, TIA Portal’daki “Cyclic time” ekranına baktık. 4 ms ortalama, 6 ms en kötü. Üç hafta önce 1.2 ms’di.
‘Görünmez’ Büyüme: Döngü Süresi Nasıl 3 Katına Çıktı?
“Enerji optimizasyonu” bloğu, 200 satırdı. İçinde, konveyörün anlık akımını okuyan, bir döngü içinde 50 kez hesap yapan, bir dizi üzerinde gezinen bir yapı vardı. Bu yapı, her döngüde, konveyörün yüküne bağlı olarak farklı sayıda tur atıyordu.
Yük düşükken: 50 tur × 0.02 ms = 1 ms. Yük yüksekken: 50 tur × 0.06 ms = 3 ms.
Yani, blok, yükle orantılı olarak yavaşlıyordu. Ve “yük yüksek” anları, tam da kapağın kapanması gereken anlardı. Çünkü kapak, ürünün “ağır” olduğu anda kapanıyordu.
Bu, kötü bir tesadüf değildi. Bu, tasarım hatasıydı. Blok, “kritik” bir döngüde (kapak senkronu), yük bağımlı bir hesap yapıyordu. Ve bu hesap, döngü süresini, tam da “kritik” anda, en kötü hale getiriyordu.
Ne Yaptım?
Üç şey:
- “Enerji optimizasyonu” bloğunu, kritik döngüden çıkardım. Artık, her döngüde değil, 100 ms’de bir çalışıyordu. Konveyörün ince ayarı, 100 ms’de bir güncelleniyordu. Bu, “enerji optimizasyonu” için yeterliydi — çünkü konveyörün yükü, 100 ms’de bir değişmiyordu, 100 ms’te bir okunması yeterliydi.
- Döngü süresini, 1.2 ms’ye geri getirdim. Kritik döngü (kapak senkronu), tekrar 1.2 ms’de. En kötü döngü, 1.5 ms.
- TIA Portal’da, “Cyclic time” alarmı kurdum. Döngü süresi, 2 ms’yi aşarsa, alarm versin. Bu, “hat durduracak” bir alarm değil, “dikkat edin” bir alarmıydı. Ama bu alarm, 4 ms’lik büyümeyi, üç hafta değil, üç saat içinde yakalayacaktı.
‘Çalışıyor’ Demek, ‘Doğru Çalışıyor’ Demek Değil
Bu vakada, en tehlikeli cümle “çalışıyor”du. Blok eklenmişti, “çalışıyor” denmişti. Hat durmamıştı, “çalışıyor” denmişti. Döngü süresi 4 ms’ye çıkmıştı, “çalışıyor” denmişti.
“Çalışıyor”, fonksiyonel bir ifadedir. “Doğru çalışıyor”, performans ifadesidir. Ve bu ikisi, sahadan ayrılır. Bir PLC, “çalışabilir” ama “doğru çalışmayabilir”. Ve bu fark, bir gün, bir kapağın 2 ms geç kapanmasıyla, bir ürünün ezilmesiyle, bir hat duruşuyla patlar.
Döngü süresi, alarm vermeden büyür. Ve bu yüzden, bakılmalı. TIA Portal’daki “Cyclic time” ekranı, “alarm” vermez. Ama bakarsanız, size “döngünüz 3 katına çıkmış” der. Ve bu bilgi, bir kapağın ezilmesinden önce gelir.
Bazen en pahalı hata, “alarm veren” hata değil, “alarm vermeyen” hatadır.