Temsili çalışma görseli: oklar ve veri kutuları bir kablolama ya da sabit PDO haritası değildir. Görseldeki çevrim aralığı tüm cihazlar için performans garantisi sayılmaz; normal hattın dönüş yolu aşağıda açıklanmıştır.
EtherCAT nasıl çalışır?
EtherCAT, masterın gönderdiği Ethernet çerçevesinin saha cihazlarından geçerken donanım tarafından işlenmesiyle çalışır. Cihaz, kendisine ayrılmış çıkış verisini alır; giriş verisini aynı geçiş sırasında çerçeveye yerleştirir. Çerçeve mastera döndüğünde gelen veri denetlenir ve kontrol uygulamasına aktarılır. Normal çevrimde her cihaz için ayrı bir istek–cevap paketi oluşturmak gerekmez. [1]
Bu yazı, EtherCAT ana rehberindeki genel tanımı bir adım ileri taşıyarak bir çevrimin içinde ne olduğunu açıklıyor. Kapsam, doğrudan Ethernet çerçeveleriyle çalışan klasik EtherCAT saha ağıdır; EtherCAT G/G10 gibi farklı hız sınıfları ve özel ağ bağlama çözümleri ayrıca değerlendirilmelidir.
Bir çevrimde masterdan sahaya ve tekrar mastera ne gider?
Önce uygulama verisi hazırlanır. PLC programının ürettiği hedefler ve çıkış bitleri, masterın çıkış süreç görüntüsünde tutulur. Gelen girişler için ayrı bir alan vardır. Programın bu alanları hangi görevde ve hangi anda okuduğu/yazdığı kontrolörün zamanlama düzenine bağlıdır; haberleşme çevrimi ile PLC taramasını aynı işlem saymamak gerekir. [3]
Çerçeveyi master oluşturur. Uygun Ethernet arayüzü üzerinden bir veya birkaç datagram içeren çerçeve gönderilir. Standart ağ donanımının kullanılabilmesi, rastgele bir bilgisayar programının gerçek zamanlı master olduğu anlamına gelmez: sürücü, master yazılımı ve görev zamanlaması birlikte çalışmalıdır. Normal segmentte çerçeve başlatma görevi masterdadır; master ve slave arasındaki iletişim rolleri bu ayrımdan doğar. [1]
ESC veriyi geçerken işler. Saha cihazındaki EtherCAT Slave Controller, uygun adres alanını donanımda yakalar. “On-the-fly” ifadesi, çerçevenin tamamı her cihazın uygulama işlemcisine kopyalanıp yeni bir yanıt hazırlanana kadar beklenmemesidir. Bu özellik bir RJ45 portunun görünüşünden anlaşılmaz; cihazın gerçek EtherCAT desteği bulunmalıdır. [1]
Çerçeve geri döner. Normal iki portlu hat düzeninde son açık uçta dönüş yolu oluşur; veri aynı kablonun diğer iletim yönüyle mastera ulaşır. Fiziksel hat, işlev bakımından mantıksal halka gibi davranır. Dönüşte her cihaz ikinci kez yeni ölçüm eklemez; bu yön normal düzende iletme yönüdür. Port yönleri ve dallar EtherCAT topolojisine göre değerlendirilir. [10]
Master sonucu kabul eder veya hatalı işaretler. Çerçeve bütünlüğü, beklenen WKC ve cihaz durumları değerlendirilir. “Paket geldi” ile “uygulamaya geçerli giriş geldi” aynı kontrol değildir. Bir SCADA ekranında sayı görünmesi de o sayının yeni olduğunu tek başına kanıtlamaz. [11]
Ethernet çerçevesi, datagram ve PDO aynı şey değildir
Doğrudan EtherCAT trafiği, Ethernet çerçevesi içinde 0x88A4 EtherType değeriyle tanınır. İçeride EtherCAT başlığı, bir veya daha fazla datagram ve bunların veri alanları bulunur. Datagram, yapılacak erişimin komutunu, adresini ve uzunluğunu taşır; sonunda kendi Working Counter alanı vardır. Bu nedenle tek çerçevedeki iki datagramın beklenen WKC değerleri farklı olabilir. [2]
PDO, uygulamanın düzenli değiş tokuş ettiği süreç verisinin düzenidir: örneğin bir hedef konum veya durum sözcüğü. Datagram ise o veriye nasıl erişileceğini taşıyan haberleşme birimidir. Bir PDO’yu zorunlu olarak tek Ethernet paketi veya tek datagramla eşitlemek yanlıştır. CANopen kökenli nesne sözlüğü ve PDO/SDO kavramlarının CoE’de kullanılması da EtherCAT hattından klasik CAN çerçeveleri geçtiği anlamına gelmez. CoE, her basit EtherCAT cihazında bulunmak zorunda değildir. [3] [5]
Standart Ethernet, belirli bir uygulama istek–cevap düzenini zorunlu tutmaz. Buradaki farkı “Ethernet her zaman her cihaza ayrı soru sorar” diye kurmak yerine, EtherCAT ile geleneksel Ethernet arasındaki farkı veriye erişim yöntemi, cihaz donanımı ve zamanlama üzerinden okumak gerekir. Doğrudan çevrimsel veri değişimi için her slavee IP adresi atamak gerekmez; ayrı servis veya tünelleme işlevlerinin IP kullanması bu mekanizmayı değiştirmez. [1]
Cihaz kendi verisini nasıl bulur? FMMU ve SyncManager
FMMU (Fieldbus Memory Management Unit), datagramdaki mantıksal adres aralığını cihazın yerel belleğindeki ilgili alana eşler. Bu eşleştirme master tarafından yapılandırılır; kabloda üçüncü sırada olmak, verinin çerçevede daima üçüncü sabit kutuda bulunacağı anlamına gelmez. Fiziksel konum, istasyon adresi ve süreç verisi ofseti farklı bilgilerdir. [2]
SyncManager ise ağ tarafı ile cihaz uygulamasının aynı veriye tutarlı biçimde erişmesini düzenler. Süreç verisinde kullanılan tamponlu çalışma, tüketiciye tamamlanmış bir veri grubunu verir; mailbox çalışma biçimi mesaj alışverişi için el sıkışma kullanır. Bu, veri tutarlılığı işidir; bütün sensörleri aynı anda örnekleten saat senkronizasyonu değildir. Geçerken işleme, bozuk çerçevenin çıkışlara koşulsuz uygulanması da değildir: masterın yazdığı SyncManager tampon değişiklikleri geçerli FCS kontrolünden sonra kabul edilir. [2]
Pratik ayrım şudur: FMMU “hangi bayt?”, SyncManager “hangi tamamlanmış veri grubu?”, Distributed Clocks “hangi zaman?” sorusuna karşılık gelir. Gelen baytın ESC tarafından alınması, motorun o anda fiziksel hareketi tamamladığını göstermez. Servo sürücünün kendi kontrol döngüsü ve enkoder geri bildirimi ayrıca değerlendirilir.
Ağ açılırken hangi hazırlık yapılır?
Master, görülen cihazları ve bağlantı düzenini projeyle karşılaştırır; istasyon adreslerini ve erişim alanlarını yapılandırır. ESI XML dosyası, mühendislik yazılımına cihazın özelliklerini ve süreç verisi seçeneklerini tanıtır. Yanlış ürüne ait dosya kullanmak veya uyumsuz revizyonu seçmek, cihazı uygun hale getirmez. Programlama araçları üzerinden görülen ürün kimliği, revizyon ve seçili PDO düzeni gerçek donanımla birlikte kontrol edilmelidir. [6]
Aynı tip iki cihaz yer değiştirirse, yalnız sıra ve ürün tipi kontrolü fiziksel ekipman karışıklığını yakalamayabilir. Desteklenen explicit identification / station alias kontrolü burada işe yarayabilir; fakat her cihazda aynı özellik veya aynı ayar adı bulunmaz. Özellikle çok eksenli sistemde “doğru sürücü tipini gördüm” ile “doğru makine eksenine bağlandım” ayrı doğrulamalardır. [7]
RxPDO, slavein aldığı; TxPDO, slavein gönderdiği veridir. Master açısından RxPDO çıkış, TxPDO giriştir. Sürekli gereken veriler PDO düzenine alınır; uygun cihazlarda SDO ile ihtiyaç üzerine parametre okunur veya yazılır. SDO erişimini her çevrimdeki hedef aktarımının yerine koymamak gerekir. Model kılavuzları üzerinden seçilen arayüzün ve desteklenen çalışma modunun doğrulanması, yalnız seri adına güvenmekten daha anlamlıdır. [3] [4]
| Durum | İşlev ve sınır |
|---|---|
| INIT | Başlangıç; normal süreç verisi alışverişi yoktur. |
| PREOP | Desteklenen mailbox/parametre haberleşmesi mümkündür; normal süreç verisi çalışması başlamamıştır. |
| SAFEOP | Giriş süreç verisi güncellenebilir; normal çıkış işletimi henüz açılmamıştır. |
| OP | Giriş/çıkış süreç verisi işletimi mümkündür; sürücünün çalışma izni ayrıca kontrol edilir. |
Normal ilerleme INIT → PREOP → SAFEOP → OP şeklindedir; BOOT, desteklenen firmware güncellemesi için ayrı durumdur. OP, motorun çalıştığı; SAFEOP ise makinenin sertifikalı güvenli duruşta olduğu anlamına gelmez. Haberleşme durumu, sürücü durumu ve STO fonksiyonu birbirinin yerine kullanılamaz. [8]
Üç cihazı tek datagramla okuyup yazma örneği
Varsayımsal mühendislik örneği: A bir 16 bit dijital giriş cihazı, B bir basınç ölçüm cihazı, C bir servo sürücü olsun. Üçünün de aşağıdaki eşleştirmeyi ve LRW — Logical Read Write komutunu desteklediği varsayılıyor. Bu tablo herhangi bir üreticinin hazır PDO profili veya çalıştırılacak motor komutu değildir.
| Ofset / boyut | Veri ve sahibi | Master yönü |
|---|---|---|
| 0–1 / 2 bayt | A: 16 dijital giriş biti | Giriş / TxPDO |
| 2–3 / 2 bayt | B: basınç, UINT16 | Giriş / TxPDO |
| 4–5 / 2 bayt | C: kontrol sözcüğü | Çıkış / RxPDO |
| 6–9 / 4 bayt | C: hedef konum, INT32 | Çıkış / RxPDO |
| 10–11 / 2 bayt | C: durum sözcüğü | Giriş / TxPDO |
| 12–15 / 4 bayt | C: gerçek konum, INT32 | Giriş / TxPDO |
Örnek mantıksal başlangıç adresi 0x00010000 seçilirse 16 baytlık alan 0x00010000–0x0001000F aralığını kaplar. Tablodaki ofsetler bu alanın başına göredir; PLC mutlak bellek adresi veya CoE nesne indeksi değildir. Master C’ye ait 6 bayt çıkışı hazırlar; A ve B ikişer bayt, C ise 6 bayt giriş verisi döndürür: 6 bayt çıkış + 10 bayt giriş = 16 bayt süreç verisi.
B için ayrıca 1 ham birim = 0,01 bar ölçeği varsayılırsa 625 değeri 6,25 bar olur. Bu özel ölçek, tüm basınç sensörlerine uygulanamaz. B bir 4–20 mA giriş modülü olsaydı, akım aralığına ek olarak o modülün ham sayı ölçeği de bilinmeliydi. Haberleşme, mühendislik birimini kendiliğinden seçmez.
Bir sonraki kontrolde aynı 625 değerini görmek iki farklı anlama gelebilir: basınç gerçekten sabittir veya ölçüm güncellenmiyordur. Bu ikisini ayırmak için mevcutsa cihaz durum biti, örnek sayacı veya zaman damgası kullanılır. Ölçüm doğruluğu ve kalibrasyon ise başka bir sorudur; hatasız ulaşan yanlış ölçekli veri hâlâ yanlış sonuç üretir.
Üç cihaz varsa Working Counter neden 5 olabilir?
WKC’yi doğrudan “bağlı cihaz adedi” diye okumak yanıltır. Artış, datagram komutuna ve gerçekleşen erişime bağlıdır. Yukarıdaki tek LRW datagramında masterın cihazdan veri okuması +1, cihaza yazması +2, aynı cihazda ikisinin gerçekleşmesi +3 katkı verir. Bu +2 kuralı bağımsız bir yazma komutuna genellenmez. [2]
| Cihaz | İşlem | WKC katkısı |
|---|---|---|
| A | Master A’dan giriş okur | +1 |
| B | Master B’den giriş okur | +1 |
| C | Master çıkış yazar, giriş okur | +3 |
| Toplam | Üç cihazın beklenen katkısı | 5 |
Dönen değer 4 ise beklenen işlem toplamı oluşmamıştır. Bundan tek başına “B arızalı” sonucu çıkmaz: A’nın okumasının eksilmesi de aynı sayıyı doğurabilir. Ayrıca ortak datagrama bağlı birden çok cihazın WcState göstergesi birlikte hatalı olabilir. Hata yerini bulmak için cihazın AL durumu ve port/bağlantı bilgileriyle devam edilir. [11]
WKC = 5 de bütün makinenin sağlıklı olduğunu kanıtlamaz. Bu sayaç uygulama mantığının, sensör kalibrasyonunun veya mekanik hareketin doğrulaması değildir. Özellikle çok baytlı erişimde her baytın semantik olarak doğru yorumlandığını gösteren bir kontrol gibi kullanılmamalıdır. Bir hedefin ulaşıp ulaşmadığı, sürücünün hedefi kabul edip etmediği ve eksenin hedefe gidip gitmediği ayrı sorulardır. [2]
Veriler sırayla geçiyorsa cihazlar nasıl eşzamanlı çalışır?
Çerçevenin varış anı ile işlem anını ayırarak. Distributed Clocks (DC) destekleyen cihazlarda yerel saatler ortak referansa göre hizalanır; yayılma gecikmesi ve saat sapması telafi edilir. Ölçüm yakalama veya çıkış güncelleme, uygun yapılandırmada yerel zaman olayına bağlanabilir. Çerçeve cihazlara farklı anlarda ulaşsa da gereken veri belirlenen işleme anından önce hazır bulunmalıdır. [1]
DC desteği kendiliğinden etkin olduğu varsayılamaz. Free Run, SyncManager senkronizasyonu ve DC Sync aynı mod değildir. Gerçek zamanlı performansı değerlendirirken yalnız ağ çevrimini değil, cihazın ölçüm modu ve uygulamanın zamanlamasını da kontrol etmek gerekir. Bu ayrım PID kontrolünde kullanılan geri beslemenin yaşını yorumlarken de önemlidir. [9]
Gerçek donanım örneği — Beckhoff EL1008: Üretici, sekiz kanallı bu dijital giriş terminali için tipik 3 ms giriş filtresi verir; Distributed clocks alanında “–” bulunur. Dolayısıyla EtherCAT bağlantısı bulunması, bu girişin DC ile örneklendiğini göstermez. [12]
Buradan çıkan uygulama sonucu şudur: ağı varsayımsal olarak 1 ms çevrimle okumak, terminalin 3 ms filtre özelliğini ortadan kaldırmaz. Hızlı bir enkoder çıkışını değerlendirmek için yalnız protokol adına bakarak standart dijital giriş seçilmez. Bu ürün örneği, önceki tabloda varsayılan 16 girişli A cihazı değildir.
16 bayt veri, kabloda yalnız 16 bayt mı yer kaplar?
Hayır. Başlıklar ve asgari çerçeve boyu hesaba katılmalıdır. Aşağıdaki hesap VLAN’sız, tek LRW datagramlı, 100 Mbit/s bir çerçeve varsayar; başka çevrimsel veya mailbox datagramı yoktur. EtherCAT/datagram alanlarının boyutları üretici dokümanından alınmıştır. [2]
EtherCAT yükü: 2 bayt EtherCAT başlığı + 10 bayt datagram başlığı + 16 bayt örnek süreç verisi + 2 bayt WKC = 30 bayt.
Ethernet çerçevesi: 30 baytlık yük, 46 bayt asgari yük alanına tamamlanır. 14 bayt Ethernet başlığı + 46 bayt yük/dolgu + 4 bayt FCS = 64 bayt. 8 bayt preamble/SFD ve 12 baytlık süreye karşılık gelen çerçeveler arası boşlukla hat bütçesi 84 bayt-zamanı olur. Boşluk, süreç verisi taşıyan 12 bayt değildir. [1]
84 × 8 / 100.000.000 = 6,72 µs. Bu, tek asgari çerçeve için boşluk dahil iletim zaman bütçesidir. EtherCAT çevrim süresi veya ölçümden harekete toplam tepki süresi değildir.
Bunu üç cihaz için doğrudan üçle çarpmak da doğru ağ modeli değildir: çerçeve her cihazda yeniden bütünüyle üretilmez. Kablo yayılması, ESC geçişleri, frame dönüşü, uygulama görevi, giriş filtresi ve çıkışın güncellenme anı birlikte değerlendirilir. Gecikme süresi ile hat bit hızı bu yüzden ayrı ölçütlerdir. Daha büyük veri haritası veya farklı görev hızları ek çerçeveler gerektirebilir; ağın sınırları yalnız tek telegramın boyuyla belirlenmez.
Çalışma mantığını sahada nasıl doğrularsınız?
Önce projeyi ve donanımı eşleştirin. Bağlı cihaz ve sensörlerin tipi, kimliği, revizyonu, port sırası ve PDO uzunluklarını kaydedin. Rx/Tx yönlerini master bakış açısına çevirin; değerlerin veri tipini, işaretini, bit yerleşimini ve birimini kontrol edin. Otomatik tarama sonucunu fiziksel ekipman doğrulaması yerine koymayın.
Ardından bir çevrimi gözleyin. Masterın teşhis ekranında gönderme/alma durumu, datagramların beklenen/gerçek WKC değerleri, AL durumları ve varsa DC sapması birlikte incelenir. Wireshark’ta ecat görüntüleme filtresi EtherCAT trafiğini ayırır; ecat.cmd, ecat.cnt ve ecat.data alanları komut, sayaç ve veriyi incelemeye yardım eder. [13]
Gönderilen ile döneni karıştırmayın. Masterdan çıkan datagramın başlangıç sayacı ile dönüşte oluşan WKC aynı gözlem değildir. Komut, adres, uzunluk, çerçeve yönü ve yakalama noktasını birlikte değerlendirin. Tek başına ecat.cnt == 0 filtresi genel bir “ağ arızası” filtresi sayılamaz; yakalamada giden çerçeveler de olabilir.
Çalışan makineye rastgele Ethernet switch ekleyerek trafik yakalamaya çalışmayın. Klasik EtherCAT dallanması için uygun EtherCAT junction kullanılır; kayıt için masterın desteklediği izleme olanağı veya uygun TAP düzeni seçilir. Kablo tipi, portlar arası mesafe ve konnektör yönü cihaz kılavuzuna göre değerlendirilir. Normal veri dönüş yolunun bulunması, tek başına yapılandırılmış kablo yedekliliği demek değildir. [10]
| Gözlem | Sonraki kontrol |
|---|---|
| Bağlantı LED’i var, cihaz OP olmuyor | AL durum/hata kodu, doğru ESI/revizyon, seçili PDO uzunluğu ve gerekli başlangıç parametreleri. |
| Birden çok cihazda WcState hatalı | Ortak datagramı belirleyin; cihaz durumlarını ayrı okuyun. Hepsinin fiziksel olarak arızalı olduğu sonucunu çıkarmayın. |
| WKC doğru, değer anlamsız | Ofset, veri tipi, işaret, birim ve ölçek. Haberleşme kontrolü yanlış eşleştirmeyi her durumda yakalayamaz. |
| Veri aralıklı kayboluyor | Çerçeve kaybı, port hata sayaçları, kablo/konnektör ve besleme sürekliliği. |
| Komut var, hareket yok | Sürücü durumu, çalışma modu, interlock, güç katı ve bağımsız emniyet izinleri. OP tek başına hareket izni değildir. |
Kablo veya cihaz değiştirmeden önce besleme koşullarını ve mevcut teşhis kayıtlarını da koruyun. Yukarıdaki satırlar teşhis yönlendirmesidir; yalnız belirtiye bakarak parça arızası kesinleştirmez. [11]
Sonuç: doğru bayt, geçerli veri ve doğru zaman
EtherCAT’in çalışma mantığını üç kontrolle toparlayabilirsiniz: Doğru cihazın doğru alanına mı erişildi? Dönen veri bu çevrim için geçerli mi? Uygulama o veriyi gereken zamanda mı kullandı? FMMU/PDO haritası ilk soruyu, datagram ve cihaz teşhisi ikinciyi, DC ile görev/ölçüm zamanlaması üçüncüyü değerlendirmeye yardım eder.
Devreye alma kaydına topoloji, cihaz kimlikleri, ESI/revizyon, PDO haritası, çevrim zamanı ve beklenen WKC’yi eklemek yararlı bir kabul kontrolüdür. Kayıt sisteminde yalnız sayıyı değil mümkünse geçerlilik ve zaman bilgisini de saklayın. Ağ üzerindeki yazma/force işlemleri hareket doğurabilir; testleri yetkili personelle