Vlákno názorů k článku
Jádro bude mít subsystém pro řízení pohybu od František Ryšánek - Možná bych do záznamu dodal, že jsem během...

Základní high-level struktura Motion Control systému zas tak složitá není. Nahoře je Trajectory Generator, který podle aplikačně požadovaného pohybu časově ekvidistantními hodnotami požadované polohy (případně navíc i rychlosti a zrychlení) krmí "něco co se snaží motor udržet v těchto hodnotách". Nejčastěji servo-controller, který obsahuje kaskádu PID/PI/P regulátorů pro proud, rychlost a polohu. Nejdůležitější je vstup do vnější smyčky polohy, a prípadně stačí i jen ten. Pokud jsou větší požadavky na dynamiku, je dobré použít i informaci o rychlosti a zrychlení pro tzv. feed-forward do vnitřních smyček.

Krokový motor je trochu speciální a jednodušší případ, tam odpadají PID regulátory, a stačí generovat správnou hustotu (mikro-)kroků, na což je potřeba specializovaný HW případně FPGA. A pak záleží jestli takový HW rovnou obsahuje Trajectory Generator, a on tam alespoň nějaký být musí. To jsou pak ty různě ASICy. Ale krokové motory mají jedinou výhodu, že jsou levné a dají se levně řídit bez zpětnovazebních snímačů, ale jinak jsou s nimi samé problémy.

Trik je vždy v implementačních omezeních, které se s vývojem techniky různě mění, a samozřejmě pro jednoduché aplikace stačí málo. Když tohle všechno jde udělat na jednom MCU/CPU na plné rychlosti, tak je to celkem jednoduché.

Podle dynamické náročnosti aplikace je v praxi regulační smyčka proudu (a u PMSM motoru FoC Park/Clark) někde na 10-100kHz, rychlost 1-10kHz a poloha 250Hz-10kHz. Trajectory Generator obvykle jede stejně rychle jako regulátor polohy, ale je možné dělat mezi tím vhodnou interpolaci.

Nejsnazší je všechno tohle nacpat do jednoho MCU, což celkem jde, případně i pro více pohonů zároveň a pak to běží rovnou sychnronně pro interpolované pohyby. Ale to už není úplně praktické jako generický produkt, protože potřebujete škálovat výkonovou část od 100W po 10+kW individuálně pro jednotlivé osy.

Pro jednoduché aplikace, kde se vystačí s pohybem bod-bod s omezením rychlosti a zrychlení se dá vše implementovat v jednom MCU, a ovládá se to nějakým klidně pomalým asynchronním rozhraním (UART na pár desítkách kb/s), a není to moc zajímavé. DS402 to standrdizuje jako Profile Position Mode.

Pro cokoliv složitějšího se celkem ustálilo řešení, že Trajectory Generator je centralizovaný v nějakém PC/PLC a setpointy polohy (případně i rychlosti, zrychlení) krmí do jednotlivých výkonových jednotek pohonů pomocí rychlé komunikace, dneska už většinou na bázi Ethernetu, kde si každý tradiční vendor jede své, ale obrovskou část trhu se s tisíci různých výrobců urval EtherCAT, protože je je přiměřeně otevřený a fakt dobře vymyšlený. Tahle komunikace obvykle běží na 250Hz až 10kHz. Výhoda je, že v tom jednom místě mám všechna data nejen ze všech z pohonů, ale i z dalších vstupů/senzorů/al­goritmů, a můžu dělat sychronizované/in­terpolované pohyby napříč osami nezávisle na tom, jaké výkonové jednotky použiju. DS402 to standrdizuje jako Cyclic Synchronous Position (případně ... Velocity / Torque) Mode.

A tady se dostáváme k tomu, že tohle už není problém provozovat na dobrém PC s Linuxem a PREEMPT-RT, kde se těží z velkého výkonu PC, a dá se dostat i na těch 10kHz, a používá se to. Buď s něčím jako Codesys soft-PLC, nebo s vlastním softwarem. Častěji to je nějaké klasické PLC, ale u vyšších řad to stejně často je PC-class hardware, akorát to zvenku není poznat.

Asi je dobré dodat, že tyhle aplikace vždy jednou ve fixním timingu: přečíst všechny vstupy, spočítat co s tím, zapsat všechny výstupy (s intervalem někde mezi 4ms a 100us). Takže se neřeší nějaké eventy a IRQ. U toho EtherCATu se pošle v minimálním případě dokonce jen jeden Ethernet frame za cyklus, který obslouží celou síť - zapíše všechny výstupy a přečte všechny vstupy. Za těch 100us se o moc víc stihnout nedá.

