EtherCAT G: 1 Gb/s az új sebességszint (x)

 ( hup | 2019. szeptember 9., hétfő - 14:18 )

Az EtherCAT technológiát új sebességszintre emelő EtherCAT G rendszerkiegészítés Gigabit Ethernet sebességet biztosít nagy adatmennyiségekkel dolgozó alkalmazásokhoz. A megoldás kompatibilis a világszerte használt 100 Mbit/s sebességű EtherCAT technológiával, és a megszokott, egyszerű kezelhetőséget nyújtja. Ezenfelül az új, EtherCAT G rendszerű ágvezérlő lehetővé teszi párhuzamos hálózatszegmensek hatékony üzemeltetését is.

Az EtherCAT G működése a szabványos, 1 Gbit/s sebességű Ethernet-átvitelen alapul, a technológiai tanulmányként bemutatott EtherCAT G10 változata pedig 10 Gbit/s adatátvitelt tesz lehetővé. A szabványos 100 Mbit/s-ot lényegesen meghaladó átviteli sebesség jelentősen növeli az EtherCAT által biztosított adatátvitelt. Az eszközök okozta késleltetés és az újonnan bevezetett ágvezérlési koncepció együttes hatásaként az EtherCAT G az adott alkalmazástól függően 2–7-szer nagyobb feldolgozási sebességet biztosít. Hans Beckhoff, a Beckhoff Automation GmbH & Co. KG tulajdonosa és ügyvezető igazgatója szerint: „Az EtherCAT G és G10 új sebességrekordot állított be, aminek révén ügyfeleink a világ legkorszerűbb magas teljesítményszintű gépeit építhetik meg! Az EtherCAT G és G10 nem a rendkívül sikeres 100 Mbit/s sebességen alapuló EtherCAT-szabvány kiváltását jelenti, hanem az új teljesítményszintek meglévő rendszerbe történő bővítésére szolgálnak.”

Teljes EtherCAT-kompatibilitás

Az EtherCAT G az EtherCAT-tel megegyező jellemzőkkel, de még nagyobb adatátviteli sebességgel rendelkezik anélkül, hogy meg kellene változtatni a protokollt, vagy az EtherCAT Master-programot. Az EtherCAT G teljes körűen kompatibilis a világszerte használt EtherCAT-szabvánnyal, és ugyanazokat a gyakorlatban bevált képességeket nyújtja – többek között beépített diagnosztikát, nagy pontosságú szinkronizálást és legfőképpen egyedülálló, azonnali telegramfeldolgozást. Az EtherCAT G kompatibilis az IEEE 802.3 Ethernet-szabvánnyal is.

Az általános EtherCAT nyújtotta nagy átviteli sebesség a jelenlegi alkalmazások többségéhez bőven elegendő. Az EtherCAT G kifejlesztésének célja az volt, hogy legyen technológia a jövőben várható, rendkívül nagyléptékű alkalmazások és különösen a nagy adatforgalmat lebonyolító eszközök – például gépi látást biztosító kamerák, összetett mozgásvezérlő rendszerek és nagy mintavételi frekvenciájú mérőeszközök – egyre szélesebb körű támogatására.

Ágvezérlési koncepció: kiterjedt eszköztámogatás, minimális jelterjedési késleltetés mellett

Az EtherCAT és az EtherCAT G a hálózatokon vegyesen is alkalmazható, azaz az EtherCAT G vezérelt („slave” szerepkörű) eszközök üzemeltethetők 100 Mbit/s sebességű EtherCAT-hálózaton, és fordítva - az EtherCAT G mindkét esetben visszavált 100 Mbit/s-os sebességre. Ezzel szemben az új EtherCAT G ágvezérlési modellben létrehozhatók olyan EtherCAT leágazások, amelyek megfelelő sebességkonvertálással lehetővé teszik 100 Mbit/s-os szegmensek párhuzamos üzemeltetését 1 Gbit/s sávszélességű hálózaton. Például, az új EK1400 típusú EtherCAT G csatolóval létrehozható olyan ág, amely az 1 Gbit/s-os átviteli sebességet 100 Mbit/s-ra csökkenti, így EtherCAT G hálózaton is lehet használni a be- és kimeneti funkciókat ellátó, számos különféle általános EtherCAT-terminált. Az EK1400 ágvezérlési funkciói nem érintik az EtherCAT törzs 1 Gbit/s-os sebességét.

