EtherCAT’in gerçek zamanlı performansı nasıldır?

EtherCAT, küçük süreç verilerini kısa ve öngörülebilir çevrimlerle taşımak; uygun cihazları ortak bir zaman tabanında çalıştırmak için tasarlanmıştır. Ancak bir makinenin gerçek zamanlı davranışı yalnız ağ adına bağlı değildir. Kontrolörün işi zamanında bitirmesi, verinin kullanılacağı andan önce ulaşması ve giriş/çıkış donanımının istenen hızda çalışması birlikte değerlendirilir. EtherCAT’in güçlü yanı bu zamanlama zincirini destekleyen mimarisidir; her kurulum için aynı tepki süresini garanti etmesi değildir. ^{[1] [2]}

Bir uygulamada asıl soru “kaç Mbit/s?” değil, “doğru veri, doğru çıkışa en geç ne zaman uygulanacak?” olmalıdır. Bu yazıda çerçeve işleme, deterministik iletişim, dağıtılmış saatler, cihazlar arası aktarım ve yedeklilik bu sorunun etrafında ele alınmaktadır.

Önce dört farklı zaman değerini ayırın

Çevrim süresi, planlanan veri güncellemeleri arasındaki aralıktır. Örneğin 250 µs, saniyede 4.000 çevrim; 1 ms ise 1.000 çevrim demektir. Gecikme / uçtan uca tepki süresi, seçilmiş başlangıç olayıyla sonuç arasındaki süredir. Sensördeki değişimden fiziksel çıkışa kadar ölçülen süre, bir Ethernet çerçevesinin ağda dolaşma süresiyle aynı değildir.

Jitter, belirli bir zamanlama değerinin değişkenliğidir. Görev başlama jitter’ı, çerçeve gönderim jitter’ı ve fiziksel çıkış jitter’ı ayrı ölçümlerdir. Senkronizasyon hatası ise iki cihazın saatleri veya karşılaştırılabilir yerel olayları arasındaki zaman farkını anlatır. “Jitter 1 µs” deniyorsa hangi olayın, hangi yöntemle ve hangi istatistikle ölçüldüğü açıklanmalıdır.

Bu ayrımın pratik sonucu şudur: İki çıkış birbirine çok yakın anlarda çalışabilir, fakat ikisi de uygulamanın son teslim zamanına geç kalabilir. Tersine, sonuç yeterince erken ulaşırken eksenler arası eşzamanlılık yetersiz kalabilir. Düşük gecikme, düşük jitter ve iyi senkronizasyon birbirini tamamlar; birbirinin yerine geçmez.

Çerçeveyi geçerken işlemek neden hızlıdır?

EtherCAT saha cihazındaki ESC, çerçeve geçerken ilgili veriyi okur ve kendi giriş verisini yerleştirir. Her cihazın uygulama yazılımını bekleyen ayrı bir sorgu–cevap alışverişi gerekmez. Çok sayıda küçük veri alanının aynı çerçevede taşınabilmesi de protokol yükünü azaltır. Geçerken işleme mantığı, klasik EtherCAT’in 100 Mbit/s fiziksel bağlantısını verimli kullanmasının temelidir. ^[1]

Bu, Ethernet ile EtherCAT farkını yalnız kablo hızına indirgememek gerektiğini gösterir. 100 Mbit/s bir bit hızıdır; 100 µs bir zaman aralığıdır. Cihazın iç kontrol algoritması ve fiziksel giriş filtresi, ESC’nin hızlı çerçeve işlemesiyle aynı iş değildir. Ayrıca EtherCAT G/G10 gibi uzantıları klasik 100 Mbit/s kurulumun otomatik hız artışı olarak okumamak gerekir.

Distributed Clocks: paket geldiğinde değil, belirlenen zamanda