Tohle je řešení pro různé manipulátory, balicí stroje, semiconductor manufacturing, ale viděl jsem takové řešení i u lékařského CT (dokonce s tím EtherCATem + PC s VxWorks). Dá se tak řešit i řízení klasických 6-osých průmyslových robotů, ale to je spíš výjimka pro speciální účely, jinak si vendoři drží svoje specifické řešení a aplikační prostředí.

A co se týká "vrchní", aplikační strany toho Trajectory Generatoru, tak v PLC světě napříč vendory se celkem ustálil PLCopen MC standard, jehož specifikace jsou kupodivu volně dostupné: https://plcopen.org/downloads?field_technical_activity_target_id=63 - a z toho se dají poskládat složitější aplikace včetně sychronizovaných os, elektronických vaček a interpolovaných víceosých pohybů. Úplné speciality pak vedou na úplně speciální Trajectory Generator. V případě CNC strojů se Trajectory Generator krmí nějakým tím G-kódem.

Takže, co z toho chcete dávat do Linux kernelu a proč zrovna to? :-)

Předně děkuji za bezvadný a vyvážený přednes, trochu jste mi otevřel oči :-)

> Takže, co z toho chcete dávat do Linux kernelu a proč zrovna to? :-)

No jestli jede řídící task v user space v taktu 10 kHz s garantovanou přiměřenou latencí spuštění jednotlivé periody, tak už asi nic :-)

Nebo nic moc. Dovedu vágně navrhnout nouzové zastavení při nějakém safety-kritickém stavu (dojezd na kocový spínač ke kterému nemělo nikdy dojít apod.)
Už jste podrobně popsal, že to s těmi safety funkcemi není zdaleka jednoduché. Uveďte do bezpečného stavu mechanický systém, kde vám různé hmoty rotují, mávají tam ramena apod.

Osobně jsem si před lety vyzkoušel v RTAI na PC asi 5 kHz, jenom akademicky tikat GPIO výstupem, koukal jsem na to skopem a tuším jsem měl i nějaký odposlech - bylo znát, že nějaký jitter už tam je.
Tuším ten RTAI task tehdy běžel v kernelu.

Tuším to bylo v době příchodu PCI-e do PC čipsetů (i915 nebo tak něco kolem) včetně překlopení doručování IRQ na message-signaled mechanismus. Tehdejší HubLink byl hubený, takže trochu zásadnější konkurující provoz na sběrnici mezi severním a jižním kusem čipsetu byl dost znát na latencích obsluhy IRQ od systémového časovače (ten je v south bridgi) a ostatně i na latencích I/O operací s LPT nebo GPIO porty.

Na PCčkách obecně není problém s hrubým výpočetním výkonem, ale na běžném PC hardwaru dovedou nepříjemně překvapit latence různého původu. Jako že ve stovkách mikrosekund, na konkrétních historických modelech hardwaru údajně i hůř. Když vyřešíte process scheduling (RT podpora v OS) a prioritu RT tasku a IRQ, a SMI/SMM a C-stavy, zbývá Vám potenciální tlačenice na PCI-e = jde o to postavit systém tak, aby k tlačenici nedocházelo. "Technologický pokrok" sám o sobě se bohužel neprojevuje nějakým přímo úměrným zkracováním latencí. Nevhodnou skladbou HW a OS je i dnes možné, dostat se s latencemi IRQ a IO "do úzkých", ale naštěstí se s tím dá pracovat.

Pak je taky možné, nechat běžet časově kritické vlákno řídící úlohy "nebržděně" = v těsné smyčce, mimo kompetenci plánovače úloh. Vyhradit řídící úloze celé jádro vícejádrového CPU. Jsou k vidění hybridní softwarová RT řešení, kde se běžnému OS (Windows/Linux) odebere jedno či více jader CPU, a rozjede se na nich proprietární "real-time executive engine". Tento má samozřejmě přístup do fyzického adresního prostoru, využije nastavení PCI sběrnice zděděné od hostitelského "obecného OS", může obsluhovat některé interrupty (má drivery pro konkrétní periferie) apod.