Az EtherCAT G ágvezérő-rendszer másik előnye, hogy minimálisra csökkenti a jelterjedési késleltetéseket. Erre a célra szolgálnak az új, CU14xx-sorozatú ágvezérlők, amelyekkel EtherCAT és EtherCAT G szegmenseket lehet egymáshoz csatlakoztatni, és ezáltal párhuzamosítani. Ezzel az elrendezéssel jelentősen csökkenthetők a jelterjedési idők, és lerövidíthetők az adatátviteli-, illetve ciklusidők, mivel az egy adott szegmensből érkező telegramok az ágvezérlőből közvetlenül jutnak el a vezérlő („master”) szerepkörű egységhez, mégpedig a többi hálózatszegmenstől függetlenül, 1 Gbit/s sebességgel.

(A Beckhoff megbízásából készített anyag.)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Igazan leirhattak volna hogy megis mi ez az EtherCAT.

https://en.wikipedia.org/wiki/EtherCAT

invented by Beckhoff Automation
Jééé!

Egy protokoll.

Bizonyos feladatoknal - tipikusan CNC gepeknel - ha egy kozponti eszkozod van, es kis kesleltetessel kell valamit vezerelned, egy hataron tul (bizonyos pontossaghoz) az Ethernet nem eleg. Ilyenkor az Ethernettel kb. egyezo hardware-re epithetsz mas protokollal EtherCAT alapu rendszert, aminek kicsi a kesleltetese, eleg jol ossze van szinkronizalva (az 1. slave ad nagypontossagu orat), es egyeb finomsagokat tud (pl. normalis halozatos adatatvitelre tudsz bele mast is csomagolni). Plusz ha mar egy gyartelepen vannak EtherCAT-es eszkozeid, felfuzhetsz a rendszeredre mindenfele egyeb erzekeloket, nyithatsz ajtokat, effeleket.

Az latszik rajta, hogy valakik leultek, es nagyon megterveztek. Az is latszik, hogy sokat foglalkoztak a kompatibilitassal is. Tovabbi elony, hogy a slave-ekhez tartozik egy (na jo, igazabol tobb) xml file, ami kb. a SOAP-hoz hasonloan leirja mik a kutyu kepessegei (szoval feldugod a lancodra, es a master tudni fogja mit csinaljon vele). Viszont ezek miatt eleg bonyolultra sikerult. Szinten emiatt az Ethernettel valo viszonyt az eszkozok oldalan nem nagyon tudod kihasznalni, a master oldalan meg ha egy PC van (real time linuxon eletre keltheto, de nagyon sok fekete kakast kell erte felaldozni), akkor azzal fogsz nagyon megszenvedni.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ez az infó tényleg hiányzott a cikkből, enélkül elég lámának tűntek, hogy 20 év kellett a gigabites sebességhez.
Amúgy tényleg ennyire rossz az Ethernet, még egyetlen egy darab közös erős sokportos menedzselhető switch mellett is, hogy külön protokoll kell az általad említett problémákhoz? Még a hubok, a korai switchek és kiforratlan NIC csippek és driverek idején meg is értem, de lassan már 2020.

Legnagyobb hibaja, hogy nem real-time; azt nem tudom, hogy ezt a hianyossagot beceloztak-e, de nem is ertem, ha igen.

valaki roviden elmagyarazna, hogy egy nem real-time rendszer folott hogyan lehet real-time rendszert epiteni?

Mert ahogy neztem, ez a fo csapasiranya ennek az EtherCAT-nek.

A fent említett wiki oldalon, van egy frame processing video, azt nézd meg.
Szerintem annak köszönhető, h meg tudják ezt (" egy nem real-time rendszer folott real-time rendszert építeni") csinálni, h. az eth. head. után egy ethcat head.-ot tesznek. Tehát eth. frame-be van beágyazva az ethcat frame, amit a slavek az eth. működésétől -szinte- függetlenül tudnak olvasni/írni.
Ha jól értem , tehát nem kell megvárni a slave-eknek, hogy a teljes eth. keret beérkezzen, mert nem foglalkoznak eth. keretekkel, csak az abban lévő ethcat mezőkkel dolgoznak.

Ujra feltalaljak a token-ringet :)

token ring over ethernet :D

A token ringgel annyira nem losz melle, ugyanis az adat "korbe" vandorol: elindul a masterrol, vegigmegy a slave-eken (mindenki leszedi a sajatjat el felpakolja a visszakuldendot), aztan vissza a masternek.

Egyebkent egy csomo protokollbol van benne valami, egy csomo regisztercim erteke annyi, mert CAN-nel is annyi volt. (azt is hasznaltak gepvezerlesre korabban)

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Az EtherCAT az egy protokoll, annak nincs sok koze a real time-hoz. Kis jittert, es kis kesleltetest tud, ez az elonye. Nem hasznalja a szokasos halozati eszkozoket, tipikusan lancba vannak fuzve (kepzelj el egy csomo szamitogepet, aminek 2-2 halokartyaja van, amivel egymasnak adjak az adatot), de lehet fat is csinalni.

