TIA Portal Optimizasyonu: S7-1500'ünüz Neden Yavaşlar ve Nasıl Düzeltilir

Giriş: Kritik Bir Metrik Olarak Döngü Süresi

Bir S7-1500'ün döngü süresi yalnızca teknik bir değer değil; program kalitesinin aynasıdır. Kötü optimize edilmiş bir program bir S7-1516'yı çökertebilirken, aşırı boyutlandırılmış bir S7-1511 minimal kodla mükemmel çalışabilir. Bu makale döngü süresi kaynaklarının nerede harcandığını sistematik olarak göstermekte ve hedefli optimizasyonların nasıl yapılacağını açıklamaktadır.

Döngü Süresini Ölçme ve Analiz Etme

Optimize etmeden önce ölçün. TIA Portal'da mevcut değerleri Çevrimiçi → Döngü Süresi İzleme altında bulabilirsiniz. Tanı tamponu ve OB_CYCLIC_INT sistem bloğu aracılığıyla daha ayrıntılı bilgi elde edilebilir. Sürekli ölçüm için TIA Portal'daki İz işlevini kullanın (Çevrimiçi → İz). Döngü süresi sistem değişkenini veya daha iyisi SFB "RUNTIME" değişkenlerini kaydedin.

S7-1500 için referans değerler:

• S7-1511: 1000 komut başına tipik 1–3 ms
• S7-1515: 1000 komut başına tipik 0,5–1,5 ms
• S7-1518: 1000 komut başına tipik 0,2–0,8 ms

Döngü Süresi Sorunlarının En Yaygın Nedenleri

1. Verimsiz DB Erişimi

Klasik performans katili. Birçok programcı DB değişkenlerine tam sembolik adreslemeyle erişir: "BenimDB".BenimDeğişkenim. Aynı DB'ye sık erişildiğinde, DB'yi bloğun başında yerel bir örneğe kopyalamak veya ANY işaretçileri ve SFC20 BLKMOV ile çalışmak çok daha hızlıdır.

Daha da kötüsü dolaylı DB erişimidir: DB[i].DBW[j]. Bu erişim düzeni ön derlemeyi engeller ve doğrudan erişime kıyasla 3–5 kat daha fazla çalışma süresi maliyeti getirir. Mümkün olan her yerde yapılandırılmış veri türlerine ve doğrudan adreslemeye geçin.

2. Yanlış Blok Mimarisinden Kaynaklanan OB1 Aşırı Yükü

Yaygın bir hata, OB1'e çok fazla görev yüklemektir. Daha iyi bir uygulama, zaman açısından kritik kontrol döngüleri için döngüsel interrupt OB'leri kullanmaktır: OB30 (5 ms), OB31 (2 ms), OB32 (1 ms). OB1 öncelikli olarak durum makinelerini ve sıraları işlemelidir; hızlı kontrol döngüleri daha kısa OB'lere taşınmalıdır. Ancak toplam kullanıma dikkat edin: OB30 kendi aralığından fazla süre gerektirirse hemen yeniden başlar ve OB1'in önüne geçer.

3. PROFINET İletişim Yükü

PROFINET iletişimi arka planda çalışır ancak işlemciyi yükler. Kısa güncelleme süreleriyle çok fazla IO cihazı döngü süresinin %20–40'ını harcatabilir. Optimizasyonlar:

