Linuxcnc ethercat - EasyCAT + arduino

Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

8. 1. 2019, 6:04

Mex píše: 7. 1. 2019, 8:37 Dovolím si lehce nesouhlasit.
Pokud se zavede přesná synchronizace celého systému, tak pak na jitteru serveru příliš nezáleží (je-li v rozumných mezích, tedy řekněme max 15-25% času servoperiody). Server se sice dostane k obsluze nikoli třeba přesně v čase 5ms, ale možná v 4.9 nebo 5.1ms. Ale data, která dostane od jednotlivých komponent, byla přečtena v přesně daném okamžiku. A příkazy, které jim na základě toho server pošle, tak budou provedena opět v přesném čase.
Takže pak celý systém žije jakoby ve "virtuální časové realitě", protože i když se server dostane k lizu v nepřesném čase, tak si oprávněně může myslet, že je přesně tolik hodin, kolik teoreticky má být.
Ta "časová razítka" se totiž vztahují nejen na výstupy, ale i na vstupy.

EDIT: Já jsem ten příspěvek otevřel, odešel jsem si udělat večeři, a mezitím tady přibyly další posty. Tak možná trochu opakuju, co už zaznělo jinde.
Ale tam přece nejde o to zpracovat to v přesně definovaném čase ale zpracovat to HNED ve chvíli kdy tu přesnou polohu mám. Zavedení zpoždění celého servo-cyklu do zpětné vazby je podobná degradace jako zavedení vůle do posuvového šroubu.

Naopak ten jitter tam představuje naprosto zanedbatelnou chybovost protože je jedno kdy to zpracovávám pokud pracuji s AKTUÁLNÍMI DATY. Tedy ne s nějakými daty někde z minulosti byť je známo kdy to bylo a stejně tak nereaguji na to až v dalším servocyklu (byť označeno časovým razítkem kdy provést korekci) ale reaguji HNED (v rámci rychlosti zpracování výpočtů tedy v řádu ns nikoliv ms)

Jak říkám podle mě je ta výhoda toho přesného načasování důležitá především v systému který nepotřebje mít nějakou ostřejší zpětnou vazbu.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

8. 1. 2019, 8:39

Přenos po EtherCATu představuje průchod jednoho paketu sítí tam a zpět (za podmínky, že se data pro všechny klienty vejdou do jednoho paketu).
V tom stejném paketu jsou při vyslání povely pro jednotlivé klienty, když se ten paket vrátí zpět, tak tam jsou nasbírané odpovědi těch klientů.
Takže server vždy musí vyslat připravené příkazy, a teprve později dostane odpověď, tj. stav vstupů, změřený před příchodem toho paketu, tj. v minulé servoperiodě.
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

8. 1. 2019, 4:20

Mex píše: 8. 1. 2019, 8:39 Přenos po EtherCATu představuje průchod jednoho paketu sítí tam a zpět (za podmínky, že se data pro všechny klienty vejdou do jednoho paketu).
V tom stejném paketu jsou při vyslání povely pro jednotlivé klienty, když se ten paket vrátí zpět, tak tam jsou nasbírané odpovědi těch klientů.
Takže server vždy musí vyslat připravené příkazy, a teprve později dostane odpověď, tj. stav vstupů, změřený před příchodem toho paketu, tj. v minulé servoperiodě.
Aha. Takže je zpětná vazba zpožděna přesně o jeden ServoCyklus.
Mesa (tedy mám na mysli 5i20, 5i24 atd PCI verze) v rámci jedné obsluhy servo-cyklu napřed přečte z karty aktuální stavy všech "zařízení" StepGenů (ano i StepGen je řízen zpětnovazebně v polohovém módu), Quadrature counterů, IO Pinů atd. a na základě toho "ihned" spočítá nové příkazy a ty nahrne zpět do karty. (teprve poté předá řízení zpět systému a čeká na nové probuzení od časovače ServoThreadu)
A tím pádem bez ohledu na to jak moc přesně se PC k obsluze ServoThreadu dostal je výpočet tímto "jitterem" zatížen relativně minimálně.

