EtherCAT'te master her döngüde tek bir Ethernet çerçevesi gönderir ve hattaki bütün cihazlar bu çerçeveyi paylaşır. Çerçeve bir cihazdan geçerken cihazın EtherCAT slave denetleyicisi (ESC) kendi çıkış verisini okur, giriş verisini aynı çerçeveye yazar ve çerçeveyi durdurmadan iletir; bu işi donanım yapar. Son cihaz çerçeveyi geri çevirir, master da dönen çerçevedeki Working Counter'a bakıp her cihazın payını işleyip işlemediğini anlar. Tezgâhımızda (TI AM572x master, tek slave, 64 bayt süreç verisi, 10 kHz) çerçevenin gönderimden tam dönüşüne kadar geçen süre ortalama 19,2 µs, en fazla 30,9 µs oldu.

Kısaca

  • Bütün hat tek çerçeveyi paylaşır: FMMU sayesinde tek datagram bütün hattın süreç verisini taşır, her cihaz kendi payını çerçeve geçerken donanımda okuyup yazar.
  • Working Counter datagramı işleyen cihazları sayar; tutmayan döngünün verisi taze sayılmamalıdır.
  • Klasik CAN çerçeve başına en fazla 8 bayt, CAN FD 64 bayta kadar taşır ve veri yolunu kimliğe dayalı tahkimle paylaşır; araçtaki dağıtık ECU'lar için hâlâ doğru araçtır.
  • Tezgâhımızda (1 slave, 64 B, 10 kHz) ortalama 19,2 µs, maksimum 30,9 µs, yazılım dahil toplam 25,5 µs ölçtük; gecikmeyi frekanstan çok veri boyutu belirledi.

Bir makine neden tek bir "ne zaman"a ihtiyaç duyar?

Yazının üstündeki 80 saniyelik film şu cümleyle açılıyor: bir makine, "ne zaman" konusunda anlaşması gereken parçalardan oluşur. Robot kolun altı ekseni aynı döngünün komutlarıyla hareket etmezse kolun ucu programlanan yolu izlemez.

Klasik Ethernet tabanlı yaklaşımda her cihaz kendi paketini alıp cevabını gönderir. Paketler anahtarda (switch) kuyruğa girer ve gecikme kuyruğun doluluğuna bağlanır; cihaz başına veri birkaç bayt olsa da her Ethernet çerçevesi en az 64 bayttır. EtherCAT'in cevabı, her döngüde her cihaz için bir yuvası olan tek çerçevedir.

Örnek hesap (ölçüm değil): 30 cihaz var, her biri 4 bayt komut alıp 4 bayt durum döndürüyor; önsöz (preamble) ve çerçeveler arası boşluk sayılmadı. Cihaz başına çerçeveyle master'dan 30 × 64 = 1.920 bayt çıkar. Tek EtherCAT çerçevesi ise 14 + 2 + 10 + 240 + 2 + 4 = 272 bayttır (Ethernet başlığı, EtherCAT başlığı, datagram başlığı, 30 × 8 = 240 bayt veri, Working Counter, FCS) ve cevaplarla birlikte geri döner. Master'ın hattına çıkan bayt yedide birin biraz altına iner. Bu oran gecikmeyi değil, hat verimini anlatır.

Film bu fikri bir fabrikada izliyor: çerçeve kumanda panosundan çıkıp servo sürücüleri, kaporta kaynaklayan robot kolun altı eksenini ve insansı robotun otuz eklemini dolaşıyor, o hattın ürettiği arabada bitiyor. Pano, kol, insansı robot ve araba bizim 3B illüstrasyonlarımız; otuz eklem bir ürün iddiası taşımıyor. Tezgâh sayıları ise gerçek ve bizim ölçümümüz (filmin sayfası).

Tek çerçevenin içinde ne var?

EtherCAT verisini standart bir Ethernet çerçevesine koyar; EtherType alanındaki 0x88A4 çerçeveyi tanıtır. Beckhoff'un ESC veri sayfasına göre çerçevede 14 baytlık Ethernet başlığından sonra 2 baytlık EtherCAT başlığı (uzunluk ve tip), 14–1.498 baytlık datagram alanı ve 4 baytlık FCS gelir. Datagram alanına bir ya da birden çok datagram dizilir; her biri 10 baytlık başlık (komut, adres, uzunluk), 0–1.486 bayt veri ve 2 baytlık Working Counter taşır.

Ayar ve durum erişimi için cihaz adreslemesi kullanılır. Süreç verisi ise mantıksal adreslemeyle taşınır: bütün cihazlar aynı 4 GB'lık mantıksal adres uzayını paylaşır ve her slave'deki FMMU (Fieldbus Memory Management Unit), bu süreç görüntüsünün bir dilimini kendi belleğine, gerekirse bit düzeyinde eşler. Eşlemeyi master başlangıçta kurar. Böylece tek bir LRW (logical read-write) datagramı hattın farklı yerlerindeki ESC'lere aynı geçişte erişir ve master veriyi cihaz cihaz toplamaz.

