Bunu kabul edelim. İletişim, bir AGV veya AMR projesinde küçümsenmeye çok müsaittir. Genellikle araç hareket etmeye başladığında ve birkaç eksen, kodlayıcı, fren, sensör ve kontrolör birlikte çalışmak zorunda kaldığında önem kazanır.
Basit bir taşıma AGV'si için iletişim yükü düşük olabilir. Sistem çift yönlendirme, dört tekerlekli yönlendirme, kaldırma veya diğer koordineli hareketlere geçtiğinde, tepki süresi ve senkronizasyon çok daha önemli hale gelmeye başlar.
CANopen, EtherCAT ve Modbus endüstriyel otomasyonda yaygın seçeneklerdir, ancak bir AGV veya AMR içinde çok farklı işlere uyarlar. Bu makaleyi okuyun, bu üç iletişim protokolünü tek tek ayrıntılı olarak inceleyelim ve AGV robotunuz için en uygun olanı seçmenize yardımcı olalım.

CANopen, EtherCAT ve Modbus'a Genel Bakış
İşte AGV ve AMR uygulamaları için daha pratik bir karşılaştırma.
| Öğe | CANopen | EtherCAT | Modbus |
| Tipik Fiziksel Katman | CAN, genellikle ISO 11898-2 | Yaygın olarak kullanılan 100BASE-TX Ethernet | RTU için yaygın olarak kullanılan RS-485; Modbus TCP için Ethernet/TCP/IP |
| Tipik Veri Hızı | CANopen CC için 1 Mbit/sn'ye kadar | 100 Mbit/sn | Uygulamaya bağlıdır; RTU genellikle seri baud hızlarını kullanırken Modbus TCP Ethernet hızını takip eder |
| Tipik Ağ Topolojisi | Kısa uçlarla doğrusal veri yolu | Hat, ağaç, yıldız ve dal topolojileri | RTU için çoklu düşen veri yolu; TCP için standart Ethernet topolojisi |
| Gerçek Zamanlı Davranış | Birçok standart hareket kontrol uygulaması için yeterince deterministik | Yüksek derecede deterministik ve hızlı döngüsel kontrol için tasarlanmıştır | Sıkı senkronize hareketler için genellikle daha az deterministiktir |
| Senkronizasyon Yöntemi | CANopen SYNC nesnesi senkron PDO iletişimini koordine edebilir | Dağıtılmış Saatler ağ genelinde 1 μsn'nin altında senkronizasyon sağlar | Yerleşik bir dağıtılmış saat mekanizması yoktur |
| Hareket Profili Desteği | Sürücüler ve hareket kontrolü için yaygın olarak kullanılan CiA 402 | CiA 402 dahil CANopen uygulama profillerini destekler | Genellikle üreticiye özgü kayıt eşleştirmesine dayanır |
| Çok Eksenli Koordinasyon | Birçok standart çok eksenli AGV sistemi için uygundur | Sıkı senkronize çok eksenli hareket için çok güçlüdür | Daha basit veya zaman açısından daha az kritik kontrol için daha uygundur |
| Daha Fazla Eksenle Ölçeklenebilirlik | Eksen sayısı arttıkça CAN bant genişliği ve PDO veri yolu yükü kontrol edilmelidir | Yüksek bant genişliği ve verimli çerçeve işleme daha fazla eksen sayısına uygundur | Daha fazla cihaz veya kayıt sorgulandıkça tepki süresi artabilir |
| Tanılama | Nesne sözlüğü, EMCY, kalp atışı, sürücü durumu | Cihaz durumu, çalışma sayacı, bağlantı ve işlem verisi tanılama | İstisna kodları, kayıt/durum verileri ve üreticiye özgü tanılama |
| Entegrasyon Çabası | Orta; olgun ekosistem ve geniş cihaz desteği | Genellikle daha yüksektir, özellikle senkronize hareket sistemleri için | Temel kayıt tabanlı iletişim için genellikle basittir |
| Tipik AGV / AMR Kullanımı | Sürüş motorları, yönlendirme motorları, servo eksenler | Çoklu yönlendirme, yüksek dinamikli AMR'ler, koordineli çok eksenli sistemler | Sensörler, G/Ç, şarj cihazları, kaldırma üniteleri, PLC'ler ve yardımcı cihazlar |
| En Uygun Kullanım | Standart AGV/AMR hareket kontrolü | Yüksek performanslı senkronize hareket | Basit kontrol ve zaman açısından kritik olmayan iletişim |
AGV ve AMR Hareket Kontrolü için CANopen
CANopen, mobil robot sürüş sistemlerinde halihazırda yaygındır.
Kontrolöre, hız komutlarını, konum verilerini, akım değerlerini, durum bilgilerini ve arızaları servo sürücüyle paylaşmak için standartlaştırılmış bir yol sunar.
Kontrolörün iki sürüş motoruna hız komutu göndermesi gerekirken aynı zamanda gerçek hız, akım, kodlayıcı konumu, sürücü durumu ve arıza bilgilerini alması gerekebilir. CANopen, aşırı karmaşık bir ağ gerektirmeden bu tür bir iletişimi iyi yönetir.
CANopen ayrıca PDO ve SDO gibi standartlaştırılmış iletişim nesnelerini kullanır.
PDO'lar normalde hız komutları, tork komutları, konum geri bildirimi veya durum bilgileri gibi çalışma sırasında hızlı hareket etmesi gereken veriler için kullanılır. SDO'lar daha yaygın olarak parametre ayarları ve yapılandırma için kullanılır.
Servo sistemleri için CiA 402 özellikle önemlidir çünkü standartlaştırılmış bir sürücü ve hareket kontrol profili tanımlar. Bu, her komutu sıfırdan oluşturmak yerine uyumlu AGV servo sürücülerini bir kontrolör mimarisine entegre etmeyi kolaylaştırır.
Bu nedenle CANopen birçok durum için güçlü bir seçenektir:
-
Diferansiyel sürüşlü AGV'ler
-
Tek direksiyon tekerlekli AGV'ler
-
Çift yönlendirmeli AGV'ler
-
Forklift AGV'leri
-
Düşük voltajlı depo AMR'leri
-
Orta hızlarda çalışan ağır hizmet AGV'leri
Mevcut en hızlı endüstriyel ağ değildir. Elbette bu bazı projelerde önemlidir. Ancak birçok AGV'nin gerçekten çok sayıda senkronize eksen arasında son derece kısa iletişim döngülerine ihtiyacı yoktur.
Bu sistemler için CANopen; performans, maliyet, kablolama ve geliştirme çabası arasında çok iyi bir denge sunabilir. CANopen ve CAN veri yolu, sağlamlıkları ve nispeten düşük kablolama karmaşıklıkları nedeniyle AGV servo sürücü uygulamalarında da yaygın olarak kullanılır.
Daha Yüksek Performanslı AGV ve AMR Sistemleri için EtherCAT
Zamanlama ve senkronizasyon daha önemli hale geldiğinde EtherCAT daha cazip hale gelir.
CANopen'in aksine EtherCAT, Ethernet teknolojisine dayanır ve hızlı, deterministik endüstriyel iletişim için tasarlanmıştır. Özellikle birkaç servo eksenin çok küçük zamanlama farklarıyla birlikte çalışması gerektiğinde yararlıdır.
Dört tekerlekten yönlendirmeli bir AGV düşünün.
Aracın dört yönlendirme motoru ve dört çekiş motoru olabilir. Dönüş sırasında her yönlendirme ekseni doğru açıya ulaşırken her AGV çekiş tekerleği gerekli hızı takip etmelidir. Bu eksenler iyi koordine edilmezse araçta tekerlek sürtünmesi, yönlendirme direnci, gereksiz motor akımı veya dengesiz hareket görülebilir.
İşte EtherCAT'in avantajlı olduğu nokta burasıdır.
Dağıtılmış saat mekanizması, cihazlar arasında çok hassas senkronizasyonu destekleyebilir. Denetleyici, öngörülebilir iletişim zamanlamasıyla birden fazla ekseni yönetebilir, bu da aşağıdakiler için yararlıdır:
-
Dört tekerlekten yönlendirmeli AGV'ler
-
Çok yönlü mobil robotlar
-
Yüksek hızlı AMR'ler
-
Çok eksenli kaldırma ve sürüş sistemleri
-
Sıkı bir şekilde koordine edilmiş hareket gerektiren robotlar
-
Birden fazla servo eksene sahip mobil manipülatörler
EtherCAT, daha hızlı güncelleme oranlarının ve deterministik zamanlamanın gerektiği yüksek performanslı AMR mimarilerinde giderek daha fazla kullanılmaktadır.
Ancak EtherCAT'in de bir maliyeti vardır.
Denetleyicinin EtherCAT'i desteklemesi gerekir. Servo sürücülerin de desteklemesi gerekir. Yapılandırma ve devreye alma süreci de temel bir CANopen ağından daha karmaşık olabilir.
İki çekiş motoruna sahip yavaş hareket eden bir depo AGV'si için EtherCAT, uygulamanın aslında ihtiyaç duyduğundan daha fazla kapasite sunabilir.
Bu durum EtherCAT'i daha kötü yapmaz. Sadece iletişim performansının, yalnızca bir protokolün kağıt üzerinde daha gelişmiş görünmesi nedeniyle seçilmek yerine robot mimarisiyle uyumlu olması gerektiği anlamına gelir.
Modbus'un AGV ve AMR Sistemlerindeki Yeri
Modbus, en yaygın kabul gören endüstriyel haberleşme protokollerinden biridir. Basit, olgun ve birçok cihaz tarafından desteklenmektedir.
Ancak AGV ve AMR'lerdeki rolü genellikle CANopen veya EtherCAT'ten farklıdır.
Modbus RTU genellikle RS485 üzerinden çalışırken Modbus TCP Ethernet üzerinden çalışır. Her ikisi de durum değerleri, parametreler, komutlar ve diğer nispeten basit verilerin iletilmesi için kullanışlıdır.
Örneğin Modbus şunlarla birlikte kullanılabilir:
-
PLC'ler
-
Giriş/çıkış modülleri
-
Batarya yönetim arayüzleri
-
Şarj cihazları
-
Sensörler
-
Yardımcı eyleyiciler
-
Kaldırma ekipmanları
-
İzleme cihazları
Bazı sistemlerde servo sürücülerle birlikte de kullanılabilir. Örneğin HKT ROBOT servo ve hareket ürünleri, yapılandırmaya bağlı olarak CANopen, EtherCAT ve Modbus (RS485) dahil olmak üzere çeşitli haberleşme seçeneklerini destekler.
Bununla birlikte Modbus, birkaç servo eksenin sıkı gerçek zamanlı senkronizasyon gerektirdiği durumlarda genellikle daha az uygundur.
Haberleşme İhtiyaçları AGV Mimarisiyle Değişir
Sürüş mimarisi protokol seçimini büyük ölçüde etkiler.
İki tekerlekli diferansiyel AGV nispeten basittir. Her bir sürüş motorunun hız veya tork kontrolüne ihtiyacı vardır ve kontrolcü aracı yönlendirmek için sol ve sağ tekerlek hızlarını ayarlar.
Bu tür bir sistem için CANopen genellikle yeterlidir.
Tek direksiyonlu bir AGV, kontrol edilen bir eksen daha ekler. Sürüş motoru araç hızını kontrol ederken direksiyon motoru konum kontrolü gerektirir. CANopen çoğu durumda hala iyi bir uyum sağlar.
Şimdi birkaç direksiyon daha ekleyin.
Dört tekerlekli bir direksiyon platformu, birden fazla servo ekseni arasında koordineli direksiyon açısı, tekerlek hızı, enkoder geri bildirimi ve konum güncellemeleri gerektirebilir. Bu noktada ağ senkronizasyonu çok daha önemli hale gelir.
Genel bir kılavuz şuna benzer:
| AGV / AMR Mimarisi | Haberleşme | Ana Neden |
| İki tekerlekli diferansiyel AGV | CANopen | Makul eksen sayısı, güvenilir servo kontrolü |
| Tek direksiyonlu AGV | CANopen | Sürüş + direksiyon eksenleri kolayca yönetilebilir |
| Çift direksiyonlu AGV | CANopen / EtherCAT | Senkronizasyon ve güncelleme hızına bağlıdır |
| Dört direksiyonlu AGV | EtherCAT / CANopen | Birden fazla direksiyon ve sürüş ekseni koordinasyona ihtiyaç duyar |
| Yüksek dinamikli AMR | EtherCAT | Daha hızlı güncellemeler ve daha sıkı senkronizasyon |
| Ağır hizmet, düşük hızlı AGV | CANopen | Yüksek bant genişliği genellikle gerekli değildir |
| Kaldırma / döndürme modülü | CANopen / EtherCAT / Modbus | Hareket karmaşıklığına bağlıdır |
| Sensörler, G/Ç ve yardımcı sistemler | Modbus | Basit veri değişimi genellikle yeterlidir |
Bu bir tasarım kılavuzudur, kesin bir kural değildir. Ağ sabitlenmeden önce kontrolcü desteği, servo sürücü yeteneği, yazılım platformu, güvenlik işlevleri ve gelecekteki genişletme seçenekleri kontrol edilmelidir.
Hız, Önemli Olan Tek Fark Değildir
Protokol karşılaştırmaları genellikle haberleşme hızına çok fazla odaklanır.
Bu durum, mühendislik kararının büyük bir kısmını gözden kaçırır.
Bir AGV tasarımcısı için entegrasyon çabası da en az onun kadar önemli olabilir.
Mevcut araç kontrolcüsü yalnızca CANopen'ı destekliyorsa, hızlı bir EtherCAT ağının pek bir faydası olmaz. Aynı şekilde, CAN konnektörüne sahip bir servo sürücü seçmek, onun otomatik olarak CANopen'ı desteklediği anlamına gelmez.
Fiziksel arayüz ile haberleşme protokolü aynı şey değildir.
CAN tabanlı bir servo sürücü CANopen, J1939 veya tescilli bir CAN protokolünü kullanabilir. Araç kontrolcüsü CANopen bekliyorsa, servo sürücü aynı protokolü ve nesne yapısını desteklemelidir.
Bu, protokol uyumluluğunun yalnızca konnektör tipinden değil, gerçek kontrolcü ve servo sürücü belgelerinden doğrulanması gerektiğinin nedenlerinden biridir.
Aynı durum Modbus için de geçerlidir.
RS485, fiziksel haberleşme katmanını tanımlar. Üzerinde hangi haberleşme protokolünün çalıştığını tek başına söylemez.
Bu tür küçük ayrıntılar, daha sonra devreye alma süresinden büyük ölçüde tasarruf sağlayabilir.
Protokol Seçimine Tüm Tahrik Sistemi Göz Önünde Bulundurularak Başlanmalıdır
Gerçekte iletişim, yalnızca servo sürücüye ait bir özellik değildir; tüm araç mimarisini ilgilendirir.
agv motoru, servo sürücü, enkoder, kontrolör, redüktör ve tahrik tekerleği birlikte çalışır.
Örneğin bir AGV, direksiyon konumu bilgisini korumak için yönlendirme ekseninde mutlak enkoder kullanabilir. Servo sürücü bu enkoderi desteklemeli, iletişim ağı da kontrolörün yönlendirme eksenine doğru şekilde komut göndermesine ve onu izlemesine olanak tanımalıdır.
Aynı durum AGV diferansiyel tahrik üniteleri için de geçerlidir.
Motor torku ve redüktör oranı mekanik çıkışı belirler; ancak iki tekerleğin uyumlu çalışması için kontrolörün yine de güvenilir hız geri bildirimi alması ve komutları uygulayabilmesi gerekir.
HKT ROBOT'ta, yalnızca yük kapasitesine göre bir tahrik bileşeni seçmek yerine genellikle uygulamanın tamamına bakarız. Araç ağırlığı, faydalı yük, hız, tekerlek çapı, dişli oranı, enkoder, fren, montaj alanı ve kontrol gereksinimlerinin tümü nihai tahrik sistemi yapılandırmasını etkiler.
Sonuç
CANopen, EtherCAT ve Modbus'un her birinin AGV ve AMR sistemlerinde yeri vardır, ancak farklı sorunları çözerler.
CANopen, birçok mobil robot servo sistemi için güçlü bir denge sunar. EtherCAT, senkronizasyonun ve deterministik iletişimin daha önemli olduğu zorlu çok eksenli hareketler için daha uygundur. Modbus, daha basit iletişim ve yardımcı cihazlar için kullanışlı olmaya devam eder.
Önemli olan en güçlü protokolü seçmek değildir. Servo sistemi, kontrolcü, araç mimarisi ve gerçek hareket gereksinimlerine uyan birini seçmektir.
AGV ve AMR tasarımcıları için bu genellikle daha güvenilir bir sisteme — ve devreye alma sırasında çok daha az soruna yol açar.
HKT ROBOT'ta servo ve tahrik çözümlerimiz CANopen, EtherCAT ve Modbus (RS485) dahil olmak üzere farklı iletişim seçeneklerini destekler. Protokol, kontrol sistemine ve araç mimarisine göre seçilebilir, böylece motor, servo sürücü, enkoder, dişli kutusu ve iletişim arayüzü tek bir tam hareket sistemi olarak birlikte çalışır.
Yeni bir AGV veya AMR projesi planlıyorsanız, uygun motor, tahrik, dişli kutusu ve tekerlek yapılandırması için araç özelliklerinizle birlikte bizimle iletişime geçin.
Sıkça Sorulan Sorular
1. CANopen ve EtherCAT aynı AGV'de kullanılabilir mi?
Evet. Bir araç, farklı alt sistemler için farklı iletişim ağlarını kullanabilir. Örneğin, EtherCAT senkronize servo eksenlerini yönetirken CANopen yerel sürücüleri veya yardımcı modülleri bağlayabilir. Kontrolcü mimarisi her iki ağı da desteklemelidir.
2. Bir CANopen veri yolu hem direksiyon motorlarını hem de tahrik motorlarını kontrol edebilir mi?
Evet. Düğüm sayısı, PDO yapılandırması, veri yolu yükü ve güncelleme hızı düzgün şekilde tasarlandığı sürece birden fazla servo sürücü tek bir CANopen ağını paylaşabilir. Pratik sınır genellikle fiziksel düğüm sayısından ziyade gerekli kontrol döngüsü performansı tarafından belirlenir.
3. EtherCAT, AGV tekerlek kaymasını azaltır mı?
Hayır. EtherCAT komut senkronizasyonunu iyileştirebilir, ancak tekerlek kayması esas olarak mekanik çekiş sorunudur. Tekerlek malzemesi, normal yük, ivmelenme, zemin durumu ve tahrik torku çok daha büyük etkiye sahiptir.
4. İletişim protokolü servo sürücüden önce seçilmeli mi?
Genellikle birlikte seçilmelidir. Araç kontrolcüsü, servo sürücü, enkoder arayüzü, desteklenen hareket modları, güvenlik işlevleri ve iletişim protokolünün tamamının uyumlu olması gerekir. Bir bileşeni önce seçmek daha sonra gereksiz entegrasyon işi yaratabilir.
5. CANopen hala yüksek faydalı yüke sahip AGV'ler için uygun mu?
Yalnızca faydalı yük protokolü belirlemez. Sınırlı sayıda eksenle yavaş hareket eden 20 tonluk bir AGV hala CANopen ile iyi çalışabilir. Hareket karmaşıklığı ve senkronizasyon gereksinimleri araç ağırlığından daha önemlidir.
6. AGV kontrolcüsü ve servo sürücü farklı CANopen profillerini kullanırsa ne olur?
Entegrasyon çok daha zor hale gelebilir. Her iki cihaz CANopen'i desteklese bile, desteklenen nesne sözlüğü, CiA 402 uygulaması, PDO eşleştirmesi, çalışma modları ve üreticiye özgü nesnelerin hala kontrol edilmesi gerekir.

Paylaşmak:
AGV ve AMR Sistemleri için Servo Sürücüler: Uygulamalar ve Yapılandırmalar