Proto tu tak plaším a snažím se dobrat toho jak to vlastně funguje s tím EtherCat časováním a jaký to má dopad/přínos atd. na funování LinuxCNC tak jak ho provozuje většina "MESáků" a jak by to bylo s případnou implementací StepGenů do takového EtherCat zařízení.

Neberte to tedy prosím tak že se snažím prudit za každou cenu (i když to tak možná vypadá :roll: )
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

8. 1. 2019, 9:30

Trocha teorie jak to vidím já. Samozřejmě se můžu mýlit (mám jen názor, nikoli pravdu), rád o tom podebatuju s dalšími.

To je problém u obecně každého zpětnovazebního systému. U digitálních se projevuje víc než u analogových, u distribuovaných víc než u lokálních.
Vždy musím zjistit aktuální stav, na základě toho provést výpočet, a poslat nové zadání.

Takže nikdy ta korekce z principu nemůže být absolutně přesná, protože:
- získání původního stavu něco trvá - čím distribuovanější systém je, tím to trvá déle (zpoždění na vedení, na dlouhých drátech taky většinou musím zpomalit komunikaci)
- výpočet něco trvá - čím je složitější, tím to může trvat déle, navíc většinou ne konstantně, ale s jitterem
- odeslání povelu zpět zase může vnášet nějaké zpoždění, závislé na rozsahu

Sběrnicové řízení do toho případně ještě zavádí další zpoždění, a to periodu sběrnicového cyklu.

Jak s tím bojovat? Buď extenzívně (potřebuju víc obilí, tak osázím víc polí, potřebuju víc udělat tak najmu víc lidí atd.), nebo chytře (zavedu lepší postupy pěstování obilí, místo pracovníků nasadím automatizaci atd.).

U toho CNC to pak znamená buď nasadit rychlejší a ještě rychlejší metody komunikace a výpočtů, abych problém eliminoval hrubou silou. Nebo se s tím nějak naučit žít a naučit se to kompenzovat.

I u LinuxCNC na EtherCATu by se zřejmě dal použít model, že by se sběrnice pustila třeba 2x rychleji než servosmyčka v jádře LinuxCNC, takže bych jedním průchodem napřed získal zpětnou vazbu, pak by se dostalo k lizu jádro LinuCNC, provedlo výpočty, a druhým sběrnicovým cyklem by se to poslalo zpět.
Nebo zavést nějaké časové značky, se kterými budou čteny vstupy i realizovány výstupy. Pak se sice zpoždění nezmenší ale naopak spíš zvětší, ale bude přesně dané, predikovatelné a (snad) kompenzovatelné (tohle právě dělá to DC).

No a teď přichází na řadu ta základní otázka: vadí něčemu konstantní zpoždění jedné sběrnicové periody?
Kdyby se psal z gruntu nový systém, tak by se na to asi už při návrhu myslelo a kompenzace by tam byla zahrnuta. Prostě by se výpočet dělal nikoli z reálných dat, ale z naměřených dat, korigovaných o jejich předpokládanou změnu za jednu periodu.
Jestli to vadí v případě konkrétně LinuxCNC asi neumím úplně přesně odhadnout. Laickým, matematikou nepodloženým pohledem bych řekl, že ne. Délka servocyklu je stanovena tak, aby byla rychlejší než případné změny pohybu mechaniky. Ale třeba se pletu. Nebo třeba někdo popracuje (nebo už popracoval) na kompenzaci vlivu sběrnicového řízeni v LinuxCNC. Nakonec sběrnicové řízení je všeobecný trend.

Samozřejmě to případné zpoždění se projeví hlavně u zpětnovazebního systému, uzavíraného přes server. Takže víc třeba u analogových serv, řízených v rychlostním režimu podle externích pravítek. U serva v polohovém režimu to tak žhavé nebude, tam dokonce ani zpětnou vazbu prakticky nepotřebuju. Ne nadarmo je vždy u serv polohová řídicí smyčka nejpomalejší, kdežto rychlostní je několikanásobně rychlejší, a momentová opět ještě několikanásobně rychlejší než rychlostní.