Geçerken işleme: çerçeve hiçbir cihazda beklemez

ETG'nin tarifiyle her slave, kendisine ait veriyi çerçeve ilerlerken "on the fly" okur ve kendi verisini ekler; çerçeve yalnızca donanımın yayılma gecikmesi kadar gecikir. Beckhoff veri sayfasına göre çerçeve ESC'de depolanmaz, veri bitler geçerken okunup yazılır; gecikmeyi kısaltmak için gönderme FIFO'su bile yoktur. Bu yüzden her slave'de bir ESC bulunur: ASIC, FPGA ya da mikrodenetleyiciye gömülü bir blok. Tezgâhımızdaki TMS320F28388D'de ESC, C2000 mikrodenetleyicinin içinde.

ESC belleğiyle slave'in işlemcisi arasındaki trafiği SyncManager düzenler. Döngüsel süreç verisi (PDO) tamponlu kipte (üç tampon) akar ve okuyan her zaman son tutarlı veriyi alır. Yapılandırma ve teşhis döngü dışında, el sıkışmalı mailbox kipiyle yapılır; CoE bu kanaldan CANopen'ın nesne sözlüğünü, PDO eşlemesini ve SDO'larını taşır. SyncManager tampon değişikliğini yalnızca çerçevenin FCS'si doğruysa kabul eder; bozuk bir çerçeve yarım yazılmış tampon bırakmaz.

Dönüş de donanımdadır. Hat full duplex çalışır. Kapalı bir port dışarıya çerçeve göndermez, çerçeve içeride bir sonraki porta geçer; otomatik kipte bağlantısı olmayan port kapalı sayılır. Son cihazın boştaki portunda çerçeve böylece kendiliğinden geri döner. İki portlu ESC'de çerçeve gidişte işlenir, dönüşte yalnızca iletilir.

Working Counter: master işin yapıldığını nereden bilir?

Her datagram 16 bitlik bir Working Counter (WKC) ile biter. ESC, datagramı başarıyla işlediğinde sayacı donanımda artırır: okumada 1, yazmada 1, okuma-yazmada 3'e kadar (okuma için 1, yazma için 2). Master beklenen değeri önceden hesaplar; iki slave de aynı LRW datagramında okunup yazılıyorsa beklenen değer 3 + 3 = 6'dır, biri payını işleyemezse 3 döner. Sayaç cihaz sayar, bayt saymaz.

/* Master döngüsünün iskeleti (sözde kod) */
for (;;) {
    wait_cycle_tick();                      /* ör. 10 kHz: her 100 µs */
    put_outputs(&frame, app_outputs);       /* tek LRW datagramı */
    send(&frame);
    if (!wait_return(&frame, deadline)) {   /* çerçeve dönmedi */
        lost_frames++;
        keep_last_valid_inputs();
        continue;
    }
    if (frame.wkc != expected_wkc) {        /* bir cihaz payını işlemedi */
        mark_inputs_stale();                /* eski veriyi taze gibi verme */
        if (++wkc_errors >= WKC_LIMIT)      /* eşiği makine belirler */
            enter_safe_state_and_diagnose();
        continue;
    }
    wkc_errors = 0;
    app_update(get_inputs(&frame));         /* yalnızca tutarlı döngü */
}

Araba neden başka bir veri yolu kullanıyor?

Filmde çerçeve arabaya varınca başka bir veri yolu başlıyor: CAN mesaj başına sekiz bayt gönderir, her seferinde tek mesaj; diğerleri sırasını bekler. Karşılaştırma yapısaldır, ölçüm içermez.

Klasik CAN'de (CAN CC) bir çerçeve 0 ile 8 bayt veri taşır. 11 ya da 29 bitlik kimlik (ID) içeriği tanımlar ve önceliği belirler; en küçük değer kazanır. Aynı anda başlayan düğümlerin kimlikleri bit bit karşılaştırılır, kaybedenler o anki çerçevenin alıcısı olur ve kazanan çerçeve bozulmadan devam eder. Alıcılar doğru alımı ACK yuvasına dominant bit yazarak teyit eder. CAN FD veri alanını 64 bayta çıkarır ve veri fazında daha yüksek bit hızına geçebilir; tahkim fazı 1 Mbit/s ile sınırlıdır. CiA'ya göre ikisi birlikte ISO 11898-1:2024'te standarttır; CAN XL veri alanını 2.048 bayta çıkarır.

