RSLogix 500 Çevrimiçi Düzenleme Sırasında Neden Yavaşlar

Yavaş RSLogix 500 çevrimiçi düzenleme işlemi çoğu zaman eskimiş bir SLC işlemcisine bağlanır; ancak görünen gecikme birkaç farklı noktadan kaynaklanabilir: mühendislik iş istasyonu, RSLinx iletişimi, yönlendirilmiş veya gürültülü bir ağ, proje dosyası tutarsızlığı, kullanılabilir denetleyici belleği ya da çevrimiçi düzenlemeyi sürdürmek için işlemcinin gerçekleştirmesi gereken işler. Bu katmanları birbirinden ayırmadan donanımı değiştirmek, asıl arızanın giderilmeden kalmasına neden olabilir.

Denetleyiciyi veya ağı değiştirmeden önce gecikmenin nerede oluştuğunu (ekran güncellemesi, tarama, yükleme, doğrulama, kabul etme, test etme veya birleştirme) ölçün.

Belirtiyi kesin olarak tanımlayın

“Çevrimiçi yavaşlık” çok farklı arızaları ifade edebilir. Gecikmenin bir veri tablosunu açarken, merdiven mantığını kaydırırken, projede arama yaparken, bir rung'u düzenlerken, söz dizimini doğrularken, bir düzenlemeyi kabul ederken, düzenlemeleri test ederken, düzenlemeleri birleştirirken veya dosyayı kaydederken ortaya çıkıp çıkmadığını kaydedin. İşlemcinin yanıt vermeyi sürdürüp sürdürmediğini ve üretim tarama süresinin, iletişim hatalarının veya HMI güncellemelerinin aynı anda değişip değişmediğini not edin.

İzlenime güvenmek yerine, tekrarlanabilir birkaç işlemi zamanlayın. Aynı projede çevrimdışı gezinmeyi çevrimiçi gezinmeyle karşılaştırın. Basit bir veri tablosu okumasını yüklemeyle karşılaştırın. Çevrimdışı proje zaten yavaşsa, denetleyiciden önce iş istasyonunun veya proje veritabanının incelenmesi gerekir.

Güvenli bir temel durum oluşturun

Çalışan programı yükleyip koruyun, ardından amaçlanan kaynak dosyayla karşılaştırın. İşlemci kataloğunu, serisini, ürün yazılımını, bellek boyutunu, çalışma modunu, RSLogix 500 sürümünü, RSLinx sürümünü, iletişim sürücüsünü, güzergâhı, iş istasyonunun işletim sistemini ve boş disk ile bellek kaynaklarını kaydedin. Bir düzenlemenin güvenle iptal edilebileceği bir makine durumu koruyun.

Rockwell Automation SLC 500 Modular Hardware Style User Manual, desteklenen işlemci ve iletişim yapılandırmaları için temel donanım başvuru kaynağıdır. SLC 500 Instruction Set Reference Manual ise komut davranışlarını, veri dosyalarını, durum bilgilerini ve önerilen bir düzenlemenin yürütmeyi veya bellek kullanımını değiştirmesi durumunda önem kazanabilecek aritmetik hataları belgeler.

İş istasyonu gecikmesini iletişim gecikmesinden ayırın

İlgisiz uygulamaları kapatın, gereksiz proje eklentilerini devre dışı bırakın ve gecikmeyi yeniden oluştururken CPU kullanımını, bellek baskısını, disk etkinliğini ve ekran yanıtını gözlemleyin. Büyük çapraz başvuru veritabanları, açık çok sayıda veri tablosu, animasyonlu merdiven durumu, antivirüs taraması, uzak masaüstü grafikleri ve neredeyse dolu bir sistem sürücüsü, denetleyicinin taramasını değiştirmeden düzenleyiciyi yavaş hissettirebilir.

Güvenlik yazılımını değiştirmeden önce onaylı bakım politikasını uygulayın. Tanılama amacıyla bir istisna eklenmesi veya geçici çevrimdışı test kontrollü olmalı ve sonrasında geri alınmalıdır. Eski bir aracı daha duyarlı hâle getirmek için uç nokta korumasını kalıcı olarak zayıflatmayın.

Ardından iletişimi test edin. RSLinx sürücü tanılamalarını gözlemleyin ve güvenli, desteklenen bir alternatif mevcut olduğunda doğrudan yerel yolu normal yönlendirilmiş yolla karşılaştırın. Yinelenen yeniden denemeleri, kararsız düğüm görünürlüğünü, yinelenen adresleri, Ethernet üzerindeki dupleks veya anahtar hatalarını ve seri, DH-485 veya DH+ ağlarındaki fiziksel katman arızalarını kontrol edin. Sonunda başarılı olan bir tarama, programlama yolunun sağlıklı olduğunu kanıtlamaz.

Proje ve oturum tutarlılığını kontrol edin

Açık dosyanın çalışan denetleyiciyle eşleştiği biliniyorsa çevrimiçi oturum daha güvenlidir. Yazılımın eski veya yapısal olarak farklı bir projeyi denetleyiciyle ilişkilendirmesi gerekiyorsa, bağlantı kararlı olsa bile gezinme ve doğrulama kafa karıştırıcı hâle gelebilir. Denetleyiciye kontrollü bir kopyaya yükleme yapın, dosyaları karşılaştırın ve üretim mantığını düzenlemeden önce açıklanamayan farklılıkları giderin.

