'3.8µs döngü süresi' tek başına bir pazarlama cümlesidir; onu mühendislik verisine dönüştüren şey ölçüm metodolojisidir. Bu yazıda, NXP i.MX8M Plus üzerinde IgH EtherCAT Master ile döngü süresini 8µs'den 3.8µs'ye, dağıtılmış saat (DC) senkron hatasını ±5µs'den 100ns'nin altına indirirken kullandığımız ölçüm ve raporlama disiplinini anlatıyoruz: neden ortalama gecikme raporlamadığımızı, 'kaçırılan döngü'yü nasıl tanımladığımızı ve yazılım timestamp'ini neden tek başına kanıt saymadığımızı. Amaç, EtherCAT hareket kontrolü vaka analizimizde yayınlanan sayıların hangi düzenekle üretildiğini, aynı ölçümü kendi sisteminizde tekrarlayabileceğiniz kadar açık biçimde ortaya koymak.
Ortalama Gecikme Neden Yanıltır?
Bir kontrol döngüsü ortalamada değil, en kötü anında kırılır. 1kHz'lik bir servo döngüsünde ortalama gecikme 4µs olabilir; ama saatte bir kez 500µs'lik bir sapma yaşanıyorsa, çok eksenli enterpolasyon hattı tam o anda pozisyon hatası üretir. Mekanik sonuç — tork sıçraması, izleme hatası, ürün yüzeyinde iz — ortalamaya değil o tek olaya bağlıdır. Üstelik ortalama bu sırada hâlâ mükemmel görünür: bir saatlik pencerede 3.6 milyon döngü içindeki tek bir 500µs'lik sapma, ortalamayı yalnızca ~0.14ns oynatır. Aritmetik, kuyruğu görünmez kılmak için çalışır.
Linux tabanlı sistemlerde gecikme dağılımı ağır kuyrukludur. Cache ve TLB miss'leri, RCU callback'leri, softirq yoğunlaşmaları, bellek bandı çekişmesi ve bazı platformlarda firmware kaynaklı kesintiler; bunların hiçbiri ortalamayı kayda değer biçimde oynatmaz, hepsi dağılımın kuyruğunu şişirir. Ortalama, tam olarak görmeniz gereken olayları istatistiksel olarak silen bir özetleyicidir.
Raporlama sıralamamız bu yüzden şöyledir:
- P50 (medyan): sistemin tipik davranışı — konfor verisidir, karar verisi değildir.
- P99 / P99.9: kuyruğun şekli — mühendislik kararları burada verilir.
- Gözlenen worst-case + ölçüm süresi + yük profili: raporun güvenilirlik sınırı. 'Şu kadar saat, tam yük altında gözlenen maksimum' bilgisi olmadan worst-case iddiası eksiktir.
Yayınladığımız değerler de bu disipline tabidir: 3.8µs döngü süresi ve <4µs P99 jitter, ortalama değil dağılım verisidir.
Kaçırılan Döngü: Önce Tanım, Sonra Sayı
'Hiç döngü kaçırmıyoruz' cümlesi, kaçırılan döngünün tanımı verilmeden denetlenemez. Kullandığımız tanım iki koşulludur; ikisinden biri gerçekleştiğinde döngü kaçırılmış sayılır ve sayaca işlenir:
- Overrun: çıkış çerçevesi, bir sonraki döngü periyodu başlamadan hatta basılamamışsa.
- Veri bütünlüğü ihlali: bir önceki döngünün process data'sı, yeni döngünün hesaplaması başlamadan işlenememişse.
Bu tanımın iki pratik sonucu var. Birincisi, eşik döngü periyoduna bağlıdır: 1ms periyotlu bir hatta 990µs'lik bir gecikme 'yavaş bir döngü' değil, fiilen kaçırılmış bir döngüdür; çünkü bir sonraki döngünün bütçesini yemiştir. İkincisi, tek bir kaçırma bile rapora girer; yüzdelik istatistiğin arkasına saklanmaz. Servo kontrolde kaçırılan döngü degrade bir çalışma modu değil, hata durumudur — sürücüler bir önceki komutla yola devam eder ve hata mekanik olarak birikir.
Yayınladığımız operasyonel metrik buna göre okunmalıdır: tam yük profili altında saatte 0 kaçırılan döngü.
Ölçüm Düzeneği: Test Edilen Sistem Tek Tanık Olamaz
Yazılım timestamp'i — clock_gettime çağrısı, ARM generic timer okuması — test edilen sistemin içinde alınır: aynı zamanlayıcı, aynı kesme altyapısı, aynı bellek hiyerarşisi. Sistem geciktiğinde ölçüm de onunla birlikte gecikebilir ve tam da yakalamak istediğiniz olayı maskeleyebilir. Bu yüzden iki bağımsız ölçüm yolu kullanıyor ve sonuçları birbirine karşı doğruluyoruz.
Bant içi yol — donanım timestamp. Her döngüde ARM cycle counter'dan (CNTVCT) timestamp alınır; MAC seviyesinde donanım timestamping destekleniyorsa çerçevenin hatta çıkış anı da kaydedilir. Örnekler, gerçek zamanlı yolu bozmamak için önceden ayrılmış bir ring buffer'a yazılır; histogram ve yüzdelik hesabı ölçüm bittikten sonra çevrimdışı yapılır. Ölçüm kodunun kendisi kritik yola yük bindirmemelidir — timestamp alma maliyeti onlarca nanosaniye mertebesinde tutulur.
Bant dışı yol — osiloskop. Master, her döngü başlangıcında bir GPIO pinini toggle eder. Osiloskop bu pini ve Ethernet TX hattını birlikte izler; persistence modunda periyot dağılımı doğrudan ekranda birikir, infinite persistence ile saatler içindeki en geniş sapma görünür kalır. Bu yol, test edilen sistemin yazılımından tamamen bağımsızdır: kernel ne yaşarsa yaşasın, hattaki elektriksel gerçek osiloskoptadır.
Çapraz doğrulama kuralı: yazılım histogramı ile osiloskop dağılımı örtüşmek zorundadır. Örtüşmüyorsa yayınlanacak olan sayı değil, düzeneğin kendisi sorgulanır.
Yük profili: boşta sistemin jitter'ı bilgi taşımaz. Ölçüm; CPU, bellek bandı ve ağ üzerinde eşzamanlı stres (stress-ng ve harici trafik üreteci) altında, saniyeler değil saatler mertebesinde koşturulur. Kuyruk olayları nadirdir; kısa ölçüm pencereleri onları istatistiksel olarak göremez.
Burada sık yapılan bir hata, cyclictest çıktısını EtherCAT determinizm kanıtı olarak sunmaktır. cyclictest değerli bir araçtır; ama ölçtüğü şey zamanlayıcının uyandırma gecikmesidir — çerçevenin hatta basılması, sürücü yolu, DMA ve PHY gecikmesi bu ölçümün dışında kalır. Bizim ölçtüğümüz büyüklük döngünün kendisidir: master iş parçacığının tetiklenmesinden çerçevenin fiziksel hatta görünmesine kadar geçen uçtan uca süre. Bu ikisi arasındaki fark, kâğıt üzerinde deterministik görünen ama sahada döngü kaçıran sistemlerin en yaygın açıklamasıdır.
Mimari: IgH Master + PREEMPT_RT + Çekirdek İzolasyonu
Genel bir mühendislik gerçeği olarak PREEMPT_RT, maksimum zamanlama gecikmesini tipik olarak onlarca mikrosaniye bandına çeker; ancak mikrosaniye sınıfı determinizm için tek başına yeterli değildir. Kullandığımız yapı üç katmandan oluşur:
1. IgH EtherCAT Master + polling-mode sürücü. EtherCAT'e ayrılan ağ arabirimi, genel amaçlı ağ yığınından ve kesme birleştirme (interrupt coalescing) mekanizmasından çıkarılır; çerçeve gönderimi ve alımı master döngüsünün kendi bağlamında, polling ile yürür. Kesme birleştirmenin eklediği 3–8µs'lik değişkenlik bu adımda ortadan kalkar — döngü süresinin 8µs'den 3.8µs'ye inmesindeki ana katkı budur.
2. PREEMPT_RT + SCHED_FIFO. Master iş parçacığı SCHED_FIFO 99 önceliğinde koşar; threaded IRQ modeli sayesinde kesme işleyicileri de zamanlanabilir birer iş parçacığıdır ve master'ın altında önceliklendirilir.
3. isolcpus + IRQ affinity. Dört Cortex-A53 çekirdeğinden biri yalnızca master'a ayrılır; kernel housekeeping, RCU callback'leri ve diğer tüm IRQ'lar kalan üç çekirdeğe sabitlenir:
# Kernel komut satırı — çekirdek 3 yalnızca EtherCAT master için
isolcpus=3 nohz_full=3 rcu_nocbs=3 irqaffinity=0-2
# Master iş parçacığı: adanmış çekirdek + RT önceliği
chrt -f 99 taskset -c 3 ./ecat_master_app
# Doğrulama: izole çekirdekte master dışında ne koşuyor?
ps -eLo pid,psr,rtprio,comm | awk '$2 == 3'
Dağıtılmış saat (DC) tarafında kritik adım başlangıç kalibrasyonudur: referans slave seçimi ile ofset ve drift kompanzasyonu boot sekansına eklenir. Bu adım atlandığında slave saatleri ±5µs bandında kayar; kalibrasyonla senkron hatası 100ns'nin altına iner ve iki slave'in SYNC0 çıkışları arasındaki fark osiloskopta doğrudan izlenerek doğrulanır. Çok eksenli enterpolasyonda bu fark, doğrudan pozisyon hassasiyetine yansır.
Son katkı PDO haritalarının sadeleştirilmesidir: kullanılmayan nesnelerin haritadan çıkarılması çerçeveyi kısaltır — küçük ama her ölçümde tekrarlanabilir bir kazanım.
Sonuçlar
Aşağıdaki tablo, endüstriyel protokoller yeteneği sayfasında yayınlanan laboratuvar metrikleriyle birebir aynıdır; ölçüm bağlamının tamamı vaka analizinde yer alır.
| Metrik | Önce | Sonra | Ölçüm yöntemi |
|---|---|---|---|
| Döngü süresi | 8µs | 3.8µs | Donanım timestamp + osiloskop |
| Döngü jitteri (P99) | kontrol edilemiyor | <4µs | GPIO toggle + persistence modu |
| DC senkron hatası | ±5µs | <100ns | SYNC0 çıkışları, osiloskop |
| Çerçeve gecikmesi | ~1ms (TCP/IP) | <4µs | Hat üzeri timestamp |
| Kaçırılan döngü | tanımsız | 0 / saat | Overrun sayacı, tam yük |
Tablo okunurken üç büyüklüğün birbirinden ayrı tutulması gerekir. Döngü süresi, jitter ve senkron hatası aynı şey değildir: ilki bir döngünün ne kadar sürdüğünü, ikincisi bu sürenin döngüden döngüye ne kadar oynadığını, üçüncüsü ise farklı slave'lerin saatlerinin birbirine göre kaymasını anlatır. Üçü farklı düzeneklerle ölçülür ve biri diğerinin yerine kanıt olarak kullanılamaz — 3.8µs'lik bir döngü süresi, tek başına senkron hakkında hiçbir şey söylemez.
Tablodaki 'Önce' sütunu da bir ölçümdür: iyileştirme iddiası, başlangıç durumunun aynı düzenekle ölçülmüş olmasını gerektirir. Referans ölçümü olmayan bir 'şu kadar kat hızlandı' cümlesi doğrulanamaz.
Raporlama Şablonu: Güvenilir Bir Determinizm Raporunun Alanları
Bir gecikme veya determinizm raporu şu alanları içermiyorsa, sayının kendisi değerlendirilemez:
- Donanım ve kernel: SoC, çekirdek sayısı, kernel sürümü + RT yaması, ilgili boot parametreleri
- Yük profili: ölçüm sırasında CPU, bellek ve ağ üzerinde ne koşuyordu
- Süre ve örnek sayısı: ölçüm penceresi ve toplam döngü adedi
- Dağılım: P50 / P99 / P99.9 / gözlenen maksimum — yalnızca biri değil, hepsi
- Yöntem: timestamp kaynağı ve bağımsız doğrulama (osiloskop) olup olmadığı
- Kaçırılan döngü: tanımı ve sayısı
Bu şablon tedarikçi raporlarını okurken de işe yarar: hangi alan boşsa, sorulacak ilk soru oradadır.
Kendi Sisteminize Uygularken
Determinizm bütçesi platforma, döngü frekansına ve eksen sayısına göre değişir; 1kHz'lik bir I/O hattı ile 8kHz'lik çok eksenli bir servo hattının bütçeleri aynı değildir. Kendi döngü süresi ve gecikme bütçenizi kabaca çıkarmak için gerçek zamanlı sistem hesaplayıcımızı kullanabilirsiniz. Mevcut bir EtherCAT hattında kernel yapılandırmasını, IRQ topolojisini ve master mimarisini ölçüm düzeneğiyle birlikte gözden geçirmek isterseniz, mimari denetim tam olarak bu tür bir çalışma için kurgulanmıştır. Yöntemin uçtan uca uygulanmış hâli — problem, kök neden, müdahale ve ölçüm — EtherCAT hareket kontrolü vaka analizinde adım adım anlatılıyor.