EtherCAT (2), Prehľadové články, Rubriky,

V predchádzajúcej časti seriálu (ATP Journal 5/2021) sme sa venovali začiatkom vzniku zbernice EtherCAT, organizácii EtherCAT Technology Group, metóde spracovania rámcov On the Fly, topológii tejto zbernice, skladbe rámcov (frame), synchronizácii, diagnostike a lokalizácii porúch, ako aj výhodám zbernice EtherCAT. V tejto časti sa budeme venovať opisu ďalších vlastností, ktoré čitateľom pomôžu správne pochopiť fungovanie EtherCAT-u. Hlavnou témou je stavový automat EtherCAT-u (tzv. EtherCAT State Machine), ďalej spomenieme jednotlivé protokoly, ktoré EtherCAT vie do seba zahrnúť, a opíšeme ich význam a možnosti použitia. Nadviažeme aj na informácie z predchádzajúceho dielu a detailne opíšeme synchronizačné skupiny (Sync Units), predovšetkým prácu s nimi, ich význam aj zmysel použitia.

EtherCAT State Machine (ESM)

Stavový automat EtherCAT-u je definovaný základnými stavmi Init, Pre-OP, Safe-OP a Operational. Špeciálnym stavom je BootStrap, ktorý slúži na prenos firmvéru. Základné pravidlá fungovania ESM sú zhrnuté v nasledujúcich bodoch:

EtherCAT Slave nasleduje stav svojho EtherCAT Master,
EtherCAT Slave nemôže zotrvávať vo „vyššom“ stave než jeho master,
master odovzdáva jednotlivým slave požiadavky, v akom stave sa majú nachádzať,
master kontroluje, či sú všetky slave v príslušnom stave,
smerom hore vedie cesta len pomocou prechodov cez jednotlivé kroky (vynechanie stavu nie je možné),
smerom nadol je zmena možná na akýkoľvek nižší stav priamo (stavy možno preskakovať),
stav je pretrvávajúca vlastnosť EtherCAT Slave (nežiaduce zmeny sú zaznamenané ako poruchy),
dôležité sú prechodové deje medzi jednotlivými stavmi.

Pri zmene stavu treba splniť príslušné požiadavky, ktoré prechod do nasledujúceho stavu podmieňujú. Poruchy nastávajú spravidla počas prechodových dejov. Preto si na pochopenie diagnostiky jednotlivé stavy opíšeme a v poslednom diele tohto seriálu na uvedené informácie nadviažeme.

Pre názornosť je dobré pripomenúť si typickú schému EtherCAT Slave, ktorá už bola uvedená v predchádzajúcom diele tohto seriálu. Z pohľadu funkcie EtherCAT je hlavným prvkom EtherCAT Slave Controller (ESC). Naň je naviazaná pamäť typu EEPROM. Záleží na type ESC a celkovom riešení EtherCAT Slave, ale samotnú funkciu EtherCAT Slave spravidla riadi ďalší mikroprocesor. To je ďalší procesor, s ktorým treba vytvoriť komunikáciu. Všetky opísané časti majú svoju nezameniteľnú úlohu a internú nadväznosť jedna na druhú a celkovo externú nadväznosť z pohľadu komunikácie celého zariadenia EtherCAT Slave voči EtherCAT Master. Jednoducho povedané, najskôr treba pomocou pamäti EEPROM inicializovať ESC a spustiť jeho väzbu na EtherCAT Master. Potom treba sprevádzkovať komunikáciu ESC s mikroprocesorom a opäť aj túto väzbu pomocou prostredníka ESC sprístupniť pre EtherCAT Master. To je v skratke a laicky opísané fungovanie tohto procesu, ktorý je v princípe zastrešovaný spomínaným stavovým automatom, teda EtherCAT State Machine.

Ako už bolo povedané, zariadenie slave rešpektuje či nasleduje stav svojho mastera. Preto je tiež logické rozlišovať aj stavový automat EtherCAT-u z hľadiska EtherCAT Master a EtherCAT Slave, pretože pre každého z nich daný stav znamená iné činnosti, iné odpovede, iné detegované chyby a pod.

Init

Z hľadiska EtherCAT Master ide o kompletnú inicializáciu predovšetkým adresných registrov a ak je implementovaný, inicializuje sa aj mechanizmus distribuovaných hodín. V komunikácii medzi master a slave vyčíta master z ESC VendorID kód produktu, prípadne sériové číslo. Všetko bolo pôvodne uložené v pamäti EEPROM.

