CNC Fórum

Ahoj
rozbehal jsem vyse zminene
pridavam nejake poznatky
v realu to bude k videni na prednasce mozno koupit zde http://www.bausano.net/en/hardware/ethe ... sycat.html" onclick="window.open(this.href);return false;
cena do dvou tisic, maji i jina provedeni vhodnejsi k zabudovani do vlastniho zarizeni
jedna se o shield k arduinu nebo jako periferie k jinym MCU postrednictvim SPI pro zabudovani do zarizeni
v zakladnim firmware je nastaveny tak ze si vymenuje po sbernici 32 bytu IN a 32 bytu OUT
ja jsem to zkusil s velmi rozsirenym arduino UNO do ktereho jsem nakompiloval jeden exampl od vyrobce hardware je dostatecne vybaveny pro zakladni otestovani funkci takze jsem to ponechal uplne beze zmeny a zameril se na zakladni komunikaci s linuxcnc
na prvni tuknuti to beha ve windows s ethercat configuratorem od beckhoffu kde se da otestovat funkce
moznosti jsou neskutecne, v kombinaci s MCU je mozne prevadet analogove informace tam i zpet, v mcu citat rychle citace a sdilet je s HALem a spousta dalsich veci


1. je treba rozbehat ethercat podporu v jadre a hal modul pro linuxcnc
je to identicke jako v tomhle popisu od fupeho http://forum.strojirenstvi.cz/viewtopic ... 55&start=0" onclick="window.open(this.href);return false;
v mem pripade jsem narazil na dve drobne odchylky (konfigurace ethercat sitovky pro generovani initrd neni v /etc/sysconfig... ale /etc/default/ethercat tedy nutno prepsat i v initscriptu, druha odchylka uz byla popsana v popisu rozchozeni deltackeho ethercat servodriveru asda, a to konkretne ze nelze pouzit driver sitovky generic nebot to vytuhava jadro)
definice syncmanageru a PDOcek zde: protoze jsem na tom chvili vykysnul pujcil jsem to fupemu ktery se zasekl na stejnem problemu ale postupnym prostridanim firmwaru toho easycatu se mu povedlo se dobrat k tomu ktery s linuxcnc knihovnou fachci
tj. s defaultnim firmwarem se to asi rozjet nepovede
k dispozici jsou na strankach tyhle firmwary (hvezdickou oznacene by meli chodit):
EasyCAT_128_128_rev_1.bin
EasyCAT_16_16_rev_1.bin
*EasyCAT_32_32_rev_1.bin
EasyCAT_64_64_rev_1.bin
*EasyCAT_V1_0.bin
EasyCAT_configurable_rev_1.bin

po techto prvotnich peripetiich se to rozbeha uplne stejne jako v predchozich navodech tj. nacte se do halu komponenta na konfigurovani ethercat modulu s prilozenym XML a pak samotny halovy modul, start a uz to jede, pak je mozne si data prohlizet pomoci halscope a pod. na halscope je vidno analogovy pin arduina kdyz se posimra prstem a softwarem v arduinu generovany pilovy prubeh

jak jsme debatili s fupem, komunikace na prvnich dvou syncmanagerech (zde pouzitych) beha mirne odlysne nez na dalsich dvou ktery jsou urceny pro updatovani rychlostnich polohovych a jinych registru v servo aplikacich
takze je jeste co badat co se tyce treba nazazeni jako uplne realtime interface pro rizeni nebo zpetnou vazbu os ale za me velmi zajimavy kus hardware

jeste doplnim
protoze mi permanentne vytuhava linuxovej ethercat master nedoporucuju pouzivat generic driver sitove karty ale nativni drivery soucasti toho baliku
ty jsou ovsem podporovany pro omezeny vyber karet
prozatim:

8139too - RealTek 8139C (or compatible) Fast-Ethernet chipsets.
e1000 - Intel PRO/1000 Gigabit-Ethernet chipsets (PCI).
e100 - Intel PRO/100 Fast-Ethernet chipsets.
r8169 - RealTek 8169/8168/8101 Gigabit-Ethernet chipsets.
e1000e - Intel PRO/1000 Gigabit-Ethernet chipsets (PCI Express).

update
driver generic neni plne kompatibilni RTAI
v PREEMPT_RT by to melo makat normalne

Chci si udělat vlastní desku s LAN9252 a procesorem ARM.
Abych zbytečně neprokopával slepé cesty, tak jsem napsal Ježíškovi, ať mi na pokusy přinese EasyCAT. A protože jsem byl celý rok hodný, tak mi přání splnil.