Distributed Clocks (DC), destekleyen cihazları ortak zaman referansına yaklaştırır. Referans saate göre ofset ve yayılma gecikmesi dikkate alınır. Böylece yerel örnekleme veya çıkış olayı, her cihazın paketi aldığı ana değil ortak takvime bağlanabilir. Bu, özellikle birden çok servo ekseninin birlikte çalışmasında önemlidir. Bunun koşulu, çıkış verisinin ilgili DC olayından önce hazır olmasıdır. ^{[1] [14]}

DC desteği, DC’nin etkin olduğu anlamına gelmez. Delta Motion, desteklenen senkronizasyon modunun ayrıca seçilmesini ister; modu ifade eden adlar üreticiye göre değişebilir. Bu nedenle cihaz ve sensör entegrasyonunda yalnız EtherCAT logosuna değil, seçilen çalışma moduna da bakılır. DC desteklemeyen I/O, DC destekleyen cihazlarla aynı ağda yer alabilse de aynı zamanlama yeteneğine sahip sayılmaz. ^[2]

SYNC0/SYNC1 olayları, çevrim ve faz ayarları kullanılan cihaza göre değerlendirilir. Referans saat, master zamanının referans saate göre kaydırılması veya bunun tersi gibi seçenekler de yazılımın uygulamasına bağlıdır. Cihaz üreticisinin sunduğu modu, yalnız daha küçük bir sayı görmek için gelişigüzel değiştirmek yerine veri-hazırlık zamanıyla birlikte incelemek gerekir. ^[14]

250 µs çevrim örneği: kaç mikrosaniye pay kaldı?

Aşağıdaki tablo tamamen varsayımsal bir zamanlama örneğidir. Girişi okuyan aktarımın, kontrolör hesabının ve çıkışı yazan aktarımın aynı 250 µs aralığına yerleştirilebildiğini varsayıyoruz. Bütün EtherCAT masterları bu iş sırasını kullanmaz; başka bir uygulama bir veya daha fazla çevrimlik boru hattıyla çalışabilir. Cihazın yerel hazırlık süresi de gerçek projede kılavuzdan veya ölçümden bulunmalıdır.

Son veri teslim anı = 250 − 20 = 230 µs. Veri 190 µs’de ulaştığına göre kalan zaman payı 230 − 190 = 40 µs olur. Çıkış verisini taşıyan yol 50 µs daha geç tamamlanırsa veri 240 µs’de ulaşır; 20 µs hazırlıkla 260 µs’ye kalır. Böylece 250 µs hedefi 10 µs kaçırılmıştır.

Saatler kusursuza yakın eşzamanlı olsa bile bu geç veriyi geçmişteki çıkış olayına yetiştiremez. Eski değerin tutulması, hata üretilmesi veya başka bir davranış görülmesi cihazın çalışma moduna ve uygulamaya bağlıdır; tablodan evrensel arıza davranışı çıkarılamaz.

Bu örnekte 0 µs’de alınan örneğin planlanan çıkışı 250 µs’dedir. Sadece çevrim başında örneklenen bir girişte fiziksel olay o örneklemenin hemen ardından oluşursa, yeni örnek için neredeyse bir çevrim daha bekleyebilir. Bu varsayımlar altında olaydan planlanan çıkışa kadar süre yaklaşık 250–500 µs aralığına yayılır; sensörün ve fiziksel çıkışın ayrıca tanımlanmamış gecikmeleri buna dahil değildir. Bu yüzden ağ çevrimi tek başına makinenin tepki süresi değildir.

“1 ns çözünürlük” gerçek cihazda ne anlama gelir?

Beckhoff EL1252, iki kanallı 24 V DC timestamp giriş terminalidir. Üretici 1 ns zaman damgası çözünürlüğü, kanallar arasında 10 ns + giriş gecikmesi biçiminde doğruluk ve 1 µs’den küçük giriş gecikmesi belirtir. Bunlar farklı özelliklerdir: 1 ns çözünürlük, bütün ağın veya sensörden motora tepkinin 1 ns olduğu anlamına gelmez. ^[5]

