GX Simulator’ın Factory I/O’ya OPC Üzerinden Bağlanması

Sanal devreye alma, simüle edilen sahne birbirinden kopuk bir animasyon yerine denetlenen bir makine gibi davrandığında değer kazanır. Bir Mitsubishi PLC projesi için bu, GX mühendislik simülatöründen uyumlu bir OPC sunucusu üzerinden Factory I/O etiketlerine kadar izlenebilir bir veri yolu gerektirir.

Amaç yalnızca bir konveyörü hareket ettirmek değildir. Kullanışlı bir kurulum, fiziksel I/O kullanılabilir olmadan önce adres sahipliğini, sinyal yönünü, sıra davranışını, kilitlemeleri, zamanlamayı, iletişim kaybına verilen yanıtı ve yeniden başlatma mantığını doğrular.

Küçük bir sanal konveyör, eşleme, zamanlama ve kurtarma hatalarını gerçek bir kontrol panosuna ulaşmadan önce ortaya çıkarabilir.

Etiketleri eşlemeden önce yazılım uyumluluğunu doğrulayın

“GX Simulator”, farklı GX Works nesilleri ve MELSEC CPU aileleriyle ilişkili simülasyon işlevlerini ifade edebilir. OPC ürünleri de sürüme ve OPC DA ya da OPC UA sunup sunmadıklarına göre farklılık gösterir. Factory I/O, her kombinasyonu aynı şekilde desteklemeyebilecek sürücü seçenekleri sunar.

PLC ailesini, GX Works sürümünü, simülatör bileşenini, OPC sunucusu ürününü ve sürümünü, arayüz türünü ve Factory I/O sürümünü kaydedin. Ardından OPC sunucusunun bu simüle edilmiş CPU’ya bağlanabildiğini doğrulayın. Fiziksel bir Ethernet modülüyle çalışan bağlantı yönteminin yazılım simülatörüyle de otomatik olarak çalışacağını varsaymayın.

Mitsubishi, MX OPC’yi MELSEC programlanabilir kontrolör verilerini OPC üzerinden sunan bir yazılım olarak tanımlar. Daha yeni MELSEC iQ-R donanımları, yerleşik bir OPC UA sunucu modülü de kullanabilir; ancak bu mimari, simüle edilmiş bir kontrolöre bağlı PC barındırmalı bir sunucudan farklıdır. Tasarım notlarında ve sorun gidermede bu yolları birbirinden ayrı tutun.

Yazılımı yapılandırmadan önce veri sözleşmesini yazın

Her sinyal için bir satır içeren bir I/O listesi oluşturun. Factory I/O etiketini, Mitsubishi cihaz adresini, veri türünü, yönü, mühendislik anlamını, varsayılan durumu, güvenli durumu, güncelleme gereksinimini ve sorumlusunu ekleyin. Simülasyonda normalde saha giriş durumlarının sahibi olmalı, PLC mantığı ise aktüatör komutlarının sahibi olmalıdır.

Bu sahiplik kuralı, iki uygulamanın aynı noktaya yazmasını önler. Simüle edilmiş bir fotosel PLC giriş cihazına yazabilirken PLC, Factory I/O’nun okuyacağı bir motor komutuna yazabilir. Her iki taraf da aynı etikete yazarsa, her bir bağlantı teknik olarak etkin olsa bile görüntü titreyebilir veya rastgele görünebilir.

Bit cihazları, sözcükler, işaretli tam sayılar, kayan noktalı değerler ve diziler açık tür işleme gerektirir. Bir OPC istemcisi bir değeri başarıyla görüntüleyebilirken Factory I/O yanlış türü veya bit sırasını yorumlayabilir. Önce bir Boolean noktası ve değişen değerleri açıkça görülebilen bir sözcükle başlayın. Yön ve ölçeklendirme doğrulanana kadar kapsamı genişletmeyin.

Bağlantıyı katmanlar halinde oluşturup test edin

Önce desteklenen GX simülatöründe çalıştırmak üzere minimal bir PLC programı oluşturun. Bilinen bir dahili cihazı zorlayın veya değiştirin ve ladder izleyicisinin beklenen durumu gösterdiğini doğrulayın. Bu, programın, seçili CPU’nun ve simülatörün çalıştığını gösterir.

İkinci olarak OPC sunucusunu bu simüle edilmiş kontrolör için yapılandırın. Yalnızca birkaç test etiketi oluşturun. Kaliteyi, zaman damgasını, değeri ve yazma yeteneğini doğrulamak için sunucunun kendi istemcisini veya tanılama görünümünü kullanın. “Kötü” ya da “belirsiz” olarak işaretlenen bir değer varsa, Factory I/O’yu açmadan önce bu katmanda düzeltin.

Üçüncü olarak Factory I/O OPC istemcisini yapılandırın ve doğrulanmış etiketlere göz atın veya bunları girin. Bir simüle edilmiş sensörü ve bir aktüatör komutunu eşleyin. Her iki yönü de bağımsız olarak doğrulayın: sahne girişini değiştirip PLC belleğini gözlemleyin, ardından PLC çıkışını değiştirip sahneyi gözlemleyin.