A ještě poznámka k té zmínce, že Mesa používá zpětnovazební řízení i u úkolování stepgenů: no to je tak proto, protože se tím právě snaží kompenzovat jitter toho zpracování a případnou odchylku hodin systému a hodin Mesy. V případě nějakého systému s přesným časováním by to nebylo třeba.
Takže kdyby se povedlo udělat to řízení krokáčů pomocí EtherCATu nějakým modulem, který bude umět DC, tak tam by se tam nic takového dělat nemuselo. Prostě by se poslala nová požadovaná poloha a bylo by jasné, že to na ní za dobu další servoperiody dojede.

EDIT: Ještě poznámka - ta kompenzace konstatního zpoždění je vlastně variace na FeedForward. Ale na rozdíl o běžného FeedForwardu, který závisí na mechanických vlastnostech pohonu, se to tady dá kompenzovat přesně, jasně definovaným výpočtem.
Uživatelský avatar
Cjuz
Příspěvky: 2422
Registrován: 17. 2. 2013, 6:27
Bydliště: Předklášteří
Kontaktovat uživatele:

9. 1. 2019, 7:21

Využití synchronizace s DC u něžného CNC pro účel zpětné vazby mi přijde poměrně neodůvodněná.
Osy musí umět jet tam kam je pošlu aniž bych potřeboval do procesu zasahovat.
Snad pokud bych měl dvě serva na portál, tak možná, abych puls STEP odeslal opravdu přesně oběma naráz, ale i tak rozdíl obdržení dat v rámci jedné periody je nepatrný.

Já to reálně použil jen párkrát, kdy jedna osa byla svázaná momentově nebo polohově s jinou.
Pak při pohybu master osy musí systém sledovat její polohu a stále korigovat pohyb slave osy.

Pro hobíka dává nevíce smysl zařízení které produkuje STEP/DIR, má vstupy a výstupy a je spolehlivější a rychlejší než LPT a zároveň je levnější než MESA. A to je úkol hodný vynálezce.
Na konci poznávacího procesu je omyl zcela vyvrácen a my nevíme nic. Zato to víme správně.
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

9. 1. 2019, 3:02

Cjuz píše: 9. 1. 2019, 7:21 Využití synchronizace s DC u něžného CNC pro účel zpětné vazby mi přijde poměrně neodůvodněná. ...
No jo, no. Kdy já mám raději "good" než "good enough".
Teda pokud jsi skutečně neměl na mysli "něžné CNC", tam je to možná jinak. ;-)
Cjuz píše: 9. 1. 2019, 7:21 Pro hobíka dává nevíce smysl zařízení které produkuje STEP/DIR, má vstupy a výstupy a je spolehlivější a rychlejší než LPT a zároveň je levnější než MESA. A to je úkol hodný vynálezce.
Možná jo. I když trend jde spíš ke sběrnicovému řízení, ten DIR/STEP je přece jen takový trochu relikt minulosti. Ne nadarmo se mu často v odborné literatuře říká "stepper motor interface". Na ty krokáče je to fajn, tam to celkem dává smysl. Ale u serva je to přece jen trochu omezující.
Ta sběrnicová serva o sobě dokážou nabonzovat kde co - teplotu, proud, moment, aktuální výkon, technický stav atd.

Pokud se mi povede (a to doufám, že povede) udělat nějaký ten univerzální modul s EtherCATem a procesorem, tak pak by to mohlo sloužit jako univerzální interface pro CNC, kde k systému by to bylo připojeno tím EtherCATem, z druhé strany by to pak mělo celkem cokoli. Například i ten CANbus, jak tady o něm byla řeč v jiném vlákně. Já jsem implementaci CANbusu docela studoval kvůli jednomu projektu, na který nedošlo (zákazník to odpískal, i když možná jenom dočasně). Takže celkem mám představu o náročnosti a vím, že by se to udělat dalo.

Zatím jsem se díval na nějaké ty examply k modulu, co mi přinesl Ježíšek. A je to bída a utrpení, tímhle bych řídil možná tak dávkování žrádla pro domácí kočku. Je třeba to napsat kompletně zgruntu znova a pořádně.