• PROFINET güncelleme sürelerini gerçek gereksinimlere göre ayarlayın (her zaman 1 ms gerekmez)
• Az veri içeren IO cihazlarını bir cihazda birleştirin (ağ IO'su ve ayrı modüller)
• Büyük veri paketleri için DPRD_DAT / DPWR_DAT ile tutarlı veri aralıkları kullanın

4. Çalışma Süresi Sınırı Olmayan Döngüler

Büyük diziler üzerindeki FOR döngüleri döngü süresi tuzaklarıdır. 10.000 elemanlı bir döngü kolayca 5–10 ms harcatabilir. Çözümler:

• Döngüleri birden fazla çevrime dağıtın (devam işaretçisiyle durum makinesi yaklaşımı)
• Blok kopyaları için manuel döngüler yerine MOVE_BLK_VARIANT kullanın
• Sıralama işlevlerini kritik yolun dışına taşıyın

5. Aşırı Yüklü Tanı Blokları

Siemens standart tanı işlevleri olan DeviceStates veya ModuleStates kaynak yoğundur. Bunları her döngüde değil, yalnızca ihtiyaç duyulduğunda (kenar tetiklemeli veya zaman gecikmeli) çağırın. Yaygın bir hata: 50 modül × DeviceStates OB1'de = döngü başına 2–3 ms heba edilen döngü süresi.

TIA Portal'daki Optimizasyon Araçları

Çalışma Süresi Ölçümüyle Profil Oluşturma

TIA Portal V16+'da, çalışma süresi ölçümünü kullanarak bireysel FC/FB çağrılarını doğrudan ölçebilirsiniz. Şüpheli bloğun öncesine ve sonrasına SFC64 "TIME_TCK" sistem işlevini ekleyin ve farkı hesaplayın. Bu, dakikalar içinde tam sorumlu bloğu bulmanızı sağlar.

Optimize Edilmiş Blok Erişimi

Tüm DB'ler için "Optimize edilmiş blok erişimi" seçeneğini etkinleştirin (Özellikler → Öznitelikler → Optimize edilmiş blok erişimi). Bu seçenek sembolik erişimi etkinleştirir ve CPU'nun değişkenleri bellekte optimal olarak yerleştirmesine olanak tanır. Uyarı: etkinleştirildikten sonra mutlak DB adresleme (DBW0, DBD4) artık mümkün değil — mevcut kodu önceden kontrol edin.

Donanım Yapılandırmasını Kontrol Edin

Donanım yapılandırmasında döngü süresi izlemeyi kontrol edin (CPU'nun Özellikleri → Döngü/Senkronizasyon). Çok yüksek bir izleme süresi (varsayılan: 150 ms) aralıklı döngü süresi aşımlarını gizler. Gerçek anomalileri yakalamak için değeri ölçülen maksimumunuzun %120'sine ayarlayın.

MOVE_BLK ve Yapılandırılmış Optimizasyonlar

Büyük veri paketlerinin aktarımı için MOVE_BLK (SFC20) manuel döngülerden önemli ölçüde daha hızlıdır. Sözdizimi:

CALL SFC20 "BLKMOV"
  SRCBLK := P#DB1.DBX0.0 BYTE 100
  RET_VAL := MW100
  DSTBLK := P#DB2.DBX0.0 BYTE 100

TIA Portal V15+ ile S7-1500 için: Değişken uzunlukları ve ANY türlerini işleyen ve ek hata işleme sağlayan MOVE_BLK_VARIANT'ı tercih edin.

Pratik İpucu: Döngü Süresi Bütçesi Oluşturun

Her OB için döngü süresi "bütçelerini" detaylandıran dahili bir belge oluşturun. Örnek: OB1 = maks. 8 ms, OB30 = maks. 1,8 ms. Bu değerlere karşı düzenli olarak (örn. aylık veya program değişikliklerinden sonra) ölçüm yapın. Döngü süresi bozulması genellikle tedricidir — devreye almada 0,2 ms maliyeti olan bir blok, veri hacmi artışı nedeniyle bir yıl sonra 1,5 ms harcatabilir.

Sonuç

TIA Portal performans sorunları neredeyse her zaman birkaç iyi bilinen nedene bağlanabilir: verimsiz DB erişimi, yanlış OB dağılımı, kısa güncelleme süreleriyle çok fazla PROFINET cihazı ve kontrolsüz döngüler. Doğru ölçüm araçlarıyla darboğazlar saatler içinde bulunup giderilebilir. Düzenli performans incelemeleri profesyonel PLC geliştirmenin bir parçasıdır.