Studio 5000 Merdiven Mantığında ONS Talimatı OTE’yi Enerjilendirmiyor
Studio 5000'de ONS talimatı çalışıyor, ancak tek atımlık sinyal yalnızca bir tarama boyunca doğru olduğu için OTE bobini hiç kilitlenmiyor. Bunun yerine OTL/...
Çevrimiçi izleme ekranları bazen bir ONS depolama bitinin geçiş yaptığını gösterirken, ilgili OTE’nin bir pompa yol vericisini veya solenoidi enerjilendirdiği hiç görülmeyebilir. Studio 5000 Logix Designer’da bunun nedeni genellikle arızalı bir çıkış kartı değildir. ONS, yalnızca bir rutin değerlendirmesi boyunca doğru olan yükselen kenar dedektörüdür. OTE ise her taramada rung koşulunu dahili bir mühürleme olmadan yazar. Bunları doğrudan eşleştirdiğinizde, genellikle 5–20 ms süren tek taramalık bir darbe oluşturursunuz; kontaktörler, VFD’ler ve hatta HMI animasyonları bu darbeyi pratikte yok sayar, IDE’nin daha yavaş görüntü yenileme hızı ise darbeyi tamamen kaçırır.
Röle mantığı sezgisi burada yanıltır: 10 ms’lik bir Logix yazma işlemi, enerjili tutulan bir yardımcı kontakla aynı şey değildir.
Tarama fiziği
| Tarama | Giriş kenarı | ONS çıkışı | OTE etiketi |
|---|---|---|---|
| n-1 | 0 | 0 | 0 |
| n | 0→1 | 1 | 1 (bir tarama) |
| n+1 | 1 | 0 | 0 |
| n+2 | 1 | 0 | 0 |
Gerçek yol vericiler genellikle 50–100 ms boyunca kesintisiz komut gerektirir. Tek başına bir ONS→OTE yolu bunu sağlayamaz. Studio 5000’in izleme pencereleri görev periyodundan çok daha yavaş örnekleme yapar; bu nedenle 10 ms’lik bir darbeyi yakalama olasılığı düşüktür. “ONS hiç çalışmadı” efsanesinin nedeni budur.
Tanılama amaçlı uzatmalar
- ONS olayı üzerine paralel bir TOF (1–2 sn ön ayarlı) ekleyin; IDE’de .TT/.DN değerlerini izleyin
- Her kenarda bir REAL sayacına 1.0 ekleyin; sayımı trend olarak izleyin
- Gerçek görev çevrim oranını görmek için OTE etiketinde yaklaşık 10 ms örnekleme ile Studio Trend kullanın
Mühürleme veya OTL/OTU kalıpları, tek atımlık bir kararı sürekli bir çalıştırma komutuna dönüştürür.
Çözüm A — OTL / OTU
[Pump1_RunCmd_ONS] ----(OTL Pump1_RunCmd) [Pump1_Stop_PB] ----(OTU Pump1_RunCmd) [Pump1_Fault] ----(OTU Pump1_RunCmd)
Mandalların varsayılan olarak güç çevrimleri boyunca kalıcı olduğunu unutmayın. Yeniden başlatma sonrasında bir motorun tekrar çalışmaması gereken çıkışlar için ilk tarama veya bakım sıfırlamaları ekleyin.
Çözüm B — OTE çevresinde mühürleme
|--[Start_ONS]-+----------(OTE RunCmd)--| | | | |--[RunCmd]----+ | |--[Stop_PB]---/ |
Bu, Logix programlama uygulamalarında yaygın olarak önerilen üç telli yol verici benzetmesidir: ONS başlatma kenarını sağlar; mühürlenmiş RunCmd kontağı, durdurma veya kilitleme devresi yolu açana kadar OTE’yi enerjili tutar.
Çalışan/yedek bağlamı ve dikkat edilmesi gerekenler
Saatlik çalışma süresine dayalı pompa sıralayıcıları, “bu pompa artık lider” karşılaştırmalarında ONS’yi sıklıkla yanlış kullanır. Kenardan komuta yapısını düzelttikten sonra minimum çalışma zamanlayıcıları (kısa devreye girme önleme), dönüşümlü lider seçimi kilitlemeleri ve arıza OTU yolları ekleyin. Mühürlenmiş 1 değerini daha sonra sessizce 0 ile geçersiz kılan yinelenen bobinler için OTE etiketine çapraz referans verin. BOOL başına tek bobin sahibi olmasını tercih edin.
Ayrıca dal yapısını inceleyin: ONS’yi atlayan paralel bir yol, depolama biti titreşse bile OTE’nin yanlış kalmasına neden olabilir; aynı BOOL’u yazan ikinci bir rutin ise bir görev sonra kusursuz bir mühürlemeyi bozabilir. Birden fazla tüketici darbeye ihtiyaç duyduğunda, ONS’den tek bir ara BOOL sürün; ardından bu bitten mühürlenmiş veya mandallanmış mantıkla dağıtım yapın.
// Geçici uzatma — son devreye alma öncesinde kaldırın [Pump1_Start_ONS] ---(TOF Stretch_Timer, 2.0 s) [Stretch_Timer.TT] ---(OTE Diagnostic_Stretch_On)
Uzatma devredeyken Diagnostic_Stretch_On IDE’de ve bir HMI yanıp sönme göstergesinde görünür kalır; böylece üretim mühürleme mantığına güvenmeden önce kenar hızını doğrulayabilirsiniz. Operatörlerin bir servis lambasını sonsuza kadar takip etmemesi için FAT sonrasında tanılama yolunu silin veya devre dışı bırakın.
Gece vardiyasındaki düzenlemelerin bir sonraki paketlemede çıplak ONS→OTE rung’larını yeniden eklememesi için bu sahiplik kurallarını PLC ve PAC platformları genelinde tutarlı biçimde uygulayın.
Yazar hakkında
Mark Townsend | Kıdemli Otomasyon Mühendisi – Allen-Bradley Sistemleri
Mark Townsend, ControlLogix, CompactLogix ve eski SLC-500 sistemlerini kapsayan Allen-Bradley platformlarında 18 yılı aşkın deneyime sahip kıdemli bir otomasyon mühendisidir. Günlük çalışmaları, eski ve karma sistem filolarında RSLogix / Studio 5000 mantığı ile FactoryTalk View HMI devreye alma işlemlerini kapsar.