Ještě jedna historka z natáčení: včera jsem zabil mnoho hodin pokusy o zprovoznění frekvenčního měniče s EtherCATem. Je to měnič od hodně renomované firmy, tu komunikační kartu do toho ale dělá nějaká nezávislá americká firma, oni to pak prodávají pod svým jménem.
Ani za prase to nechtělo chodit. Pod EtherCAT Configuratorem od Beckhoffu se to povedlo dostat do OPu, ale nedalo se to řídit. Pod Ethercatem v LinuxCNC se mi to ani do toho OPu nepovedlo dostat. Tak jsem ze zoufalství stáhl nový firmware - a ejhle, EtherCAT z toho zařízení úplně zmizel. Ta karta je multiprotokolová, tak tam zbyly jen ty ostatní protokoly, EtherCAT zrušili. Díval jsem se pak do historie verzí, a skutečně to tam měli uvedeno.
Tak to se američtí programátoři a japonští testeři moc nevyznamenali. Testeři proto, že pustili do světa evidentně špatný SW. A programátoři proto, že to nedokázali spravit a tak to to raději vyřadili.
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

9. 1. 2019, 5:27

Mex píše: 8. 1. 2019, 9:30 A ještě poznámka k té zmínce, že Mesa používá zpětnovazební řízení i u úkolování stepgenů: no to je tak proto, protože se tím právě snaží kompenzovat jitter toho zpracování a případnou odchylku hodin systému a hodin Mesy. V případě nějakého systému s přesným časováním by to nebylo třeba.
Ano.. netvrdím, že StepGen komponenta pro svou činnost nezbytně nutně potřebuje zpětnou vazbu. Zcela určitě lze napsat modul StepGenu bez zpětné vazby (jediná nevýhoda je absence FPU ve většině námi oblíbených jednodušších MCU, takže by to taky neblo uplně triviální, ale jít by to mělo). Jen jsem to zmínil jako zajímavost že v MESA Implementaci StepGenu tam ta zpětná vazba je. Já osobně si dovedu představit že ve většině případů tak jak CNC provozuejme ta zpětná vazba (tedy ta které by vadilo zpoždění jednoho ServoCyklu) pobřeba není a určitě by bylo naprosto suprové kdyby se podařilo udělat nějaké komponenty skutečně 100% kompatibilní s LinuxCNC (bez ohledu na to jestli to splňuje na 101% kompatibilitu s nějakou EtherCat standardizací - pokud vůbec něco takového existuje).
Co jsem tak narychlo koukal, tak je (minimálně dle mého dojmu z tohoto letmého pokusu o zjištění jak se věci mají) většina zatím spíše zmatek ve stylu toho mněniče co jsi zkoušel rozchodit. Stejně tak i oficiální podpora toho EtherCatu v LinuxCNC zamrzla na nějakém pitomém rozpour GPL licence s požadavkem snad přímo Beckhoffa nebo tak.
Mex píše: 8. 1. 2019, 9:30 Zatím jsem se díval na nějaké ty examply k modulu, co mi přinesl Ježíšek. A je to bída a utrpení, tímhle bych řídil možná tak dávkování žrádla pro domácí kočku. Je třeba to napsat kompletně zgruntu znova a pořádně.
No přesně takový dojem to na mě zatím dělalo :(

Držím palce a těším se na jakékoliv další info o pokroku. :!:
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

9. 1. 2019, 5:41

CZ_Pascal píše: 9. 1. 2019, 5:27 Stejně tak i oficiální podpora toho EtherCatu v LinuxCNC zamrzla na nějakém pitomém rozpour GPL licence s požadavkem snad přímo Beckhoffa nebo tak.
Ale! To jsem netušil, že je tam nějaký licenční/právní problém.
Díky za info. Kdybys měl nějaký konkrétní odkaz, tak to bych si moc rád přečetl, abych věděl, jak moc hluboký průser to je.
To je skutečně nemilé. :(
Díky.
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

9. 1. 2019, 6:23

Mňo odkaz ti bohužel nenajdu protože to bylo v nějaké z milionu diskuzí co jsem narychlo prolítl ve snaze najít nějaký ucelenější oficiálnější popis jak je vlastně podpora toho EtherCatu v LinuxCNC implementována. Všimni si že v "nativní" distribuci tato podpora předinstalována není.

GPL je docle striktní v tom, že cokoliv je v GPL je opravdu bez omezení nutno poskytnout zdrojové kódy bez nároku na finanční odměnu když někdo jiný na jejich základě spáše něco užitečného atd.

Co jsem tak narychlo pochopil tak Beckhoff? nebo kdo podmiňuje použití nějké té EtherCat implementace členstvím v nějakém tom jakože "klubu". Přesto že je to jen "formalita" a je to bezplatné, už to nějako není slučitelné s GPL nebo co :roll: .

Takže rozhodně se nemusíš bát, že bys porušil použitím nějakých těchto informací nebo zdrojů nějaké právní cosi, ale teoreticky to možná/snad asi nesmíš prohlásit jako GPL ? Nevím.. popravdě tady tyto free licenční srandy neprožívám, ale bohužel se staly překážkou toho, abys rovnou v čerstvě nainstalovaném LinuxCNC měl rovnou i "nativní" podporu EtherCatu.

Vyhrazuji si právo mýliti se v tom kdo nebo za jakých podmínek odmítl cosi v souvislosti s GPL a EtherCat v LinuxCNC, protože to nebyla ta informace kterou jsem hledal a jako takovou ji mám poměrně nejstě a mlhavě uloženu v mozkovně, nicméně důsledek toho je nemilý :cry:
Mex
Příspěvky: 10288
Registrován: 6. 2. 2014, 10:29

9. 1. 2019, 6:48

Děkuji.

Důvod nepřítomnosti EtherCATu v defaultní distribuci LinuxCNC může mít i zcela prozaický důvod v tom, že ten Etherlab (odkud použitý EtherCAT server pochází) je zcela nezávislý projekt, který vznikl jako součást komplexního systému, něco na způsob open-source LabView.
Jen pak někdo šikovný (Sascha Ittnerr, zní to rusky ale to Němec) napsal můstek mezi těmi nezávislými produkty.
Uživatelský avatar
CZ_Pascal
Příspěvky: 870
Registrován: 14. 1. 2008, 8:24
Bydliště: Brno

9. 1. 2019, 7:14

https://www.etherlab.org/en/ethercat/index.php
License

All the source code available through IgH is licensed under the GPLv2 license.
Notice

The license above concerns the source code only. Using the EtherCAT technology and brand is only permitted in compliance with the industrial property and similar rights of Beckhoff Automation GmbH.
Ono je to v podstatě asi jedno, ale předpokládám že tady ta poznámka v "notice" jinými slovy říká to co se v té diskuzi probíralo nějako více proč EtherCAT vlastně není (nemůže/nechce být) v tom LinuxCNC "nativně" ale konkrétně tu diskuzi kde to už fakt nedohledám.
Uživatelský avatar
zz912
Příspěvky: 1348
Registrován: 25. 5. 2008, 7:16

20. 6. 2020, 8:11

robokop píše: 1. 11. 2017, 7:37 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
Patří mezi tyto karty 8139D ? " (or compatible) "
RTL_8139D.jpg
Rozhodně nechci v ničem experimentovat, nic zkoušet, ale zase ať nesháním něco, co už mám doma. Nenechte se rušit Tím psem, můj syn prohlásil, že na té fotce musí být. :-)
LinuxCNC - MESA 7i96
zz912.webnode.cz
Uživatelský avatar
robokop
Site Admin
Příspěvky: 22371
Registrován: 10. 7. 2006, 12:12
Bydliště: Praha
Kontaktovat uživatele:

20. 6. 2020, 11:01

Mrkni na web vyvojaru zda ji tam nepridali
Vsechna prava na chyby vyhrazena (E)
Odpovědět

Zpět na „LinuxCNC - drive pod nazvem EMC2“