Z hľadiska EtherCAT Slave dochádza k vytvoreniu internej komunikácie medzi ESC a mikroprocesorom (tzv. Host Controller). O túto dátovú výmenu sa starajú dve synchronizačné jednotky, SyncManager0 a SyncManager1, ktoré sú súčasťou EtherCAT Slave Controller. Pre mailbox komunikáciu tieto dve jednotky oddelene komunikujú vstupné a výstupné údaje z mailbox komunikácie. Dátová časť je však pre obe spoločná. Master má prístup len k registrom EtherCAT Slave Controller.

Ak sú na EtherCAT použité distribuované hodiny na synchronizáciu údajov, práve v stave Init dochádza ku kontrole a nastaveniu príslušných časových offsetov zmeraných pomocou minimálne 15 000 rámcov EtherCAT, ktoré za týmto účelom prejdú topológiou ešte za stavu Init.

Pre-Operational (Pre-OP)

Počas prechodu z Init do Pre-OP dochádza ku kontrole, či bola interná mailbox komunikácia vytvorená korektne. Dochádza k parametrizácii komunikácie procesných dát, nakoľko pri zmene nastavenia mohol byť zmenený rozsah procesných dát. Mapovanie procesných dát spadá pod mechanizmus Fieldbus Memory Management Unit (FMMU) a je realizovaný zvyšnými dvoma Sync Manager EtherCAT Slave Controller. Každý z týchto Sync Manager sa stará o výmenu jednej skupiny dát. Inými slovami, vstupné a výstupné procesné dáta sú od seba oddelené, pretože SyncManager 2 komunikuje výstupné dáta a SyncManager 3 komunikuje vstupné dáta. Na rozdiel od mailbox komunikácie sú na vstupné a výstupné procesné dáta vymedzené dve samostatné pamäťové oblasti.

Funkčný stav Pre-OP znamená úplne funkčnú mailbox komunikáciu od EtherCAT Master po mikroprocesor (Host Controller). Túto komunikáciu sprostredkúva EtherCAT Slave Controller. Procesné dáta v tomto stave ešte nie sú komunikované.

Safe-OP (Safe-Operational)

Prechodom z Pre-OP do Safe-OP nadobudne platnosť adresácia a overí sa jej funkčnosť nastavená v predchádzajúcom stave. Reč je predovšetkým o kontrole nastavení a plnej funkčnosti jednotlivých Sync Managers. Funkčný Safe-OP mód znamená kompletný a funkčný prenos mailbox komunikácie a vstupných procesných dát. Hodnoty vstupných procesných dát sú cyklicky aktualizované. Popri tom sú do EtherCAT Slave doručené aj hodnoty výstupných procesných dát, zostávajú však v bezpečnom stave a nie sú prenášané na fyzické výstupy. Ak je použitá synchronizácia pomocou mechanizmu distribuovaných hodín, potom je už v stave Safe-OP plne funkčná.

Operational (OP)

Prechod do stavu Operational prakticky znamená, že už prenášané, teda známe hodnoty výstupných procesných dát začnú byť razom prenášané aj na fyzické výstupy daného EtherCAT Slave. Stav OP zodpovedá plne funkčnému zariadeniu EtherCAT Slave. Kompletne sa prenáša všetka komunikácia vrátane výstupných procesných dát. Pre diagnostiku funkčného stroja je kontrola tohto stavu pri všetkých zariadeniach v topológii základným ukazovateľom. Treba podotknúť, že stav Operational je nutnou podmienkou funkcie zariadenia a vzťahuje sa na problematiku ESM. Neznamená to však, že zariadenie v stave OP nemôže detegovať iný typ poruchy. Preto treba brať stav Operational z pohľadu diagnostiky v súvislosti so všetkými ostatnými ukazovateľmi.

Bootstrap

Ide o špeciálny režim prístupný iba zo stavu Init. Slúži na aktualizáciu firmvéru daného EtherCAT Slave. Neprenášajú sa žiadne procesné dáta. Funkčná je len mailbox komunikácia, predovšetkým pre protokol FoE (File over EtherCAT).

Protokoly EtherCAT (CoE, EoE, FSoE, AoE, SoE…)

