Názory k článku
Úspěšná kampaň na Monarco HAT - průmyslové rozšiření k Raspberry Pi
-
To není jenom o humanitním vzdělávání. Měli jsme v bývalé práci pro jednu firmu dělat průmyslovýho robota, ale bylo to placeno z grantu a podmínka byla spolupráce s VŠ. Tak si šéf půjčil dva (údajně) talentovaný hošany z FEKTu.
První porada, zeptal se jich, čím to budeme řídit. Študáci, že NTB s XPčkama a IO kartu na USB. Ani jednoho z nich nenapadlo, že
- to není real time systém
- není tam garantovaný, že to vůbec nabootuje
- souboj HDD (před deseti lety byly SSD sci-fi) vs. vibrace je dopředu jasný
- rozsah pracovních teplot, prachu a vlhkosti
- USB má moc velký latence pro takovou aplikaci
- pohyblivá část měla dost síly na to, aby se modrá smrt proměnila na smrt poblíž stojícího zaměstnanceA když jsme je na to upozornili, tak tam seděli zaražení jak větry a jenom poslouchali, co se vlastně bude dít a jak to budeme řešit.
-
Adam KaliszStříbrný podporovatelTak to asi opravdu nebyla moc esa a nebo nebyl požadavek jasně vyřčen. Nakonec by ale člověk neměl od studentů čekat, že vše bude bezchybné, nakonec se to teprve mají naučit. Jako student jistě můžu převzít i poměrně velkou zodpovědnost, ale musí na to vždy aspoň zběžně mrknout nějaký odborník s praxí. U případného soudu to jinak zaměstnavateli omlátí o hlavu, že ten student na to ještě žádný papír neměl apod.
S real time je to aspoň v teorii trochu komplikované. Je hard a soft real time (to jistě nemusím připomínat). Něco industriálního, co nejsou kardiostimulátor nebo brzdy určitě může běžet jako soft real time a upraveným Linux jádrem např. Je i dost strojů, které běží samostatně a kritické stavy jsou ošetřeny níže, ale pracovník musí interagovat s počítačem a to je klidně Windows NT 3.1 nebo tak něco. (V produkci ještě takové stroje máme, ale vyměňte si celý agregát za stotisíce euro kvůli operačnímu systému ovládacího počítače. Managementu se to špatně vysvětluje a smlouva s dodavatelem je už ca 20 let podepsaná.)
USB je na opravdu hodně aplikací dobré rozhraní, až se divím, na co všechno lze očividně bez problémů použít. Ale je fakt, že to je často zbytečně složité řešení, když by třeba nějaké sériové rozhraní službu odvedlo třeba i spolehlivěji a z hlediska HW i SW pravděpodobně jednodušeji. V tomhle ale absolutně tápu a upřímně se rád nechám poučit i když to asi nebudu nutně potřebovat. Necítím se být někým, kdo bude navrhovat hardware, ale člověk nikdy neví, že :-) Vzdělání bych teoreticky měl mít jak na SW, tak HW. Zatím jsem ale udělal hodně teorie a osahal si spíš administraci apod. Tak jsem zvědavý, jak bude probíhat low-level programování v NASM a potom třeba nějakém návrhu obvodů. Třeba psaní ovladačů by mě docela zajímalo, ale dostat se do toho sám je docela fuška. :-)
Jinak máte svatou pravdu, harddisky třeba i 50 metrů od bucharu nebo válcující soustavy odchází obyčejně po roce (podle kolegy, který je ve firmě už přes 30 let) a to klidně i když nasadíte notebookové, myšlené na otřesy. Asi jim nedělají dobře ty poměrně malé a nerovnoměrné vibrace a 24/7/365 provoz. Upřímně, i CF karta by asi byla spolehlivější. Od té doby, co je v okolí těchto strojů nasazováno do počítačů SSD, je pokoj.
-
Sten (neregistrovaný)
XPčka můžou běžet realtime proces, který poběží dál, i kdyby zbytek systému hodil modrou smrt. Akorát nebude mít přístup k disku, ale to by si měl stejně ošéfovat, operace na magnetických discích nejsou ani soft realtime.
Co se týče USB, už dneska se tím celkem běžně řídí třeba CNCčka, 3D tiskárny nebo různé řezačky, stačí přímo na ten přístroj hodit malé AVRko (s programem v C, v assembleru už snad dneska nikdo nepíše ani pro tyhle miniatury), které zajistí realtime odezvu, takže ten řídící systém může posílat příkazy v dávkách, čímž se řeší malá odezva USB, a po vytuhnutí toho systému, co tam posílá příkazy, se to automaticky zastaví, takže ani toho pracovníka vedle to nezabije.
CF karty (s IDE redukcí) se na takové věci celkem běžně používaly, ne? Jediný problém mohl nastat v době, kdy většina mikrodesek přešla na pouze SATA, ale SSD byly stále příliš drahé.
-
Tak ono je take strasne chytre vzit dva greenhorny z VS bez praxe a pak si tam hrat na kovboje a davat jim najevo, jak jsou blbi. Na necem takovem by se studenti meli neco naucit od ostrilenych praktiku, ne ziskat dozivotni averzi nasledkem setkani s neprijemnymi lidmi, kteri si potrebuji lecit mindraky.
-
Kdybych se bál konkurence, tak neupozorňuju na to, že PLC stavěný na Arduinu a Raspberry jsou nesmysl a prostě počkám, až "konkurenci" zavřou za ublížení na zdraví z nedbalosti a obecný ohrožení.
Jako autor několika průmyslových systémů od robotů přes obráběcí stroje, dopravní systémy a energetiku si troufám říct, že tohle fakt není sranda, ani příležitost k seberealizaci pro bastlíře a napsat na něco "průmyslový" chce fakt odvahu.
-
JduAkoratKolem (neregistrovaný)
Problém je, že v aplikacích, kde jde o život (a to robot nebo linka ve fabrice je), to zařízení musí fungovat naprosto deterministicky, a všechny možné havarijní stavy musí být ošetřeny.
Když jsme u toho Arduina, tak si představte, že tu desku byste musel naprogramovat firmware, který jste zkompiloval pomocí překladače co má certifikaci, aby nedošlo k tomu, že chyba v kompilátoru povede k nedefinovanému chování. Stejně tak ten program sám musí být napsán tak, aby splňovat standardy, jinak nemůže být použit. A to se nepouštím do toho, co by se muselo provést s hardware.
To jen tak například.
A ne, není to tady zbytečná buzerace, stačí si najít historická selhání software v řídících aplikacích (např. https://en.wikipedia.org/wiki/Therac-25 )
-
To, co píšete, platí pro funkce řídicího systému zajišťující tzv. funkční bezpečnost (functional safety). V diskusi byla zmíněna norma IEC61508, která pro tento účel definuje několik úrovní safety integrity level (SIL).
Běžně používaná PLC zpravidla funkční bezpečnost nezajišťují, a jejich software není certifikován na žádnou SIL úroveň. Nemělo by to ani moc smysl, pokud by uživatelské programy běžící na takovém PLC nebyly též vytvořeny s použitím metodiky zajišťující funkční bezpečnost - a to v běžné průmyslové automatizaci - např. výrobní linky, testovací stendy - zvykem rozhodně není.
V běžných aplikacích je funkční bezpečnost obvykle zajištěna odděleně od řídicího systému, a všechny komponenty podílející se na těchto funkcích jsou certifikovány na příslušný SIL level -- např. optické závory, snímače otáček, safety relé (v jednodušších případech) a safety PLC/controllery, safety vstupy na servopohonech (typicky funkce safe-torque-off). V poslední době jsou safety prvky integrovány do distribuovaných IO systémů jako EtherCAT nebo Ethernet Powerlink, ale safety funkce vždy zajišťuje samostatný safety controller s velmi omezenou sadou funkcí.
Něco jiného jsou řídicí systémy kritických částí např. pro energetiku, zejména pak jadernou kde platí samostatná norma IEC 61508. Pak platí striktní požadavky na použitý HW, SW a nástoje vč. kompilátorů, ale často není konkrétní řešení přesně definováno a požadavky lze splnit více způsoby - redundancí, diverzitou, testováním. Nicméně v těchto oblastech se standardní PLC nepoužívají, protože při jejich komplexitě a množství funkcí (které nejsou v dané aplikaci potřeba) by náklady na vývoj podle safety standardů byly extrémní, pokud by to vůbec bylo možné.
Možná vás to tady některé překvapí, ale hard-realtime průmyslové řídicí systémy běží někdy i nad MS Windows - např. BECKHOFF TwinCAT, který se běžně používá pro řízení robotů a obráběcích strojů a svými možnostmi a parametry běžná PLC dalece převyšuje.
-
Jenže bezpečnostní modul musí dostat informaci, že je všechno OK. Tam třeba PLC drží jeden kontakt sepnutý a druhý rozepnutý. A viděl jsem i situaci, kdy po záběru 20kW serva, řízenýho z vedlejšího rozvaděče, zůstaly zamrzlý výstupy z PLC. Takže bezpečnostní modul myslel, že je vše OK, ale pohon nereagoval ani na joystick, ani na inkrementály na pojezdu. Naštěstí byly dorazy napojený na bezp. modul, ale i tak chlap málem přišel o ruku...
Bezpečný PLC je prostě základ, ztrouchnivělou dřevěnou lávku bytelný ocelový zábradlí nezachrání. Proto říkám, že tohle bych z principu nenasadil ani doma na podlahovku.
-
JduAkoratKolem (neregistrovaný)
Tak jsem si rexcontrols.com rozklikl. Když dám na jejich stránkách vyhledat "certified" nebo "certification", tak je výsledkem čistá nula. Když vidím podporované desky a systémy, tak je to tak na řízení domácího bazénu. Robota ve fabrice bych tím fakt neřídil.
Můžete mi vysvětlit KDE mám najít jejich opravdový PLC produkt ? Nebo JAKÉ to má certifikace ?
Mě tohleto totiž absolutně fascinuje. Zrovna raspberry, které má problém běžet stabilně samo o sobě. Vždyť to zařízení je rádo že vydrží nabootované, natož aby něco řídilo.
-
Pokud vaše Raspberry Pi má problém běžet stabilně samo o sobě, asi máte vadný kus nebo možná děláte něco špatně. Přestože bych RPi pro nic kritického nedoporučil, naše zkušenosti ukazují, že při použití kvalitní microSD karty (SLC), nemá RPi žádný problém běžet nepřetržitě bez jakékoliv nestability. Nejstarší takový nám běží několik let.
K hardwaru - IPC od firmy jako je B&R nebo BECKHOFF by vám pro řízení robota nestačilo?
-
Petr M (neregistrovaný)
To znamená: ve škole v laboratoří. Kritický nebo nekritický, problém je, že jenom pitomý restart z SD karty dá klidně minutu. Tu minutu, kterou se točí motor a nejedou koncáky...
Jinak RPi je hodně blbá volba pro řízení, protože
- Nikde není definováno chování RESET signálu. http://projects-raspberry.com/wp-content/uploads/2015/08/BCM2836-Cortex-A7-MPcore-Processor-Reference-Manual.pdf popisuje jenom domény pro RESET, ale nepíše se to podstatný - je RESET pin obousměrný? Pokud dojde k internímu RESETu, např. softwarově při rebootu a neí k dispozici signál, kterým se přepnou výstupy do definovanýho stavu, tak je to nepoužitelný.
- Topologie napájení je taková, že na přidané desce je napájecí zdroj, který vyrobí +5V. Raspberry s z toho udělá +3,3V a z +3,3V se pak snižuje napájení pro jádro a pro SDRAM. Jenže z +5V jeou napájený USB porty. Je nějak zajištěno, že zkrat na USB, který je volně k dispozici, nesestřelí napájení procesoru? Pokud ne, nesmí být USB volně k dispozici.
- Watchdog. No, ten musí být externí, že. Takže přes konektor a potom stačí jeden kontakt toho konektoru, který normálně nemá na funkci vliv, ale visí na něm bezpečnost...
- Vhodný OS. Pokud tam dají standardní Linux a řeknou, že si tam může kdokoliv spustit cokoliv, tak pokud jiná aplikace vygeneruje tři vlákna a u všech dá maximální prioritu, tak zaručeně shodí časování PLC. Mají to nějak ošetřeno?A to jsou jenom první tři věci, co mě napadly. Začít do toho vrtat, tak jich minimálně dvacet najdu...
-
Kritický nebo nekritický, problém je, že jenom pitomý restart z SD karty dá klidně minutu. Tu minutu, kterou se točí motor a nejedou koncáky...
Na RPi 2B s Debian Jessie je to výrazně pod půl minuty, ale to není vůbec podstatné.
Motor se točit nebude, protože všechny vnější vstupy a výstupy na té desce jsou řízené přes samostatný ARM Cortex-M3 MCU. Ten, když nedostane z RPi process data po dobu delší než např. 2 periody řídicího tasku, přepne výstupy do bezpečného stavu. Toto zafunguje při jakémkoliv problému s časováním / zatuhnutím / resetem RPi. Pokud ten motor budete řídit nějakým měničem s komunikací třeba přes Modbus RTU, bude tam obdobné opatření.
Jenže z +5V jeou napájený USB porty. Je nějak zajištěno, že zkrat na USB, který je volně k dispozici, nesestřelí napájení procesoru? Pokud ne, nesmí být USB volně k dispozici.
RPi obsahuje obvod pro omezení proudu na USB napájení. Pokud se na to nechcete spoléhat, můžete napájení USB portů softwarově vypnout, nebo je fyzicky znepřístupnit.
Watchdog. No, ten musí být externí, že. Takže přes konektor a potom stačí jeden kontakt toho konektoru, který normálně nemá na funkci vliv, ale visí na něm bezpečnost...
Nerozumím. Externí watchdog odpojuje 5V napájení do celého RPi, takže to není nic, co by normálně nemělo na funkci vliv.
Vhodný OS. Pokud tam dají standardní Linux a řeknou, že si tam může kdokoliv spustit cokoliv, tak pokud jiná aplikace vygeneruje tři vlákna a u všech dá maximální prioritu, tak zaručeně shodí časování PLC. Mají to nějak ošetřeno?
Rozvíjíte předpoklady, které nikdo neformuloval. Základ je Linux s RT-Preempt patchem. Thready řídicího systému běží s definovanou úrovní RT priority. Pokud tam budu pouštět další aplikace, musím trochu přemýšlet, a přirozeně takové aplikace nesmí požadovat větší RT prioritu než řídicí systém. Že "tam může kdokoliv spustit cokoliv" nikdo netvrdí, a ani to snad nemůže nikdo očekávat.
-
Linux Kernel dodávaný s Raspbianem neobsahuje RT-Preempt patch, takže real-time chování není zaručené. Nicméně i díky tomu, že řada věcí z RT-Preempt už je součástí mainline Linuxu, lze standardní kernel celkem dobře použít pro tasky s periodou cca 10 ms a více. Přitom "dobře použít" znamená, že na tom systému zároveň nepouštíte nějakou brutální zátěž.
RT-Preempt patch lze na RPi kernel aplikovat, a pak už se to za real-time systém dá považovat. Dlouhodobé testy z RPi zatím nemám, ale zkušenosti s obdobnými ARM platformami ukazují, že se dá spolehnout na latenci cca do 100us při téměř jakékoliv vedlejší zátěži. Viz např.: https://www.osadl.org/Latency-plot-of-system-in-rack-a-slot.qa-latencyplot-ras5.0.html?shadow=1 Dalšího zlepšení se dá dosáhnout vyhrazením jednoho CPU výhradně pro RT tasky a interrupt therady od souvisejících driverů, případně laděním dalších low-level věcí.
-
Myslím, že i non-RT kernel má /proc/irq/$IRQ/smp_affinity, kam lze zapsat CPU mask. Kernel s RT-Preempt navíc vytváří pro každý interrupt handler vlastní kernel thread, kterému lze nastavit RT scheduling class a RT prioritu přes chrt, a případně na něj použít taskset (to ale možná není ani potřeba, když už je nastaveno smp_affinity).
Linux má v tomhle ale pořád ještě rezervy, jeden z největších problémů je, že na všech CPU (i těch vyjmenovaných v isolcpus) se spouští nějaké servisní operace s periodou CONFIG_HZ. Nějakou dobu je k dispozici NO_HZ_FULL option, ale to si podle našich zkušeností moc nerozumí s RT-Preempt, a stejně to funguje jen když je na daném CPU jen jeden thread - viz https://lwn.net/Articles/549580/. Kromě toho pomáhá ještě kernel option rcu_nocbs=<cpulist>. Na ARM Cortex-A9 se nám ještě osvědčila konfigurace L2 cache CPU locking, tedy pevné vyhrazení části L2 cache pro CPU s realtime tasky. Jak moc je tohle zdokumentované u RPi jsem zatím nezkoumal. Ta izolace ale pořád není úplně dokonalá, zejména při vytváření nových procesů na non-realtime CPU dochází k drobnému "zakopnutí", jehož příčina mi zatím není úplně jasná, možná něco s TLB.
-
Adam KaliszStříbrný podporovatel
Slovo "ihned" zde není každopádně na místě. Realtime v operačním systému neznamená ihned, ale v definováném čase. Deadline, tedy lhůta, může teoreticky být jakkoliv dlouhá. Třeba když budete zavírat stavidlo na přehradě nebo něco takového, tak to taky není ihned, ale chcetě vědět, že do hodiny např. bude proud vody omezen na požadovanou úroveň. Nejsem schopen ale říci, jak reálný tento příklad je.
-
Jenda (neregistrovaný)
> Je nějak zajištěno, že zkrat na USB, který je volně k dispozici, nesestřelí napájení procesoru?
Myslím, že tam byl nějaký proudový omezovač.
> Pokud tam dají standardní Linux a řeknou, že si tam může kdokoliv spustit cokoliv, tak pokud jiná aplikace vygeneruje tři vlákna a u všech dá maximální prioritu, tak zaručeně shodí časování PLC. Mají to nějak ošetřeno?
Řídící vlákno se dá tasksetem zamknout na jedno jádro a jadernému plánovači říct, aby na něj nesahal. A pokud někdo ručně na to dedikované jádro přesune MineCraft? To je prostě jeho problém, když máš, já nevím, PLC, tak taky neřešíš debilitu uživatelů.