Lehet Ethernetet EtherCATbe agyazni, ahogy a protokollokat tipikusan szoktak (TCP/IP, UDP/IP, stb.), de ennek nem sok koze van hozza. Ilyenkor a halokartya nem Ethernet protokollt hasznal a maga utkozeses problemaival (amivel a jitter megnone), hanem ugyanazon a hardware-en EtherCATet.

Igy hirtelen egy par perces bemutato:
https://www.youtube.com/watch?v=xNE1Y7_mH8E

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

tehat ja jol ertem, akkor ez RS485 felturbozott verzioja?

En is ezen gondolkodtam, de lusta vagyok utanaolvasni.
Az Ethernet arbitralasi modszertana nem real-time, de switched fabricon ez nem kellene hogy eloforduljon.
Telco eseteben is vannak idokritikus folyamatok, megis meg tudjak oldani Ethernet + PTP (ami sub-microsecond pontossagot iger) hasznalataval. Ha meg nem eleg a sebesseg, akkor akar 100G-ig is fel tudsz menni.

Vagyis az a megoldas, hogy a switch, ami segmental, real-time parameterek megadasa menten iranyitja a forfalmat, ill. tobb switch egymassal kommunikalva biztositja, hogy egy node-rol erkezo forgalom eljuccon a celig?

Nincs switch, mert nincsenek MAC címek. Az egész egy soros topológia (Slave-ek egymás mögé vannak felfüzve), de speciális modulokkal lehet fa és csillag elágazásokat is felépíteni, illetve az utolsó modultól egy kábellel lezárni a kört a master felé és így kábelredundanciát kiépíteni (token ring? :)

Ha tényleg ethernet és switch kell, akkor nézd meg a TSN-t, bár ennek még nincs kész a teljes draftja, de sokkal komplikáltabb lesz, mert a switchekben már igazi nagy procik vannak a csomagpriorizálás miatt. Erre még ráeröltetik az OPC UA-t mint terepi busz protokollt (bár az OPC UA egy arhitektúra és nem egy protokoll, de mindegy) és szerintem ezzel csak komplexebb lesz az egész.

Egyik elozo munkahelyemen osszeraktunk/felujitottunk par CNC gepet LinuxCNC es sajat fejlesztesu meghajtok (Ethernet+UDP+broadcast IP) alapjan (azert ez joval egyszerubb az EtherCAT-nel). Eleg jol mukodott, de latszottak a hatarai. Mondjuk a mechanika is regi volt, szoval az is korlatozta az elerheto pontossagot.

Mondjuk kikuldesz egy csomagot, amiben benne van, hogy melyik tengelyedtol milyen mozgast varsz el (ez a resze broadcast), mindegyik kiveszi belole a neki szant reszt, es visszakuldi kulon-kulon hogy hol van (erre tudsz szabalyozni). Utobbival lehet a gond, meg ha a kikuldott parancsnal nincs is nagy jitter, a visszakapott valasz elegge ossze-vissza erkezik be. Erre a reszere nyujt megoldast az EtherCAT.

A master a masik kerdes. Lehet venni/csinalni direkt ilyen vezerlot, ennek meg van a sajat koltsege. Betehetsz a helyere egy sima PC-t, a legtobb OS-en viszont van valami utemezo, ami miatt a CNC vezerlo programod neha nem kap prociidot. Leteznek olyan Linux kernel patchek, ami vagy soft realtime (-RT ag, gyakorlatilag uj utemezovel), vagy ott az RTL es ujabb forkjai, aminel van egy pici real time kernel, es ez a te programodat utemezi be amikor az futni akar, a maradek idoben meg a sima Linux kernelt, ami a sajat programjait. Ebbol hard real time rendszert is tudsz csinalni. Ehhez jon meg hozza a LinuxCNC project, ami egy nyilt forrasu CNC vezerlo program, amihez hozza tudsz illeszteni sajat drivereket. Ki tudja hasznalni ezt a hard real time modot is, de nem egyszeru. Egyreszt vannak mindenfele honfoglalaskori, egymassal inpompatibilis verziok, amire valami egyetemista a szabad idejeben 10 eve osszelotte, hogy menjen valami (a tobbi resze nem megy). Masreszt ha a real time kernellel akarod kezeltetni, akkor az a speci kernel kell, hogy kezelje a halokartyadat, es ezt a drivert csak par kartyahoz irtak meg. Letezik valamilyen LinuxCNC+kernel verziohoz meg EtherCAT master is, itt meg jobban kotott, hogy milyen verzio jo, es azzal milyen hardware mit tud. Eleg nagy a kaosz, de keves ember hasznal es fejleszt ilyesmit, szoval nem csoda.
Van meg egy jopofa project: LinuxCNC letezik Beagleboardra is (kb. mint a RPi), ami legalabb egy egyseges hardware, es van ipari dobozos kivitele is.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