Bu yapı arabanın ihtiyacına göre kurulmuştur: ECU'lar bağımsız anlarda mesaj üretir, acil mesaj kimliği sayesinde önce geçer, her mesaj bütün düğümlere yayınlanır. CiA, CAN'i binek araçlardaki gömülü kontrol sistemlerinin baskın seri ağı olarak tanımlıyor. İki veri yolu aynı silikonda da buluşur: tezgâhımızdaki TMS320F28388D'de ESC'nin yanında iki CAN modülü ve bir CAN FD (MCAN) modülü var.

EtherCAT Klasik CAN / CAN FD
Kim gönderir Yalnızca master Her düğüm; çakışanlar tahkime girer
Çerçeve başına veri Datagram başına 1.486 bayta kadar 0–8 bayt; CAN FD'de 64 bayta kadar
Teyit WKC: işleyen cihaz sayısı ACK: en az bir alıcı doğru aldı
Tasarım hedefi Bir denetleyicinin döngüyle sürdüğü makine Bağımsız mesaj üreten dağıtık ECU'lar

Hangi veri yolunun nerede doğru olduğunu endüstriyel protokol seçim çerçevemizde tartışıyoruz.

Tezgâhta ne ölçtük?

EtherCAT master satmıyoruz. TI silikonunda hat ayağa kaldırır, zamanlamasını karakterize ederiz; endüstriyel protokoller tarafındaki işimiz budur ve filmdeki sayılar onun tezgâh kaydıdır.

  • Master: TI Sitara AM572x IDK (PRU-ICSS), TI-RTOS; ticari bir Class B EtherCAT master yığını. ETG.1500'e göre Class B "asgari" master sınıfıdır ve dağıtık saat (DC) desteği bu sınıfta koşula bağlıdır; bizim kurulumumuzda DC kullanılmıyor.
  • Slave: TI Delfino TMS320F28388D (entegre ESC), Beckhoff SSC v5.13.
  • Hat ve araçlar: 100 Mb/s full duplex; Code Composer Studio 12.8.1, Blackhawk XDS560v2.
1 slave, 64 B süreç verisi, 10 kHz Değer
Çerçeve, gönderimden tam dönüşe (min / ort / maks) 18,5 / 19,2 / 30,9 µs
Master yazılımı dahil toplam 25,5 µs
Slave senkronizasyon hatası en fazla 1 µs
Paket kaybı %0 (ölçümlerimiz boyunca)

Yalnızca ortalamayı değil, maksimumu da yayınlıyoruz. Kontrol döngüsünde ortalama sizi rahatlatan sayıdır; makinenin sevk edilip edilmeyeceğine maksimum karar verir.

İletim gecikmesi, çerçevenin gönderilmesiyle tamamının geri dönmesi arasındaki süredir; master yazılımını içermez. Toplam, ortalama iletime ortalama master yazılımı süresi eklenerek bulunur ve uygulamanın gördüğü süredir. Fark yazılımın payıdır: burada 25,5 − 19,2 = 6,3 µs; bütün tablolarda 6,1 µs (128 B: 27,3 − 21,2 = 6,1 µs) ile 6,4 µs (1 kHz: 26,1 − 19,7 = 6,4 µs) arasında. Koşullar değiştikçe büyüyen kısım iletimdir, yazılımın payı neredeyse sabittir.

Jitter olarak raporladığımız değer slave senkronizasyon hatasıdır (en fazla 1 µs); min/maks aralığı jitter sayılmaz, gidiş-dönüş süresinin dağılımıdır. Bu değer bir DC sonucu da değildir. Yöntemi ölçüm yöntemi yazımızda, TI tarafındaki çalışmamızı Texas Instruments sayfamızda bulabilirsiniz.

Sayılar hat tasarımcısına ne söylüyor?

Satırlar üç ölçüm tablomuzdan; veri boyutu, tezgâh kaydındaki çift yönlü süreç verisi etiketidir.

Koşul Ort (µs) Maks (µs) Toplam (µs)
1 slave, 64 B, 1 kHz 19,7 28,5 26,1
1 slave, 64 B, 10 kHz 19,2 30,9 25,5
1 slave, 32 B, 10 kHz 18,0 27,7 24,3
1 slave, 128 B, 10 kHz 21,2 32,1 27,3
1 slave, 512 B, 10 kHz 34,1 43,4 40,3
2 slave × 32 B, 10 kHz 19,3 33,3 25,5
2 slave × 64 B, 10 kHz 21,2 35,1 27,4

Frekans gecikmeyi büyütmüyor. 1 kHz'den 10 kHz'e ortalama 19,7 µs'den 19,2 µs'ye iniyor; maksimum 28,5 ile 30,9 µs arasında dolaşıyor, bundan eğilim çıkarmıyoruz. Küçülen şey döngü: 1.000 µs'lik periyot 100 µs'ye iniyor ve uygulamaya kalan zaman daralıyor. Hızın bedeli döngü bütçesinde ödenir.