Terk edilmiş düzenleme bölgelerini iptal edin ve başka bir iş istasyonunun bir düzenleme oturumuna sahip olmadığını doğrulayın. Mevcut kuvvetlendirmeleri, çevrimiçi düzenlemeleri ve geçici bakım mantığını kaydedin. Çözülmemiş birden fazla değişiklik, riski artırır ve gecikmenin yeni düzenlemeden mi yoksa mevcut durumdan mı kaynaklandığını anlamayı zorlaştırır.

Denetleyici tarafındaki maliyeti anlayın

Çevrimiçi düzenleme, çevrimdışı bir dosyayı değiştirmekle aynı değildir. Değişiklik birleştirilene veya iptal edilene kadar denetleyici ve yazılım, düzenleme sırası boyunca özgün ve değiştirilmiş mantığı korumalıdır. Bu nedenle kullanılabilir bellek ve işlemci kapasitesi önemlidir. Bellek sınırına yaklaşmış bir denetleyicinin, kapsamlı bir düzenleme için gereken geçici yapıları oluşturacak daha az alanı olabilir.

İlk tanılama düzenlemesini küçük tutun. Mantık değişikliğini yeni veri dosyaları, genişletilmiş veri tabloları, iletişim değişiklikleri ve dokümantasyon temizliğiyle birleştirmeyin. Bazı yapısal değişiklikler, çevrimiçi bir geçici çözüm yerine çevrimdışı düzenleme ve indirme gerektirir. Bir değişiklik platformun desteklenen çevrimiçi düzenleme sınırları içinde ifade edilemiyorsa doğru duruşu planlayın.

Düzenleme öncesinde, sırasında ve sonrasında işlemci tarama süresini ve maksimum taramayı, iletişim durumunu, majör ve minör hata göstergelerini ve proses zamanlamasını izleyin. Düzenleyicinin hızlı yanıt vermesi, aşırı tarama değişkenliği oluşturan veya zamana duyarlı bir sırayı değiştiren bir düzenlemeyi haklı çıkarmaz.

Kontrollü bir düzenleme sırası kullanın

Önce, ekipmanı etkilemeden düzenleme yolunu kanıtlayan en küçük değişikliği oluşturun. Saha prosedürüne göre doğrulayın, kabul edin ve denetleyiciyi ve uygulamayı gözlemleyin. Düzenlemeyi yalnızca proses tanımlanmış güvenli durumdayken test edin. Birleştirmeden önce amaçlanan mantığı ve etkilenen tüm çıkışları doğrulayın.

Birleştirmeden sonra yeniden karşılaştırma yapın veya yükleyin ve ortaya çıkan kaynak dosyayı zaman damgası, değişiklik nedeni, onaylayan kişi ve geri alma referansıyla kaydedin. Performans belirli bir aşamada kötüleşirse durun ve bu kanıtı koruyun. Daha büyük düzenlemeleri tekrar tekrar kabul etmek, bilinmeyen bir gecikmeyi tanılamak için geçerli bir yöntem değildir.

Yaygın örüntüleri yorumlayın

Çevrimdışı kaydırma ve aramalar yavaşken denetleyici veri güncellemeleri normal kalıyorsa, iş istasyonuna ve proje veritabanına odaklanın. Tüm çevrimiçi okumalar duraklıyor ve sürücü yeniden denemeleri artıyorsa iletişim yoluna odaklanın. Küçük düzenlemeler çalışıyor, ancak büyük düzenlemeler başarısız oluyor veya takılıyorsa belleği, proje yapısını ve desteklenen düzenleme sınırlarını inceleyin. Düzenleyici yanıt vermeyi sürdürürken proses tarama süresi artıyorsa mantık değişikliğini araştırın.

Yavaşlama yalnızca saatlerce çalıştıktan sonra ortaya çıkıyorsa denetleyiciyi yeniden başlatmak yerine mühendislik oturumunu kontrollü bir şekilde yeniden başlatın ve kaynak kullanımındaki artışı kontrol edin. Başka bir iş istasyonu aynı ağ yolundan normal çalışıyorsa PLC'nin arızalı olduğuna karar vermeden önce yazılım sürümlerini, sürücüleri, güvenlik denetimlerini ve proje dosyalarını karşılaştırın.

Çevrimiçi düzenlemeyi ne zaman durduracağınıza karar verin

Çalışan proje güvenle eşleştirilemiyorsa, iletişim kararsızsa, denetleyici bir kaynak sınırına yakınsa, değişiklik yapısal düzenlemeler gerektiriyorsa veya proses testi kaldıramıyorsa durun. Çalışma zamanında onarımı zorlamak yerine yedekler ve geri alma planıyla çevrimdışı doğrulama ve kontrollü indirme planlayın.

Eski platformlar ve geçiş seçenekleri Allen-Bradley koleksiyonunda ve PLC ve PAC sistemleri koleksiyonunda incelenebilir. Geçiş, tek bir yavaş düzenleme oturumuna göre değil; yaşam döngüsü riski, performans, yedek parçalar ve kurtarma konusundaki kanıtlara göre yapılmalıdır.

Mühendislik bakış açısı

Yararlı soru “RSLogix neden yavaş?” değil, “Hangi sınır, hangi tekrarlanabilir işlem sırasında yavaşlıyor ve onunla birlikte hangi kanıt değişiyor?” sorusudur. İş istasyonu, iletişim, proje, denetleyici ve proses etkileri ayrı ayrı ölçüldüğünde ekip, çalışan makineyi koruyarak gerçek kısıtı giderebilir.