Zaman damgası, bir olayın ne zaman olduğunu verinin kontrolöre ulaşma anından ayırmaya yarar. EL1252’nin belirtilen latch last edge özelliği de dikkate alınmalıdır; her ara kenarı sınırsız kaydeden bir olay günlüğü gibi kabul edilmez. Enkoder çıkış tipini seçmek, o sinyali okuyacak donanımın zaman çözünürlüğünü ve olay yakalama kapasitesini ayrıca kontrol etme ihtiyacını ortadan kaldırmaz. ^[5]

Milisaniyenin altı mümkün; her makinede aynı sınır yok

Beckhoff, XFC için optimize edilmiş kontrolör, EtherCAT, yazılım ve hızlı I/O bileşimiyle 100 µs altında I/O tepki süreleri tarif eder. Bu, uygun bir sistemin yapabildiğine ilişkin üretici örneğidir; herhangi bir PLC ve herhangi bir EtherCAT terminalinin bu değeri sağlayacağı sözü değildir. Teknik özelliklerdeki rakamın hangi katmana ait olduğu korunmalıdır. ^[4]

Oversampling, bir bus çevrimi içinde cihazın birden fazla örnek alıp bunları birlikte iletmesidir. Örnek sayısını artırır; PLC’nin aynı oranda daha sık yeni bir kapalı çevrim kararı verdiği anlamına gelmez. Örneğin varsayımsal 1 ms çevrimde 10 eşit aralıklı örnek, 100 µs örnek aralığı ve 10 kS/s demektir; hesaplanan kontrol komutu yine 1 ms’de bir güncelleniyor olabilir. PID kontrolünde hangi aralığın kullanıldığı açık olmalıdır. ^[4]

Benzer biçimde bir analog sinyalin ağdan hızlı taşınması, sensörün tepki süresini, analog dönüşümü veya sayısal filtreyi otomatik olarak hızlandırmaz. Kontrol hedefini önce fiziksel süreç için tanımlamak, sonra ağ ve I/O seçimini bu hedefe göre yapmak gerekir.

MainDevice’i baypas eden serbest bir peer-to-peer ağ mı?

Hayır; fakat cihazlar arasında doğrudan veri aktarımı da tamamen yok değildir. Uygun süreç belleği/FMMU eşlemesiyle, veriyi üreten cihaz ağdaki işleme sırasına göre tüketen cihazdan önce geliyorsa aynı çevrimde aktarım kurulabilir. acontis EC-Engineer bu yöntemi ayrı bir uzman ayarı olarak tanımlar. Bu koşulu bütün cihaz çiftlerine genişletmek yanlış olur. ^[3]

Diğer yöntemde master yazılımı alınan girişleri hedef çıkış alanına kopyalar. acontis’in açıkladığı akışta veri bir çevrimde okunur ve sonraki çevrimde yazılır. Böylece MainDevice/SubDevice iletişimindeki veri yolu ve çevrim ilişkisi açıklanmış olur. Her cihazın masterdan bağımsız çerçeve üretip istediği cihaza serbestçe konuştuğu bir ağ anlatılmamalıdır. ^[6]

Yük, topoloji ve yedeklilik performansı nasıl etkiler?

Kontrolör tarafı: ESC’nin hızlı olması, uygulama görevinin gecikmeyeceğini kanıtlamaz. Gerçek zamanlı runtime, ağ sürücüsü ve görev planlaması da zincirin parçalarıdır. acontis’in Windows için ayrıca gerçek zaman desteği tanımlaması bu ayrımı somutlaştırır. Programlama araçları ve çalışma ortamı değerlendirilirken ortalama CPU yüzdesiyle yetinmeyip kontrol işinin en uzun gözlenen süresine bakılmalıdır. ^{[8] [12]}