Zatím jsem to zprovoznil s ARMem pomocí těch jejich examplů. Bude následovat kompletní přepsání toho firmware resp. knihoven, abych se zbavil závislostí na jejich kódu.

Vygenerování nové konfigurace EEPROM pomocí siitool a její nahrání do desky Etherlabem funguje pěkně, takže zatím spokojenost.
S čím už menší spokojenost je fakt, že dokumentace k formátu ESI (XML config desky) je jen pro platící členy EtherCAT group. Naivně jsem si myslel, že tyhle věci budou volně dostupné, když se Beckhoff prsil, jak všechno dal k dispozici lidstvu. Nemáte někdo náhodou to PDF s popisem ESI?

Ale proč píšu: máte někdo LAN9252 zprovozněné a máte k tomu už třeba udělaný (nebo nalezený) nějaký nadstavbový systémový SW?
Bylo by příjemné mít k tomu třeba aspoň jednoduchý CoE stack. Nebo aspoň nějaký proprietární protokol nad mailboxovou komunikací.
Případně nějaké poznatky a tipy z praxe?
Díky.

Poznámka: když jsem četl ten předchozí post od robokopa, tak jsem nepochopil, o jaké odlišnosti syncmanagerů se tam mluví. LAN9252 má 4 syncmanagery a jsou si (podle mě) svými vlastnostmi rovné - každý z nich může fungovat v Buffered nebo Mailbox módu.
Samozřejmě změnit používané SM v SII EEPROM je snadné, ale myslím, že to není nutné, že SM0/1 budou fungovat stejně jako SM2/3.
Jestli jsem něco přehlídnul, tak prosím napište.
Díky.

kutil_tim píše: ↑4. 1. 2019, 8:55 k čemu je dobrá deska s lan a arm ?
jaký je cíl snažení ?

Obecně použitelná EtherCATová periferie, pro CNC nebo i jinam.
Chci to osadit 2-3 kusy 50-pin konektorů, kompatibilními s konektory na kartách Mesa. No a protože chci udělat vlastní oddělovací karty pro Mesu, tak pak budou použitelné i tady.
Pro začátek obecné vstupy a výstupy (opticky oddělené a diferenciální vstupy, výkonové výstupy PNP, NPN a push-pull). Pak možná přijdou nějaké vstupy pro enkodéry a výstupy 0-10V pro řízení vřetene nebo obecných pohonů, no a někdy možná i DIR/STEP výstupy, aby se daly EtherCATem připojit běžné krokáče nebo DIR/STEP serva.
Co všechno z toho a kdy bude záležet na tom, jak na tom budu s časem, je to moje hobby. Ale baví mě to a EtherCAT se mi líbí.

Tak pokusy celkem zdárně pokračují.
Mám tady teď na chvíli ještě inteligentní svorkovnici od Waga (Wago 750-354), ta se taky povedla připojit, takže mám 2 různé klienty, což je pro pokusy fajn.

Ale docela bojuju s Distributed Clocks. S vypnutým DC najedou klienti okamžitě. Ale při zapnutém DC to jednak hlásí warning o nepřesně spárovaných hodinách, to se ale asi dá ignorovat:
--- LCEC: Invalid appTimePeriod of 1000000 for master 0 (should be 999775).
S různými mainboardy je ta odchylka lehce různá, takže to evidentně skutečně záleží na nepřesnosti hodin, resp. časování threadu v RTAI.

Ale následně synchronizace DC skončí prodlevou 5 sekund, než klienti najedou do OPu:
--- EtherCAT WARNING 0-0: Slave did not sync after 5000 ms.
Zřejmě se pak ten DC rozjede, protože signál Sync0 pak periodicky generuje (bez spuštěného DC ho negeneruje). Ale třeba Sync1 se mi rozjet nepovedlo. Je ale možné, že Sync1 není ošetřený v té nadstavbě pro LinuxCNC, on se normálně většinou asi nepoužívá (zdrojáky jsem zatím nezkoumal).

Máte prosím někdo s Etherlabem rozběhnutý DC? A funguje vám hladce nebo s problémy jako u mě?
Díky.

PS. Nesprávně používám termín "klient" místo "slave", protože slovo "slave" je nesklonné a v českém textu se s tím blbě pracuje. A psát množné číslo jako "slejvy", "slavy" nebo "slaves" mi přijde ošklivé.

nevybavuju si presne ale to s tema hodinama mi myslim taky delalo
ale nebyl cas to resit
z hlediska regulace to nic viditelneho nevyvadelo, tak jsem se v tom vic nevrtal