Ano krokové motory vypadají na první pohled jednoduše k použití. Ale umí taky překvapit reálnými vlastnostmi :-) Moc toho za sebou osobně nemám, ale pár historek z natáčení už jsem taky potkal... Je samozřejmě fajn, že "pošlete krok a motor se poslušně pohne do žádané polohy", není potřeba polohu dynamicky trefovat nějakou servosmyčkou... ale kvůli bezpečnosti může být žádoucí, přesto hlídat dosažení polohy kvadraturním čidlem + čítačem apod. Kromě toho ta "mechanická garance přesného kroku" je jistě neefektivní z hlediska poměru výkon/hmotnost, omezuje to dosažitelnou rychlost pohybu apod. Krokové motory provozované dlouhodobě poblíž hranice svých dynamických možnosti můžou časem vadnout (třeba i teplem) apod.

Vnořené PID servosmyčky jsou masakr :-) A modelování řízené mechanické soustavy, prekompenzace setrvačného chování, řešení stability regulace... přiznám se, že v oboru nemám formální vzdělání, víceméně si cintám pentli.

Ehh CAN bus... jako každá úžasná technologie. Potenciálně dobrý sluha ale zlý pán... Konkrétně ta vlastnost, že fyzická vada jednoho uzlu zastaví celou sběrnici. Nad tím CANopen - složitej jak autobus. Ostatně jako jakákoli pokročilejší síť nebo fieldbus. Prostě ta vyšší úroveň abstrakce se odráží ve složitosti.

EtherCAT je v mnoha ohledech boží :-) Myslím ty spodní vrstvy. Funguje to nad generickými implementacemi Eth PHY, rozdíl je až v MAC vrstvě (na slavech a hubech). PCčko v roli EtherCAT mastera nepotřebuje po hardwarové stránce nic moc speciálního. Jako EtherCAT master port poslouží trochu slušná běžná síťovka - osobně jsem v téhle roli viděl v několika případech i210 od Intelu, moji oblíbenou. Správně píšete, že v taktu 10 kHz se toho na Ethercatu asi nestihne mnoho odvysílat - protože klasický EtherCAT je omezený na rychlost 100 Mbps (protože dedicated pár pro RX a TX), tzn. do 100 us se vejde asi 10 Kb (kilo bitů), tzn. v zásadě jeden přiměřeně velký ethernetový frame... V síti neprobíhá store and forward, frame odeslaný masterem se jenom elektricky zopakuje skrz všechny slavy a huby... (s minimální průchozí latencí). Master dostane frame zpátky s upravenými některými bity - slavové vědí, do kterých bitů mají letmo vkládat "upstream" data. Funguje to jako řetízek posuvných registrů. Neřeším vyšší vrstvy - z mého pohledu záležitost softwaru.

Viděl jsem implementaci "modulárního remote IO", kterou výrobce prodává jako EtherCATový systém, ovšem ve skutečnosti z EtherCATu používá jenom spodní asi dvě vrstvy, nad kterými si jede svůj nějaký jednodušší protokol...

Už dost volně na okraj, zajímavě vypadá taky TSN - ve srovnání s EtherCATem je jeho PHY+MAC už lehce over-engineered: packet-switched Ethernet s přidanou podporou "přerušeného a navázaného odeslání" méně prioritních dat...

A to už opravdu uhýbám od tématu.
Děkuji za zajímavou debatu.

Na PCčkách obecně není problém s hrubým výpočetním výkonem, ale na běžném PC hardwaru dovedou nepříjemně překvapit latence různého původu. Jako že ve stovkách mikrosekund, na konkrétních historických modelech hardwaru údajně i hůř. Když vyřešíte process scheduling (RT podpora v OS) a prioritu RT tasku a IRQ, a SMI/SMM a C-stavy, zbývá Vám potenciální tlačenice na PCI-e = jde o to postavit systém tak, aby k tlačenici nedocházelo.

Jistě, SMI/SMM to umí úplně rozbít. Takže už na 1kHz RT_PREEMPT task je potřeba "nezkažený" PC HW, na 10kHz už je určitě potřeba větší ladění. Že se SMI není problém je spíš výjimka, jde to u průmyslových PC, co jsou k tomu tak nějak navržena, a sám výrobce je variantně dodává s nějakým RT systémem, takže to má pohlídané - třeba BR Automation. Jasně, že tam jitter je. Je potřeba počítat rezervu třeba 25%, ale to ničemu nevadí. Přesný I/O timing dělají až ta vnější zařízení, jen potřebují včas dostat data.