Gecikmeyi veri boyutu belirliyor. Veri 32 bayttan 512 bayta çıkınca ortalama 18,0 µs'den 34,1 µs'ye, maksimum 27,7 µs'den 43,4 µs'ye çıkıyor. PDO haritasındaki her bayt her döngüde gider gelir; kullanılmayan sinyal haritada kalmamalı.

İkinci cihazın bedeli ortalamada görünmüyor. Toplam veri eşitken ikinci slave ortalamaya 19,3 − 19,2 = 0,1 µs ekliyor; 2 × 64 B ile tek slave'li 128 B ortalamada aynı (21,2 µs). Maksimumda tablo değişiyor: 33,3 µs'ye karşı 30,9 µs, 35,1 µs'ye karşı 32,1 µs. Nedenini bu veriyle ayıramıyoruz; hattı ortalamaya göre boyutlandırmanın riski burada.

1.498 bayt sınırı. Tek çerçevenin datagram alanı en fazla 1.498 bayttır ve başlıklar da buradan yer kaplar. 1 slave × 1024 B ve 2 × 512 B koşullarında çift yönlü veri bu sınırı aştı, iletim iki çerçeveye bölündü ve 10 kHz'de paketler kayboldu; frekansı birinde 6,6 kHz'e, diğerinde 5 kHz'e düşürmek gerekti. PDO haritasını iki yönün toplamıyla hesaplayın ve sınırın altında pay bırakın.

Nerede yanlış gider

  • Ortalamayı tek sayı olarak raporlamak. Aynı koşul (1 slave, 64 B, 10 kHz) iki tablomuzda da var: ortalama ikisinde de 19,2 µs, maksimum birinde 30,9, diğerinde 29,1 µs. Bir serinin maksimumu en kötü durum sınırı değil, o serinin en kötü değeridir.
  • DC kullanmayan yığından DC sayısı istemek. Böyle bir kurulumdan gelen DC senkron rakamı ölçülmüş olamaz.
  • Çerçeve sınırını aşan PDO haritası. Bizim tezgâhta 10 kHz'de paket kaybına ve frekans düşürmeye yol açtı.
  • WKC'ye bakmayan uygulama. Bir cihazın payını işlemediği döngüyü taze veri sanır.
  • Kablolama ve topoloji hataları. Beckhoff ESC'leri MAC adreslerini değerlendirmediği için master ile ilk slave arasına ya da slave'ler arasına yönetilmeyen anahtar konamaz; ofis ağına bağlanan bir ESC yayın fırtınası yaratır. Teşhiste konum adresi yerine istasyon adresi kullanın; döngüler geçici kapandığında konumlar kayar.

Bu yazının söyleyemedikleri

  • Tek ve iki slave ile ölçtük, yüzlerce cihazlı hat ölçmedik. 0,1 µs'lik ortalama bedeli yüz cihaza çarpmak bu veriyle yapılamaz.
  • DC ölçümümüz yok.
  • Standart Ethernet ile karşılaştırmalı ölçümümüz yok; EtherCAT vaka analizimizdeki Ethernet sütunu ölçüm değil, yapısal bir tariftir.
  • Yazılım yolu dahil en kötü durum sayımız yok: 25,5 µs iki ortalamanın toplamıdır.
  • CAN tarafında ölçüm yapmadık; filmde tezgâh sayıları dışında hiçbir şey ölçüm değildir.
  • Başka bir kartta, yığın sürümünde ya da PDO haritasında sayılar değişir.

Sık sorulan sorular

EtherCAT'te "processing on the fly" ne demek?

Çerçevenin cihazlarda durmadan işlenmesi demek: her slave'deki ESC donanımı, bitler içinden geçerken kendi çıkış verisini okur, giriş verisini aynı çerçeveye yazar ve çerçeveyi depolamaz.

Working Counter ne işe yarar?

Her datagramın sonundaki 16 bitlik sayaç, datagramı başarıyla işleyen cihazları sayar. Master dönen değeri beklenenle karşılaştırır; tutmuyorsa o döngünün verisi eksik ya da eskidir ve taze veri gibi kullanılmamalıdır.

EtherCAT neden CAN'in yerini almıyor?

İkisi farklı işler için tasarlandı: EtherCAT, bir denetleyicinin her döngüde bütün cihazlara tek çerçeveyle eriştiği makineler için; CAN ise her düğümün kendi mesajını gönderebildiği ve önceliği kimliğin belirlediği dağıtık ağlar için.

Bu sayılar benim hattım için geçerli mi?

Doğrudan değil. Sayılar tek bir kurulumun karakterizasyonudur (TI AM572x master, ticari Class B yığını, bir ya da iki TMS320F28388D slave, 100 Mb/s); sizin hattınızın cevabı sizin SoC'nizde, PDO haritanızla ve cihaz sayınızla ölçülerek bulunur.

Kaynaklar