Já to DC určitě chci rozjet. Považuju to za velmi silnou vlastnost EtherCATu, které by bylo škoda nevyužít.

Pro ty, kteří s EtherCATem zatím nedělali (a třeba by chtěli), tak trocha osvěty:
Distributed Clocks (DC) je mechanismus, kterým se sjednotí přesné časování všech připojených stanic - mastera i klientů.
Je to podstatné jak ve větších instalacích, kde už zpoždění dlouhého vedení není zanedbatelné (třeba na 100m kabelu to běžně udělá mikrosekundový nebo i větší rozdíl na začátku a na konci), a taky to umí kompenzovat různé rychlosti a zpoždění jednotlivých prvků.
Speciálně v případě LinuxCNC by to mělo být schopno prakticky kompletně eliminovat vliv latence, samozřejmě pokud bude v mezích, které se ještě kompenzovat dají.
Ten mechanismus DC zajistí přesnost časování na všech stanicích, ať jsou libovolně daleko, do nějakých 100ns. Docela úžasné.

Podobné přesnosti sladění hodin se případně dá v Ethernetové síti dosáhnout i metodou dle IEEE 1588, ale to jednak máloco umí, a hlavně je to komplikované. Kdežto DC je přímo integrální součástí EtherCATu, a měl by být chopný zpětně ovlivnit i časování mastera, tedy časování real-time threadu v LinuxCNC.

Mex píše: ↑6. 1. 2019, 4:52 Kdežto DC je přímo integrální součástí EtherCATu, a měl by být chopný zpětně ovlivnit i časování mastera, tedy časování real-time threadu v LinuxCNC.

Sice ano, ale laicky beru že musí proběhnout nějaká inicializace, kdy se ta síť "proběhne" a zjistí se podle nějakých časových značek jaký prvek má jaké zpoždění. Pak už je reálné, že když posíláš příkazy 4 servům naráz v periodě cca 1ms a ono jim to dojde každému jinak budou schopní práci zahájit společně. Ovšem má to opravdu v těchto časech smysl?

Já když posílám servu pozici tak systém funguje takto:
1 výpočet (master)
2 odeslání požadované polohy
3 příjem požadavku (servo)
4 realizování požadavku - odesílání aktuální polohy zpět
5 kontrola (master) zda poloha odpovídá výpočtu (návrat na 1)

Takže pokud to není pohyb za 1ms, tak master v každém cyklu sítě posílá servu další údaje podle toho jakou má zpětnou vazbu. Tím je schopen korigovat pohyb podle potřeby.

Lenze tym ze tam mas casove znacky bude pohyb vzdy synchrony, bez DC to bude nahodily proces, res bude chvilku trvat kym sa jednotlive serva dotiahnu.
Ono vlastne nebude to synchrone stale bude master na niekojo cakat a niekto bude v pred.

Jasně, můžeš DC nepoužívat, a pořád to bude pro většinu věcí "good enough".
Ale já si zrovna s EtherCATem hraju proto, že je to špičková průmyslová sběrnice, která umožňuje opravdu top řešení. Tak proč nevyužít jejího potenciálu, když je to tam pěkně vymyšlené?

V konkrétním případě použití Etherlab+nadstavba pro LinuxCNC je zrovna v tomhle asi zatím nějaká bota. Ale jinak je třeba ten Etherlab opravdu skvěle napsaný, klobouk dolů před tím německým autorem. Tak třeba se to povede nějak prokopnout a povede se tak komunitě vrátit aspoň nějaký přínos.

A musím říct, že mi dělá dobře když vidím jak se to, co se má stát za 1ms opravdu stane za 1.0ms. A ne za 0.9 nebo 1.1ms.

To atlan: ten EtherCAT je proklatě rychlej, takže i be DC to s těmi servy bude hýbat dobře.

Ale to DC má schopnost zpětně synchronizovat i server.
Je tam totiž použita taková myšlenka, nad kterou jsem ze začátku kroutil hlavou. Ale pak mi došlo, že je to naopak velmi chytré.
Zdrojem referenčních hodin pro časování celé sítě totiž není master, ale některý z klientů. Defaultně ten první v řetězci, ale dá se zvolit i jiný.

Zdá se to nelogické, ale není. Autoři vycházeli z myšlenky, že serverem může být třeba PC nebo PLC, které často žádné extra přesné časování neumí.
Ale klient (tj. slave) musí být tvořen specializovaným obvodem, a tak není problém do toho obvodu přidat i schopnost generování přesného časování.
No a pak se na tyto přesné referenční hodiny zasynchronizují ostatní klienti, ale i master.
Celá ta procedura není triviální, master při té synchronizaci měří parametry sítě, zpoždění jednotlivých klientů i vedení, a podle toho pak zavádí korekce do všech klientů.