Veri yükü: Hedef konum, gerçek konum ve kontrol/durum bilgileri için çevrimsel PDO düzeni kullanılır. Parametre erişimi sağlayan SDO aynı işi yapmaz. Gereksiz PDO alanlarını ve yoğun parametre sorgulamasını kontrol etmek yararlıdır; ancak bir SDO’nun çevrimsel görevi nasıl etkilediği masterın zamanlamasına bağlıdır. “SDO varsa mutlaka jitter olur” da “hiçbir etkisi olamaz” da yeterli açıklama değildir. ^{[9] [10]}

Fiziksel düzen: Hat, ağaç veya yıldız yapılabilir; yıldız dallanması için sıradan bir Ethernet switch’i yerine uygun EtherCAT junction gerekir. Topoloji esnekliği, kablo ve cihaz geçiş sürelerinin sıfır olduğu anlamına gelmez. Ağ değiştirildiğinde zamanlama hesabı ve ölçümü yeni düzende tekrarlanmalıdır. ^[7]

Kablo yedekliliği: Son cihazın masterın ikinci portuna bağlandığı halka, destekleyen master yazılımı ve doğru ayarlarla kablo arızasına karşı kullanılabilir. Delta Motion, RMC’de Cable Redundancy seçeneğinin açılmasını ayrıca belirtir. Bu, kontrolör yedekliliği veya her arızada kesintisiz çalışma garantisi değildir. Arıza anındaki davranış ayrı kabul ölçütüdür; sistem sınırları içinde değerlendirilir. ^[7]

Sahada gerçek zamanlı performans nasıl doğrulanır?

Ölçüm noktalarını belirleyin. Fiziksel girişten fiziksel çıkışa tepki mi, iki çıkış arasındaki fark mı, yoksa master görev süresi mi isteniyor? Bunlar için aynı ekran veya aynı zaman damgası yeterli olmayabilir. HMI ekranının yavaş yenilenmesi tek başına EtherCAT’in yavaş olduğunu göstermez. EC-Engineer belgesinde bazı izleme grafiklerinin 250 ms’de bir yenilendiği belirtilir; bu, bus çevrimi değildir. ^[12]

Veri geçerliliği ile zamanlamayı birlikte kaydedin. TwinCAT’te WcState, son çevrimin geçerli iletişim durumunu bildirir; geçersiz iletişimde eski giriş değerleri görünmeye devam edebilir. Değerin ekranda durması yeni örnek geldiğini kanıtlamaz. Working Counter, eksik çerçeve, watchdog ve DC senkronizasyon durumu ayrı bilgileri ortaya koyar. Hata teşhisini yalnız “OP durumunda” gözlemine indirmeyin. ^{[11] [13]}

Bir kabul kaydına çevrim ayarını, ilgili cihaz/firmware ve çalışma modunu, PDO boyutunu, test yükünü, ölçüm süresini, örnek sayısını, en küçük/en büyük süreleri, jitter tanımını ve son teslim zamanı ihlallerini birlikte yazın. Bu, sonucu yeniden incelemeyi mümkün kılan bir mühendislik önerisidir; belirli bir üreticinin evrensel kabul standardı değildir.

Normal üretim yükünü temsil eden koşullarda gözlem yapın; izinli bakım/test düzeni dışında güvenlik devresini devre dışı bırakmayın veya hareketli makinede kablo koparma deneyi yapmayın. Bir veri kaydının hiç hata göstermemesi, yalnız o gözlem aralığı için sonuçtur; bütün olası koşulların matematiksel garantisi değildir. Fiziksel tepki ölçümünde kullanılan prob, tetikleme ve ölçüm cihazının belirsizliği de sonucun parçasıdır.

Sonuç: EtherCAT’in gerçek zamanlı performansı, hızlı çerçeve işleme ve ortak zaman tabanıyla güçlenir. Makinedeki başarının ölçütü ise daha somuttur: geçerli giriş, zamanında biten hesap, vaktinde hazır çıkış verisi ve istenen anda gerçekleşen fiziksel sonuç. Bunlardan birini ölçüp hepsini doğrulanmış saymamak gerekir.