Díky multicore CPU není problém v Linuxu vyhradit několik jader jen pro konkrétní RT thready, to hodně pomůže. U větších CPU ideálně tak, aby RT a non-RT load nesoutěžily o stejnou L2/L3 cache. PCI-e už nebývá až takový problém, dneska jde spousta linek přímo z CPU... Pro I/O, typicky ten Ethernet, je dobré nastavit pro jejich IRQ afinitu na stejný CPU core kde se s těmi daty pracuje a zvednout prioritu IRQ threadů. A pak použít AF_XDP.

Ad TSN - fajn, low-level vrstvy se dají pochopit, ale nějak se zatím neustálil příčetný způsob konfigurace toho celého. Uvidíme, jestli se chytne OPC-UA-over-TSN, ale to jsou takové dva raketoplány nad sebou... Ale dá se to dobře kombinovat se stávajícími technologiemi včetně EtherCATu: https://www.beckhoff.com/cs-cz/products/i-o/ethercat-terminals/ek1xxx-bk1xx0-ethercat-coupler/ek1000.html

Zdravím a děkuji za doplnění a rozvedení.

Byl bych moc rád, aby se podařilo tyto informace a názory někde soustředit a mít podklady zaprvé kam již v současném stavu další směřovat, kde hledat ty společné části, na kterých lze a má určitě praktický a i ekonomický smysl pracovat dohromady a i trochu ovlivnit, vyvážit, které části by mohly/měly přijít do jádra. Viz i mé příspěvky do diskuze na LKML.

Osobně bych spíše na rozdíl od původního předkladatele směřoval spíše k řešení jako je COMEDI, tedy knihovny v userspace a do jádra přenést to, co má smysl. Třeba generování STEP, DIR na Raspberry Pi přes DMA s dobrým plánováním z úseku do navazujícího úseku mi připadá, že patří do jádra.

I když třeba CERNovské AliceO2Group ReadoutCard řeší DMA z userspace a při použití UIO a IOMMU to může být i v zásadě chráněné tak, že není potřeba do jádra specializovaný kód dávat a přenos dat z a třeba i do HW je nejrychlejší, jádro kromě počátečního nastartování nebo buzení tasku, když by se na data mělo dlouho čekat, tak vůben nepřidává žádný overhead.

Ale na RPi to s IOMMU nebude taková sláva a zároveň pro běžné použití nějaké API, aby se nemuselo vždy vše dělat v userspace na míru by se hodilo.

Řízení FOC a PMSM podle mě spíš patří do userspace, ale to API směrem k HW se vzájemně synchronizovaným čtením proudů a nastavením a PWM a nebo v něktěrých případech i ten rychlý Park, Clarke patří do FPGA, HW a nebo při emulaci třeba i do jádra a API by mohlo být nějaké sjednocené.

Jinak na PC, když se povede najít typ motherboardu bez SMI problémů, tak jsme běželi na PC přes Humusoft DAQ karty simulaci PMSM motoru modelovaného v Matlab/Simulinku s naším targetem na PREEMP_RT na 30 kHz, no missing sample. PC tak vytvářelo "HW" s dynamikou PMSM, který řídila ECU jednotka na Tricore.

Nějaké další nápady a odkazy jsem sepsal do toho vlákna na LKML. Ale s časem jsem na tom zle, učení, práce na NuttXu, RTEMSu, pysmCoderu a teď ještě něco připravit na InstallFest.

Určitě je potřeba v LKML vlákně zmínit CANopen DS402, měly jsme i ty profily naimplementované a byl jsem i jako host u standardizace CANopen FD... Na škole k normám přístup máme a na rozdíle od právníků z ProfiBUSu, kteří naše investice přes vyhrožování zablokovali tak, že jsou dnes již tak staré (1, 2), že smysl nemají, tak s představiteli CAN in Automation vycházíme dobře a naše open-source implementace i různým zájemcům o testování CAN FD a dalšího nabízí. Takže otevřená implementace DS402 by nebyla problém a i nějaké existují. Na CANu se akorát musí platit za patenty, což je dnes jen za CAN FD, CAN je volný, když budeme říkat jen Two Wire Automotive Interface kompatibilní s CAN.

Obecně, budu rád za diskuzi, propojování informací a třeba i úsilí a mám i trochu kontaktů kolem kernelu, CANu a dalšího, takže mohu i ostatní informovat a trochu působit v bějakém rozumném směru. Také je na mnou založených firemních i školních repozitářích dost k znovuvyužití.