Ta synchronizace na dobrém PC nemusí být potřebná. Ale pokud se použije LinuxCNC třeba na nějakém šupáckém HW (např. na RaspberryPi nebo jiné krabičce), tak tam problém se stabilitou už často docela je. A i tam to EtherCAT s DC elegantně vyřeší.

to jsem netusil
ale je to fikane a nakonec i logicke ty slave proste z pricipu vyzaduji spec. hw tak proc to nevyuzit

No ale problémem přece není v žádném případě přesnost nějakého časovacího synchronizačního obvodu , ale donutit Mastera (tedy PC) aby dostatečně rychle zareagoval na podnět (tedy přerušení časovače) a zpracoval požadované výpočty servocyklu

To PC má přece taky brutálně přesný časovač, ale donutit ho aby na popud tohoto časovače zareagoval (tedy obsloužil přerušení vzniklé tímto přesným časovačem) je ten hlavní problém vyžadující různé patche jádra atd aby bylo "Realtime-ové" a nehrálo si někde s něčím. (typicky nějaký ovladač grafiky, nebo jiné periferie který si myslí že milisekunda je zanedbatelný čas a preferuje dokončení své práce, která trvá přece "jen několik milisekund" před předáním kontroly zpět úloze vyžadující okamžitou reakci) když má obsloužit přerušení (přerušení způsobené přesným časovačem).

Jinými slovy: Přesný časovač (ať už je v PC nebo v dedikovaném hardware pověšeném na EtherCatu) je ti k ničemu, dokud ti na něj Master (tedy systém zodpovědný za generování trajektorie a zpětnovazebních smyček) nereaguje "okamžitě".

Toto by fungovalo pokud by řídící systém (Master) vydával rozkazy o trajektorii včetně časového razítka kdy má co být v jaké poloze ALE BEZ JAKÉKOLIV ZPĚTNÉ VAZBY.

LinuxCNC má v sobě spoustu těchto zpětných vazeb a důležitejší, než přesnost spuštění výpočtu je okamžitá reakce slave, který dokáže Masterovi odpovědět v jakém stavu se zrovna "PŘESNĚ TEĎ" (tedy přesně v čase kdy Master obsluhuje výpočet Servo Cyklu) nachází (bez ohledu na to jestli je tento čas Servo Cyklu přesně granulovaný nebo není).

Odpověď, že jsem se v nějakém konkrétním čase nacházel někde je na prd protože to "už bylo" (bez ohledu na to že ten konkrétní čas je brutálně přesně definován).

Jinými slovy: Teď jsem někde (bez ohledu na to kdy to Teď je dokud je to dostatečně často) a Teď vydávám korekční zásah (založený na aktuálních datech) v podobě nových příkazů, abych ureguloval co potřebuji.

Tímto samozřejmě netvrdím že časové značky z jednotlivých Slave zařízení EtherCatu a další synchronizační mechanismy nejsou užitečné, ale nejsou řešením toho myslím nejvetšího problému - tedy "Realtimeovosti" PC.

taky to desne zalezi na stylu rizeni
jestli servosmycku polohy dela system nebo se to necha delat servo a jen se to ze systemu prikazuje
v kazdem z pripadu vznika uplne jina choulostivost na nepresne casovani ktere zase vyplyva z architektury pouzitych pocitacu

kdyz bude v komunikaci velky jitter tak se nenaladi ta polohova pidka
jestlize bude polohova pidka v servu tak je to jednodussi a mene to ovlivni jitter mezi planovacem a servem a vysledek bude patrny stejne max na obrobku protoze na to system vlastne nereaguje regulaci pouze komparuje maximalni povolenou chybu ktera stejne za milisekundu nebude prilis velka

kolik by to ujede pri rychlosti dejmetomu 3m/min a casu 1ms? jestli dobre pocitam 0.05mm

Ano proto jsem psal že brutálně záleží na tom jestli je potřeba od LinuxCNC zpětnou vazbu, nebo ne.

robokop píše: ↑7. 1. 2019, 6:40 kolik by to ujede pri rychlosti dejmetomu 3m/min a casu 1ms? jestli dobre pocitam 0.05mm

PS: Pokud počítáš chybovou odchylku danou jitterem tak neřešíš rychlost ale maximální akceleraci.