En mar az alapveto dolgokat nem ertem.
Miert kell egy CNC-t tavolrol, halozaton keresztul vezerelni ilyen modon? Miert nem csak a kifaragando format kuldik at halozaton es a CNC onalloan elvegzi a munkat (amiben van vmi mikrokontroller RT koddal).

Jol latod a problema lenyeget, emiatt en is fogtam mar a fejemet. Foleg, hogy a kis, $200 koruli CNC gepeknel pont ez van: egy $2 Arduino Nano (elegansabb esetekben a nyakra integralva) megkapja a G code-ot USB-n vagy SD kartyan, par parancsnyit elorenez, hogy a fordulokat meg hirtelen iranyvaltasokat jol be tudja venni, es ha PC-hez van kotve, elkuldi neki, hogy hol tart. A 3018 Pro-m igy mukodik, es eltekintve a mechanika hianyossagaitol (egy asztali, extrudalt aluminiumbol allo geppel nem fogsz acelt marni), meg hogy a leptetomotor ha teveszt, nincs feedback, teljesen jol mukodik. Persze a G code csak egy reszhalmazat tudja ertelmezni, de ez nem problema, mert ugyis valami 3D tervezo program allitja elo, az meg csak olyat tesz bele, ami neki jo.

Tippre a hagyomany miatt szerettek volna egy helyen tartani mindent. Illetve ha mar technikailag megoldhato, hogy minden egy helyen legyen, akkor teljes gyartosor eseten lehet elonye (pl. robotkar adagolja a CNC gepbe a munkadarabokat). A kiegeszithetoseg/skalazhatosag megint jobb egy mikrokontrolleres eszkozhoz kepest, ha kell meg ket tengely (pl. elforgatni a munkadarabot), csak felkotsz a lancra meg ket vezerlot.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

ha a gyártó nem egy custom PCB-vel hanem általános feladatokra épített PLC "legó" rendszerrel fejleszti a CNC gépét, akkor a moduloknak egymás között valahogy kommunikálni kell. A szervó erösítök méretétöl függöen (akár néhány száz Amper) néha nem is lenne lehetséges egy nyákon kivitelezni mindent, és ezért is kell a kommunikáció a modulok között.
Ehhez kell egy terepi busz, ami lehetöleg hard real time (értsd determinisztikus idöközönként, lehetöleg kicsi jitter-el) küldi az adatokat a vezérlö és a hajtások között. Itt gyártótól függöen vannak különbségek, a pl. Siemens fejegység PROFINET-en nem hard realtime küldi az adatokat, de a szervó erösítök már hard realtime (DRIVE-Cliq) kommunikálnak egymással.

Én is erre gondoltam, de nem mertem beírni. :)
--
"Sose a gép a hülye."

FYI: Ez mar a sokadik Beckhoff hirdetes a hupon. Korabban sinre illesztheto mini PC, meg ilyesmik voltak, amire fejbol emlekszem. Ott is emlitettek az EtherCAT-et.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Nagyon jó, hogy van már 1 Gbps tempójú is, de ahogy elnézem bármilyen ethernet tempójú lehetne, mivel nem a médiát határozza meg, hanem mindössze a normál ethernet keretben a DSTMAC SRCMAC után egy 0x88a4 típusmegjelölésű ethernet csomag. Tehát végülis mindegy milyen tempójú etherneten viszik.

*fixme* de szerintem az FPGA-k / ASIC-ek a slave-ekben csak 100Mbit/s -et tudtak

Nem kell neked ethernet MAC-et tartalmazó FPGA. Rendes ethernet kontrollert is beletehetsz, amely pufferéből szelektíven kivehetsz byte-okat ill. dobhatod a puffert a kontrollerből ha nem kell neked több tartalom abból a csomagból. Én valamikor még vacak 8 bites mikrovezérlő + ethernet kontrollerrel csináltam hasonlót. Persze azokkal a hardverekkel még kisebb tempók mellett.

úgy értettem, a meglévö ASIC-ek illetve Slave-ek (pl ET1100, TIDA-00299) csak 100MBit-et tudtak és ezért fejlesztették ki az új 1G és 10G verziókat.
Ha magad fejleszted, gondolom mindenhol meg lehet oldani - én most kész EtherCAT Slave implementációkra gondoltam