Ďalšou dôležitou vlastnosťou EtherCAT-u je možnosť integrovať do dátového priestoru EtherCAT Frame aj iné protokoly. Táto vlastnosť nie je bezpredmetná, ide o praktické rozšírenie. Konfiguráciu, diagnostiku a prístup k registrom slave zariadenia zabezpečuje acyklická komunikácia, ktorá je založená na mailbox protokole. Mailbox protokol je potvrdzovaná, spoľahlivá a diagnostikovaná komunikácia.

Vzhľadom na potrebu obslúžiť veľmi široké spektrum slave zariadení (od digitálnych signálov cez analógové a enkodérové signály až po servomenič a safety zariadenie) a šírku rôznych typov aplikačných vrstiev boli definované nasledujúce komunikačné protokoly. Mailbox komunikácia nie je povinná pre všetky typy slave zariadení, na jednoduché a základné spracovanie digitálnych signálov nie je potrebná vôbec. Mailbox komunikácia neznamená ucelený balíček. Vždy podľa typu zariadenia a individuálnych potrieb EtherCAT Slave sú implementované len konkrétne typy protokolov.

CoE (CANopen over EtherCAT)

Prostredníctvom CoE je v rámci EtherCAT plne implementovaná CAN Open komunikácia definovaná štandardom EN 50325-4, ktorý definuje Object Dictionary, PDO mapping (Process Data Objects) a komunikáciu SDO (Service Data Objects). Podporované je aj rozšírenie štandardu CAN Open, napr. implementovaného profilu CiA 402 na riadenie servomeničov.

EoE (Ethernet over EtherCAT)

Vďaka EoE možno prostredníctvom procesných dát EtherCAT prenášať štandardné ethernetové správy, teda čokoľvek zo sveta IT založeného na spojení TCP/IP. Prakticky takýto prenos dát zodpovedá použitiu tunelov. Ethernetové zariadenia sú s topológiou EtherCAT prepojené pomocou tzv. switchportov, ktoré vedia fragmentovať a defragmentovať ethernetové správy „do“, prípadne „z“ EtherCAT Frame. EtherCAT Master a switchport tvoria druhú (linkovú) vrstvu modelu OSI, keď sú ethernetové správy odosielané na konkrétne MAC adresy jednotlivých zariadení, možno prenášať tiež akékoľvek internetové dáta (webové servery, e-maily, FTP spojenia…).

SoE (SERCOS over EtherCAT)

SERCOS je uznávaný komunikačný štandard vo svete motion aplikácií. Mailbox komunikácia môže pomocou SoE zahŕňať aj servisný prístup k parametrom a funkciám servomeničov.

FoE (File over EtherCAT)

Prenos súborov pomocou dát EtherCAT má význam predovšetkým pri prenose firmvéru do zariadenia EtherCAT. Zariadenia EtherCAT Slave spravidla nemajú implementované žiadne ďalšie rozhranie. Preto je aj FoE ďalším dôležitým protokolom, pretože bez ďalšieho rozhrania by aktualizácia firmvéru nebola možná.

FSoE (Fail Safe over EtherCAT)

Z hľadiska strojnej bezpečnosti je integrácia prenosu dát pre certifikované bezpečnostné zariadenie úplne zásadná. O tento prenos sa stará protokol FSoE, ktorý svoj názov dostal podľa základného bezpečnostného princípu Fail Safe. Certifikované bezpečnostné zariadenie, či už to sú rôzne skenery alebo servomeniče s integrovanými bezpečnostnými funkciami, musí voči Safety CPU prenášať dáta bezpečnou cestou. Priemyselné zbernice samotné sú so svojou chybovosťou o rád vyššie, než súčasné najvyššie štandardy vyžadujú. Preto možno do takej zbernice implementovať mechanizmus, ktorý zabezpečí spoľahlivý a kontrolovateľný prenos dát do pripojeného bezpečnostného zariadenia.

Start-Up List