Bu katmanlı yöntem arızaları birbirinden ayırır. GX belleği değişmiyorsa sorun PLC simülasyonundadır. GX değişiyor ancak OPC istemcisi değişmiyorsa sunucu yapılandırmasını ve cihaz adreslemesini inceleyin. OPC sunucusu sağlıklı ancak Factory I/O sabitse istemci bağlantısını, öğe adlarını, erişim haklarını ve etiket eşlemesini inceleyin.

Katman katman doğrulama, PLC, OPC sunucusu ve Factory I/O yapılandırma arızalarını birbirinden ayırır.

Üç bağımsız sistem arasındaki zamanlamayı hesaba katın

PLC taraması, OPC sunucusu yoklaması, istemci aboneliği ve Factory I/O fizik güncellemesi aynı anda gerçekleşmez. Birleşik örnekleme aralığından daha kısa bir sensör darbesi, PLC onu gözlemlemeden kaybolabilir. Yerel bir iş istasyonunda bile ağ veya bilgisayar yükü titreşim ekleyebilir.

Önemli olaylar örneklemeye dayanacak şekilde tasarlanmalıdır. Simüle edilmiş bir cihaz, onay alınana kadar durumunu koruyabilir veya PLC mantığı, sıra bu durumu kullanana kadar algılanan geçişi kilitleyebilir. Gösterim amacıyla her darbeyi uzatmak kullanışlıdır ancak kenar işleme hatalarını gizleyebilir. Test davranışını beklenen fiziksel sensöre ve üretim hızına uyarlayın.

Yapılandırılmış OPC güncelleme hızının toplam gecikme olduğunu varsaymak yerine, uçtan uca etkin gecikmeyi ölçün. Zamanlamanın sıra için önemli olduğu durumlarda sahne geçişini, OPC zaman damgasını, PLC gözlemini, çıkış kararını ve ortaya çıkan sahne eylemini günlüğe kaydedin.

OPC DA ve iş istasyonu kısıtlamalarını planlayın

Geleneksel OPC DA, Microsoft COM teknolojisini kullanır. Tüm uygulamalar tek bir Windows hesabıyla aynı bilgisayarda çalıştığında kurulum genellikle daha basittir. Dağıtık yapılandırmalar DCOM kimliği, izinler, güvenlik duvarı ve hizmet hesabı sorunlarını beraberinde getirir. Etkileşimli olarak çalışan bir bağlantı, yeniden başlatma sonrasında OPC sunucusu farklı bir hesapla başlarsa çalışmayabilir.

OPC UA, uç noktalar, sertifikalar ve ilkeler içeren farklı bir güvenlik modeli kullanır. DCOM’u ortadan kaldırır ancak yine de sertifika güveni, kullanıcı izinleri ve uyumlu veri modelleri gerektirir. DA ve UA’yı birbirinin yerine kullanılabilen etiketler olarak görmek yerine, seçilen yazılım tarafından gerçekten desteklenen arayüzü kullanın.

Arıza ve yeniden başlatma durumlarını bilinçli olarak test edin

Konveyör çalışırken OPC istemcisinin bağlantısını kesin. PLC simülatörünü durdurun. OPC sunucusunu yeniden başlatın. Daha önce çıkışlar açıkken Factory I/O’yu yeniden açın. Makine, yalnızca eski değerler yeniden göründüğü veya istemci yeniden bağlandığı için tehlikeli harekete devam etmemelidir.

Kötü kaliteye, iletişim kaybına ve başlangıç değerlerine verilecek yanıtı tanımlayın. Sürece bağlı olarak komutlar zorla kapatılabilir, tutulabilir veya kontrollü duruşla ele alınabilir. PLC’nin gerçek bir yanlış durumu kullanılamayan veriden ayırt edebilmesi için girişlerde açık bir iletişim sağlığı biti gerekebilir.

Ayrıca soğuk başlatmayı, sıcak yeniden başlatmayı, sayaç saklamayı, reçete uyuşmazlığını, engellenmiş sensörleri, eş zamanlı gelişleri ve operatör sıfırlamasını test edin. Her yazılabilir etiketin başlangıç durumunu ve otomatik moda geçmek için gereken sırayı belgeleyin.

Sanal hücreyi bir test düzeneğine dönüştürün

Tekrarlanabilir kabul senaryoları kullanın: başlatma izinleri olmadan aktüatör çalışmaması; her ürün için tek sayım; hedefte kontrollü duruş; engellenmiş sensörde zaman aşımı; iletişim kaybında arıza; yeniden bağlantı sonrasında öngörülebilir kurtarma. Etiket trendleri ve başarılı/başarısız kayıtları, hareket eden bir sahnenin ekran görüntülerinden daha güçlü kanıt sağlar.

Mitsubishi kontrolör seçenekleri Mitsubishi Electric koleksiyonunda, daha kapsamlı kontrolör donanımları ise PLC ve PAC Sistemleri altında incelenebilir.

OPC yalnızca taşıma katmanıdır. Mühendislik değeri, sanal hücre PLC davranışını, sinyal sahipliğini, zamanlama varsayımlarını, arıza yanıtını ve fiziksel makineye aktarılacak yeniden başlatma mantığını test etmek için tekrarlanabilir bir ortam haline geldiğinde ortaya çıkar.