Pokud bych měl (hypoteticky) potřebu velkého množství vstupů/výstupů, nebo bych měl některé vstupy/výstupy hodně vzdálené od PC.
Tak bych si za síťovou kartu pro MESU dal switch a do něho zapojil několik MESA karet, třeba:
7i93
http://store.mesanet.com/index.php?rout ... uct_id=341
+ nějaké to oddělení.
Obdobu této myšlenky používají u nás chlapi v práci, akorát používají Siemens PLC + switch a roztahají si tak profinet po celé lince. Lze takto uvažovat i u ethernetových MESA karet + Linux CNC?
Jde mi o to, že v práci máme sice na větších linkách i stovky vstupů a výstupů, ale ovládáme "jen" ventily od válečků a koncové snímače (hódně zjednodušeně). Ovšem reakční rychlost PLC+sítě není potřeba nějak vysoká.
Na druhé straně řízení servomotorů / krokáčů pomocí STEP/DIR má trochu větší nároky na řízení, než jen "válec vysunut/zasunut"
Vím, že vzhledem k tomu, že začínám, tak předbíhám. Ovšem zajímá mě potenciál Linux CNC.
Pokud by to tak šlo, budu mít větší motivaci ke studiu Linux CNC a když ne, nebudu si aspoň kreslit vzdušné zámky.
Linux CNC + několik ethernetových MESA karet
Konečnou odpověď nechám na někom se zkušeností.zz912 píše: ↑19. 3. 2020, 7:18 Pokud bych měl (hypoteticky) potřebu velkého množství vstupů/výstupů, nebo bych měl některé vstupy/výstupy hodně vzdálené od PC.
Tak bych si za síťovou kartu pro MESU dal switch a do něho zapojil několik MESA karet, třeba:
7i93
http://store.mesanet.com/index.php?rout ... uct_id=341
+ nějaké to oddělení.
Obdobu této myšlenky používají u nás chlapi v práci, akorát používají Siemens PLC + switch a roztahají si tak profinet po celé lince. Lze takto uvažovat i u ethernetových MESA karet + Linux CNC?
Jde mi o to, že v práci máme sice na větších linkách i stovky vstupů a výstupů, ale ovládáme "jen" ventily od válečků a koncové snímače (hódně zjednodušeně). Ovšem reakční rychlost PLC+sítě není potřeba nějak vysoká.
Na druhé straně řízení servomotorů / krokáčů pomocí STEP/DIR má trochu větší nároky na řízení, než jen "válec vysunut/zasunut"
Vím, že vzhledem k tomu, že začínám, tak předbíhám. Ovšem zajímá mě potenciál Linux CNC.
Pokud by to tak šlo, budu mít větší motivaci ke studiu Linux CNC a když ne, nebudu si aspoň kreslit vzdušné zámky.
Switch do komunikace vnese další prodlevu a možnost kolize při komunikaci. Záleží i na switchi a jeho nastavení. Mají několik režimů zpracování ethernet rámců.
Obecně o ethernetu: https://en.wikipedia.org/wiki/Ethernet_frame
- používá rámce
- každý rámec obsahuje hlavičku, data a kontrolní součet
- k adresaci používá tzv. MAC adresy - o délce 6 bytů, zapisuje se obvykle v šestnáckové soustavě odděleno po bytech dvojtečkou 00:00:be:ef:ca:1f tato adresa musí být v každém jedinečná v části sítě, která spolu komunikuje bez routeru (jen switche, huby, bridge - prakticky se používají jen switche)
- hlavička rámce obsahuje cílovou a zdrojovou MAC adresu (je důležité, že obě, uvidíme později).
- existují speciální MAC adresy - broadcast (ff:ff:ff:ff:ff:ff) - doručuje se na všechna zařízení - ostatní nejsou pro nás důležité
Switch
- má "porty" - tj ty konektory, kam se připojují kabely, ty fungují jako full duplex - mohou zároveň přijímat i odesílat
- má paměť, do které si ukládá, na kterém portu viděl jakou MAC adresu, ta má ovšem omezenou velikost, ne nějakou normou, ale výrobcem, měla by se vypráznit (část), pokud vypojíš kabel
- má nějakou další paměť, do které si ukládá zpracovávané rámce
- paměť se maže při vypnutí
Teď pohádka o switchi"
čerstvě zapnutý switch, nějaká připojená zařízení
portem 1 přichází rámec of MAC_1 pro MAC_2
switch přijme hlavičku
podívá se na zdrojovou adresu MAC_1 a uloží si ji do tabulky vazbu port_1-MAC_1
podívá se na cílovou adresu MAC_2
podívá se do tabulky port-MAC a najde leda prd
protože nezjistil kudy, pošle rámec všemy porty (mimo toho , kterým přišel) pryč
a portem 3 přichází další rámec od MAC_3 pro MAC_1
zase vytahne adresy z hlavičky
uloží si vazbu MAC_3-port_3
mrkne do tabulky a najde MAC_na port_1
a pošle rámec jen tím jedním port_1 pryč
a přes port 2 přichází rámec MAC_2 -> MAC_3
a zase stejný postup, přidání do tabulky + odeslání známým portem
Co když přes port_1 přijde rámec MAC_12 -> MAC_3 ?
žádná křeč, za jedním portem může být víc MAC address (třeba další switch+zařízení)
Se zmiňovanou broadcast MAC adresou se zachází tak, že se nikam neukládá a rámce na ni směřované se rozešlou vždy všemi porty (to samé s multicast - broadcast je speciální případ multicastu)
Tohle funguje plně duplexně na více portech zároveň.
Potíže nastanou
- zařízení (MAC adres) je moc, a přeplní se paměť. Je to málo pravděpodobné, bude záležet na implementaci, pravděpodobně se budou nejstarší záznamy přepisovat novějšími. Neznámé MAC se budou posílat všemy porty ven, to nechceme.
- moc zařízení chce najednou posílat data na jednu MAC - dokud vyrovnávací paměť ve switchi stačí, požadavky se řetězí za sebe, jinak se rámce, které se nevejdou zahazují, tohle by mohl být problém s MESA kartama k jednomu PC u "hloupých" switchů buffer nebývá moc velký, na druhou stranu 100Mbit, nebo 1Gbit jsou poměrně propustná média.
S propustností souvisí ještě dva údaje switche, kerými se někteří moc nechlubí
- propustnost na backplane dva 100Mbit porty při full duplex komunikaci na plné pecky potřebují 200Mbit propustnost backplane. Více portů znamená větší požadovanou propustnost. Někteří šetří a počítají s tím, že charakter provozu bude takový, že k plnému vytížení všech portů nedojde
- propustnost packet per second - nejde jen o rychlost dat, ale mnoho malých rámců - hlavička + pár bytů dat přináší nemalou režii - příjem hlavičky, hledání portu. Přenést 50Mbit/s v rámcích velkých 1,5 kB je mnohem snažší, než to samé po 100 bytech
A k tomu všemu switche (ty chytřejší) mohou mít nastaveno jak s rámcem nakládají
https://community.fs.com/blog/compariso ... ching.html
- tak jak je popsáno - po příjmu hlavičky sypou data pryč tzv cut through
- store and forward - přijmou celý rámec, zkontrolují CRC, pokud je OK, posílají dál. Pokud CRC nevychází rámec zahodí. - to vnáší další prodlevu
--
Všechno je snadné, než to zkusíš sám.
Všechno je snadné, než to zkusíš sám.
Zdržení na switchi eliminuješ, ale zůstane problém, jak OS dokáže komunikovat s více MESA kartama. Ty řídicí vlákna se budou muset poprat o procesorový čas.
Já hlavně nevím, jestli zdržení na switchi vůbec představuje problém, nebo jestli dřív dojdou zdroje na řídicím PC.
--
Všechno je snadné, než to zkusíš sám.
Všechno je snadné, než to zkusíš sám.
Napřed krátká odpověď: Ano, je to možné to takhle natahat a řídit mraky I/O.
Teď dlouhá odpověď: LinuxCNC komunikuje s Mesou v servo-cyklu, tedy defaultně jednou za milisekundu. Komunikace po Ethernetu jede na 100 Mbit/s. Na straně Mesy komunikuje FPGA, které je velmi rychlé, takže tam je latence (zpoždění) velmi malá.
Komunikace je poměrně efektivní. Na Ethernetu jsem to teda ještě nezkoumal, ale kdysi jsem se tím dost zabýval na Mese po LPT. Je tady o tom vlákno. A ty přenášené informace budou zřejmě stejné, ať je ta Mesa připojená přes Ethernet, PCI nebo LPT.
Navíc nikde není psáno, že servo-cyklus musí být zrovna 1ms. Je možné ho pustit pomaleji, podobně, jako se to běžně používá jinde v automatizaci (tam se často běžně cyklus 10ms nebo i víc).
Ale ještě lepší varianta je udělat ty cykly dva, a to různé rychlé (LinuxCNC umí defaultně až 3, každý s jinou rychlostí). Takže si můžeš udělat rychlý pro pohony, a pak třeba pomalejší pro nějaké miliony I/O. Mohlo by to běžet jak na jedné Ethernetové kartě, tak na více kartách.
No a další (levnější) možnost je použít expandéry. Mesa má svůj vlastní protokol SmartSerial, kterým se dají propojit řídicí karty (tedy např. i Mesa 7i96) s další nebo dalšími podřízenými kartami. Ta řídicí tam pak funguje inteligentní koncentrátor. Ten SmartSerial v tomto případě jede po RS422, takže může být v klidu i na velmi dlouhém vedení. Navíc je to po RS422 dost levná varianta.
SmartSerial se tady dost zabýval Fupe, má tady na to někde vlákno. Dost to tehdy prozkoumal (dokumentace od Mesy je poměrně neaktuální). Na to SS by se případně daly udělat i vlastní I/O desky. Fupe s tím myslím nějak experimentoval.
Plánuju někdy výhledově udělat oddělovací kartu pro ten 26-pin konektor na kartě 7i96. A jako jedna z věcí tam bude interface pro 4 expandéry SmartSerial.
No a úplně jinak se takové věci dají taky řešit třeba po EtherCATu. Tj. po speciální odrůdě Ethernetu pro průmyslové řízení, pro kterou má LinuxCNC slušnou podporu. V případě potřeby by se to dalo dokonce kombinovat, použít na jednom systému jak Mesu, tak EtherCAT. Pak by bylo dobré to mít na dvou Ethernetových kartách, i když čistě teoreticky by to mohlo jet i jen na jedné.
Teď dlouhá odpověď: LinuxCNC komunikuje s Mesou v servo-cyklu, tedy defaultně jednou za milisekundu. Komunikace po Ethernetu jede na 100 Mbit/s. Na straně Mesy komunikuje FPGA, které je velmi rychlé, takže tam je latence (zpoždění) velmi malá.
Komunikace je poměrně efektivní. Na Ethernetu jsem to teda ještě nezkoumal, ale kdysi jsem se tím dost zabýval na Mese po LPT. Je tady o tom vlákno. A ty přenášené informace budou zřejmě stejné, ať je ta Mesa připojená přes Ethernet, PCI nebo LPT.
Navíc nikde není psáno, že servo-cyklus musí být zrovna 1ms. Je možné ho pustit pomaleji, podobně, jako se to běžně používá jinde v automatizaci (tam se často běžně cyklus 10ms nebo i víc).
Ale ještě lepší varianta je udělat ty cykly dva, a to různé rychlé (LinuxCNC umí defaultně až 3, každý s jinou rychlostí). Takže si můžeš udělat rychlý pro pohony, a pak třeba pomalejší pro nějaké miliony I/O. Mohlo by to běžet jak na jedné Ethernetové kartě, tak na více kartách.
No a další (levnější) možnost je použít expandéry. Mesa má svůj vlastní protokol SmartSerial, kterým se dají propojit řídicí karty (tedy např. i Mesa 7i96) s další nebo dalšími podřízenými kartami. Ta řídicí tam pak funguje inteligentní koncentrátor. Ten SmartSerial v tomto případě jede po RS422, takže může být v klidu i na velmi dlouhém vedení. Navíc je to po RS422 dost levná varianta.
SmartSerial se tady dost zabýval Fupe, má tady na to někde vlákno. Dost to tehdy prozkoumal (dokumentace od Mesy je poměrně neaktuální). Na to SS by se případně daly udělat i vlastní I/O desky. Fupe s tím myslím nějak experimentoval.
Plánuju někdy výhledově udělat oddělovací kartu pro ten 26-pin konektor na kartě 7i96. A jako jedna z věcí tam bude interface pro 4 expandéry SmartSerial.
No a úplně jinak se takové věci dají taky řešit třeba po EtherCATu. Tj. po speciální odrůdě Ethernetu pro průmyslové řízení, pro kterou má LinuxCNC slušnou podporu. V případě potřeby by se to dalo dokonce kombinovat, použít na jednom systému jak Mesu, tak EtherCAT. Pak by bylo dobré to mít na dvou Ethernetových kartách, i když čistě teoreticky by to mohlo jet i jen na jedné.
Ještě bych měl dotaz, co jsou ty ksandy ?
viewtopic.php?t=34405
viewtopic.php?t=33036&hilit=ksandy+uz+n ... t&start=30
Už se o tom tady robokop párkrát zmiňoval, že s tím měl problémy.
viewtopic.php?t=34405
+robokop píše: ↑22. 1. 2020, 11:11 Tak tech dratu je opravdu treba 4 x 50pin ksanda. S tim ze do matice to muze a nemusi jit
Pak bys mohl samozrejme mezi to vyrobit tistak a nejak to multiplexovat a treba pouzit teensy coz je vec s kterou nema dobrou zkusenost. Pouzival jsem to asi 3 roky a pak nahradil pridavnou mesou a uz o tom nevim.
viewtopic.php?t=33036&hilit=ksandy+uz+n ... t&start=30
Už se o tom tady robokop párkrát zmiňoval, že s tím měl problémy.
Naposledy upravil(a) zz912 dne 19. 3. 2020, 2:21, celkem upraveno 1 x.
LinuxCNC - MESA 7i96
zz912.webnode.cz
zz912.webnode.cz
Ono ty kšandy umí pěkně potrápit. Na jednom zařízení před cca 25 lety se po nějaké době provozu začaly objevovat chyby. Servisáci od výrobce z GB vždy přijeli, se vším pokvedlali, ono se to chytlo a jelo. Kluci odjeli a po čase zase znova problém. Když ten strojek doputoval k nám do firmy, tak jsem se do toho nějak zaagnažoval. Prostě jsem chtěl zjistit, kde je to úzké místo. Když jsem si půjčil od bab z účtárny fén a začal selektivně nahřívat, došel jsem až k řídícímu PC. Jenže řízení kleklo a pc fungovalo i s win 3,x dále. Takže řídící karta, z které šla kšanda. To už jsem ukecal zubaře, ať mi půjčí, nebo spíše věnuje zbytek chladícího spreje. Tak jsem tu kartu selektivně ochlazoval a ejhle konektor na kšandě. Jelikož lis v té době nikdo neměl po ruce, svěrák to vyřešil. Bylo to málo zařezané a jak se teplem zvětšil objem izolace, tak nožový kontakt byl odtlačený od vodiče a problém byl na světě. O té doby to bylo v cajku.
-
robokop
- Site Admin
- Příspěvky: 22394
- Registrován: 10. 7. 2006, 12:12
- Bydliště: Praha
- Kontaktovat uživatele:
No kombinacky uz by to nezhorsili. Novej konektor jeste nenakrimpovanej a kdyz jsem do nej zasunul samotnej pin tak gravitaci sam od sebe vypadnul. Chybka byla asi nekde pri postupovem lisovani dutinek...
Vsechna prava na chyby vyhrazena (E)