Už bolo uvedené, že protokol CoE slúži aj na parametrizáciu zariadenia EtherCAT. Parametre sa ukladajú do pamäti EEPROM napojenej na EtherCAT Slave Controller každého zariadenia (obr. 6). Parametre zariadenia sú teda naviazané na dané fyzické zariadenie a možno ich meniť pomocou mailbox komunikácie a opakovane prepisovať. Pri výmene zariadenia je žiaduce, aby nové fungovalo ako to predchádzajúce. Práve vďaka parametrizácii cez protokol CoE je to možné. V riadiacom systéme možno nastaviť všetky parametre tak, aby pri prípadnej výmene zariadenia EtherCAT systém pomocou CoE prepísal všetky parametre na požadované hodnoty. Zoznamu s takými parametrami môžeme hovoriť napr. Start-Up List a bez problémov ho môžeme aplikovať aj vo veľmi komplexných zariadeniach, ako sú napr. servomeniče, kde sú oproti východiskovému stavu prednastavené desiatky parametrov.

Synchronizační skupiny (Sync Units)

V úvodnom diele tohto seriálu sme opísali zloženie EtherCAT Frame. Takže už vieme, že dátovú časť EtherCAT-u delíme na tzv. datagramy, a tiež to, že jednotlivé datagramy sú riadené EtherCAT COMMAND, ktorých je viac typov. Aby sme pochopili význam synchronizačných skupín, sú pre nás dôležité Command, ktoré obsluhujú procesné dáta. (Pre úplnosť sú to Command: LRD – Logical Read, LWR – Logical Write, LRW – Logical ReadWrite.)

Z uvedeného zoznamu vyplýva, že tieto základné dátové jednotky obsluhujú buď skupiny čisto vstupných dát, čisto výstupných procesných dát, prípadne môžu obslúžiť zariadenia, ktoré dáta čítajú aj zapisujú. Dátová skladba každého datagramu je nasledujúca. Obsahuje samozrejme hlavičku, ďalej dátovú časť, ktorú reprezentujú práve procesné dáta vstupov a výstupov. Poslednú časť datagramu tvoria 2 Byte pre kontrolný mechanizmus, ktorému hovoríme Working Counter. Opis detailného fungovania tohto mechanizmu nechajme na záverečný diel nášho seriálu, kde opíšeme pravidlá fungovania na úrovni zariadení EtherCAT Slave a samozrejme vyhodnotíme tento mechanizmus zo strany EtherCAT Master.

Ruka v ruke s diagnostikou ide aj to, že celá topológia EtherCAT môže byť rozdelená na viac skupín, čo má dôležitý funkčný význam. Záleží na tom, či toto rozdelenie vytvorí EtherCAT Master alebo sa do vytvorenia logických celkov vloží sám používateľ. Praktický význam vytvorenia synchronizačných skupín spočíva v tom, že vzniknú uzavreté, spravidla používateľom vytvorené funkčné a logické celky, ktoré nebudú funkčne ovplyvnené problémom týkajúcim sa inej synchronizačnej skupiny.

Aby sme to pochopili správne, uveďme príklad: používateľ rozdelí vstupy aj výstupy z hlavného rozvádzača, zároveň definuje synchronizačnú skupinu pre safety prvky a do samostatných synchronizačných skupín zahrnie aj jednotlivé funkčné skupiny stroja. Ak dôjde k poruche komunikácie v jednej z funkčných častí (napr. k odpojeniu alebo poškodeniu kábla EtherCAT alebo k výpadku ovládacieho napájania), bude sa tento výpadok týkať len dotknutej časti a všetky ostatné skupiny zachovajú plnú funkčnosť a budú všetky dáta správne komunikovať, vyhodnocovať aj diagnostikovať.

Dôležité je pripomenúť informáciu z minulého dielu, že každý EtherCAT Frame vždy prechádza celou topológiou, ktorá je definovaná v rámci daného EtherCAT Master. To, že je jedna časť neprístupná alebo že v tejto časti topológie dochádza k problému, neznamená, že dôjde k výpadku celku. EtherCAT Frame má možnosť vrátiť sa k EtherCAT Master a tým obslúžiť dostupnú časť topológie EtherCAT. V takom prípade nedochádza k strate EtherCAT Frame, ako sa niekedy mylne uvádza.

Možné logické celky na tvorbu synchronizačných skupín:

oddelenie logických celkov, ako sú hlavné rozvádzače a pridružené menšie rozvádzače stroja,
oddelenie operátorských pultov,
oddelenie funkčných celkov stroja,
oddelenie riadenia motion častí,
oddelenie bezpečnostných komponentov,
oddelenie vložených komunikačných rozhraní (Profibus, PROFINET, CANopen, EtherNet/IP…),
oddelenie častí definovaných ako Hot Connect Group.