Fórum Root.cz

Práce => Studium a uplatnění => Téma založeno: Ferda 11. 03. 2016, 14:08:53

Název: Proměna programátora desktop → PLC
Přispěvatel: Ferda 11. 03. 2016, 14:08:53
Dobre odpoledne vazene kolegyne a kolegove,

Zhruba 15 let se zivim programovanim pro desktop, casto proti nejakemu HW zarizeni. Tzn. nastudovat noty k danemu zarizeni, pripadne implementovat nejaky proprietarni komunikacni protokol. Vystupem muze byt knihovna/API, nad kterou se udela nejake to UI. Nic svetoborneho.

Nejsem technicky uplny levak (tim nemyslim PC, ale ostatni prakticke veci). Uvazuji nad praci programatora PLC kontroleru. Nicmene vubec nevim, v cem takova prace spociva. Vim jen, ze zminene kontrolery podle programu ovladaji nejakeho robota ve strojarske vyrobe.

Ma otazka - v cem takova prace programatora spociva? Ma smysl nad tou praci uvazovat vzhledem k me pracovni historii?

Predem diky za nazory.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: eiffel 11. 03. 2016, 18:42:54
Zadek  otlačený z letadel a aut, bolavá záda ze špatných hotelových postelí, žaludeční vředy z hospodské stravy.
Programování PLC (pokud Vás nenutí být prase a neprogramuje se to ve strukturovaném textu) je vcelku triviální.
Grafiku na OP řešíte taháním myší, o komunikaci se nestaráte, to si řeší PLC sama implementovanými průmyslovými protokoly, takže pokud víte, co má technologie dělat, jste v podstatě sakra velmi dobře placený úředník.
Stačí se naučit základní pravidlo, že :
1. PLC načte vstupy
2. Interpretuje program (program běží shora dolů a zleva doprava)
3. Nastaví výstupy
4. Komunikuje
... a tak stále dokola ...
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 11. 03. 2016, 20:31:06
Tohle mě taky zajímá, protože o tom vůbec nic nevím :)

Je to teda tak, že je to jednoduchá práce a je dobře placená jenom proto, že lidí s touhle znalostí je málo? Proč se to teda víc lidí nenaučí? Protože je to opruz nebo protože lidi vůbec netuší, že něco takového existuje a že by to mohli dělat?

A ještě jedna obecnější, možná hloupá otázka: je to perspektivní technologie nebo spíš relikt minulosti, který bude postupně ustupovat plnohodnotnějším kontrolerům na nějakém RTOSu? Má to nějaké zásadní výhody? (jako třeba nějakou možnost formálního ověřování korektnosti nebo jánevímco...)
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: kkjan 11. 03. 2016, 20:31:35
Pisem z vlastnej skusenosti. Takze da sa suhlasit s eiffel-om. Programovanie PLC nie je ziadna veda. Vyuziva sa graficke programovanie LAD/FBD (Nieviem ako sa to nazyva inde ja som robil zo Simaticmi-> Siemens). Niektori programuju v niecom podobnom ako asembler (STL). Jedine z cim nesuhlasim s eiffel-om je ze preco je prasacke programovat v strukturarnom texte (SCL). Ja som v tom dost robil, a naprilklad recepty umiestnene v poli sa v tom robia docela lahko (struktura a pole zo struktury). Inac je to o tom ze sa nacitaju vstupy, spracuju sa v programe a zapisu sa na vystup. Sranda zacina ak tych vstupov zacina byt 500 a viac a do toho nejaky analog a   PID/PSD regulator. T To zacina byt i sranda/veda o nastaveni toho regulatora. Taktiez su potrebne znalosti z elektrotechniky a orientacie v schemach :-D Napr. ak nejaky signal nechodi:-D A  je tu aj otazka zodpovednosti/bezpecnosti prevadzky napr. pri blokaciach nejakych veci co sa nesmu v danom momente robit (napr. blokovanie otvorenia nejakej nadrze ak je v nej horuce medium a pod.) aby sa obsluhe daco nestalo;-D

Preco som to nechal je cestovanie (kvoli rodine), inac praca je to zaujmava. Bud budes robit pre nejaku vacsiu vyrobnu spolocnost, v ktorej sa budes starat o technologiu (cestovanie az tak nehrozi) alebo pre spolocnost dodavajucu technologie (vtedy sa nacestujes az moc a na dlhsie doby, hlavne ak sa technologia spusta v zahranici). ak si myslis ze ta cestovanie bavi a aspon co to uvidis, tak to nie je az tak pravda. Z celeho cestovania vidis akurat fabriku, najblizsi hotel a potraviny alebo nejaku restiku. Inac si na place a programujes, ladis spustas pripadne zaucas obsluhu:-D.
Název: Re:Promena programatora Desktop -> PLC To Mirek Prýmek
Přispěvatel: kkjan 11. 03. 2016, 20:38:16
Perspektivu to ma. Ide hlavne o bezpecnost prevadzky preto sa pouzivaju tie PLC. RTOS je fajn ale iba ako dohliadaci system napr. SCADA alebo pre prevadzky kde nie je az tak kladeny dpraz na bezpecnost technologie. Resp. pri velkych technologiach RTOS riadi menej kriticke casti alebo je pouzity ako dohliadaci a vizaualizacny system pre tie PLC. A cena PLC nie je vobec mala. Je to prave kvoli tej ich odolnosti, testovaniu a bezpecnosti. Najlacnejsi model Simaticu S7-200 vyjde sice na cca 250 EUR ale to je cisto na zaklad kedy mas par vstupov/vystupov. vyssie rady ako S7-300 S7-400 sa splhaju vyssie min 2000eciek a ktomu si prirataj V/V karty nejake priferie a pod.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 11. 03. 2016, 20:51:32
Díky, je to zajímavý.

A to neexistuje třeba nějaký způsob, jak PLC programy převádět nějak definovaně na procesy pod RTOS? Ty RTOS-y jsou pořád ještě docela slušně deterministické, tak by to docela dobře mohlo jít, ne? (jak říkám, nic o tom nevím, nejspíš si to představuju jak Hurvínek válku ;) )
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: eiffel 11. 03. 2016, 20:58:21
Niektori programuju v niecom podobnom ako asembler (STL).
To je u SIMATICu to nejlepší, co může být. V ničem jiném simatica neprogramuji.

Z celeho cestovania vidis akurat fabriku, najblizsi hotel a potraviny alebo nejaku restiku. Inac si na place a programujes, ladis spustas pripadne zaucas obsluhu:-D.
Svatá pravda. Ale dá se "urvat" a něco vidět ... Ono se ale nechce ...

Je to teda tak, že je to jednoduchá práce a je dobře placená jenom proto, že lidí s touhle znalostí je málo? Proč se to teda víc lidí nenaučí? Protože je to opruz nebo protože lidi vůbec netuší, že něco takového existuje a že by to mohli dělat?
PLC a jejich programovací styl vznikl proto, aby se dřívější logika postavená na relé a stykačích dala snadno implementovat. (viz. Ladder Logic)
Je dobré být i trochu elektrikářem, protože se musíte vyznat v elektroprojektu a také snáz opravíte chyby po elektrikářích (anebo jim aspoň řeknete co mají chybně zapojené)
Jinak stran programování:
Dnes už to jde tak daleko, že můžete u některých typů porovnávat klidně float s integerem, PLC si s tím poradí (i když je to prasečina)...
RTOS je příliš "nízký" level... Sice na PLC většinou běží, ale vy jako programátor jste o mnoho pater výše ...
Vše máte předpřipravené, "blikací" bity různých frekvencí, datum, čas, komunikační buffery, bity o stavu baterie, retentivované proměnné ...

Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: eiffel 11. 03. 2016, 21:00:50
Jukněte třeba sem ...
http://www.tecon.cz/prod_automaty_click.php (http://www.tecon.cz/prod_automaty_click.php)
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: robotron 11. 03. 2016, 21:07:35
Díky, je to zajímavý.

A to neexistuje třeba nějaký způsob, jak PLC programy převádět nějak definovaně na procesy pod RTOS? Ty RTOS-y jsou pořád ještě docela slušně deterministické, tak by to docela dobře mohlo jít, ne? (jak říkám, nic o tom nevím, nejspíš si to představuju jak Hurvínek válku ;) )

To je dotaz zcela ignorujici myslenku predchozich odpovedi. Samozrejme, ze to jde. Jde to prelejt do programovaciho jazyka, do HDL, do MCU. Ale pointa soudobeho nasazeni PLC je prave v tom, ze se dana skupina lidi vedome a zamerne omezi na

1. konkretni HW od dodavatele, oplyvajiciho vymluvnymi razitky, casto i slusnou referenci, kolik desetileti bez vymeny to kde chodi (bylo by prima, kdyby se dokazal pochlubit i slusnou technologii a dobrym navrhem, ale to uz tak jednoznacny nebejva)

2. programovani s pouzitim velmi osekanejch vyrazovejch prvku.

Projektu nahrady resp. implementace PLC v ruznejch RTOSech, MCU aj. jsou hromady.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: vana-hb 11. 03. 2016, 21:12:31
Zhruba 15 let se zivim programovanim pro desktop, casto proti nejakemu HW zarizeni. Tzn. nastudovat noty k danemu zarizeni, pripadne implementovat nejaky proprietarni komunikacni protokol. Vystupem muze byt knihovna/API, nad kterou se udela nejake to UI. Nic svetoborneho.

Ma otazka - v cem takova prace programatora spociva? Ma smysl nad tou praci uvazovat vzhledem k me pracovni historii
Nevim co si představit pod popisem tvé práce.  Jako v čem programuješ? Co za zařízení? Jak je připojuješ? Kdo a jak používá ty aplikace? ... ale asi je to jedno.

PCL jsou dnes strašně jednoduché systémy. V podstatě všechno naklepeš v grafickém ovládacím programu s logikou vstup se sepnul něco udělej. je několik základních systémů které se liší logem a trochu přeházenýma ovládacíma prvkama.

Co je potřeba? Základní elektrikářský znalosti, hodně ligické uvažování a trochu základní práce s pc a to je všechno. Osobně se divim že to nedělá víc lidí protože programátoři PCL jsou královsky přeplacení.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 11. 03. 2016, 21:14:14
PLC a jejich programovací styl vznikl proto, aby se dřívější logika postavená na relé a stykačích dala snadno implementovat. (viz. Ladder Logic)
Jo, to jsem pochopil, zběžně jsem na to koukal shodou okolností nedávno.

RTOS je příliš "nízký" level... Sice na PLC většinou běží, ale vy jako programátor jste o mnoho pater výše ...
Vše máte předpřipravené, "blikací" bity různých frekvencí, datum, čas, komunikační buffery, bity o stavu baterie, retentivované proměnné ...
Aha, chápu.

Jukněte třeba sem ...
http://www.tecon.cz/prod_automaty_click.php (http://www.tecon.cz/prod_automaty_click.php)
Díky, ale moc mi to neřekne :) A nějak podrobněji to studovat nechci, chtěl jsem jenom slyšet od lidí, co v tom dělají, vo co vlastně go :)
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 11. 03. 2016, 21:17:45
To je dotaz zcela ignorujici myslenku predchozich odpovedi. Samozrejme, ze to jde. Jde to prelejt do programovaciho jazyka, do HDL, do MCU. Ale pointa soudobeho nasazeni PLC je prave v tom, ze se dana skupina lidi vedome a zamerne omezi na

1. konkretni HW od dodavatele, oplyvajiciho vymluvnymi razitky, casto i slusnou referenci, kolik desetileti bez vymeny to kde chodi (bylo by prima, kdyby se dokazal pochlubit i slusnou technologii a dobrym navrhem, ale to uz tak jednoznacny nebejva)

2. programovani s pouzitim velmi osekanejch vyrazovejch prvku.

Projektu nahrady resp. implementace PLC v ruznejch RTOSech, MCU aj. jsou hromady.
Buď jsem to nepochopil, nebo můj dotaz mířil jinam: tak jako kdysi PLCčka nahradily nějaké relé, tak se ptám, jestli se neblíží doba, kdy specializovaná PLCčka nenahradí nějaké obecnější stroje.

Ani jeden z těch dvou bodů mi nepřijde, že by na to nějak odpovídal.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 11. 03. 2016, 21:19:51
Buď jsem to nepochopil, nebo můj dotaz mířil jinam: tak jako kdysi PLCčka nahradily nějaké relé, tak se ptám, jestli se neblíží doba, kdy specializovaná PLCčka nenahradí nějaké obecnější stroje.
Ufff, to jsem to napsal nesrozumitelně a ještě s hrubkama. Prostě se ptám, jestli je vývoj takovýhle: relé -> PLC -> (něco obecnějšího softwarově definovaného) nebo ne.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: v 11. 03. 2016, 21:31:03
To je dotaz zcela ignorujici myslenku predchozich odpovedi. Samozrejme, ze to jde. Jde to prelejt do programovaciho jazyka, do HDL, do MCU. Ale pointa soudobeho nasazeni PLC je prave v tom, ze se dana skupina lidi vedome a zamerne omezi na

1. konkretni HW od dodavatele, oplyvajiciho vymluvnymi razitky, casto i slusnou referenci, kolik desetileti bez vymeny to kde chodi (bylo by prima, kdyby se dokazal pochlubit i slusnou technologii a dobrym navrhem, ale to uz tak jednoznacny nebejva)

2. programovani s pouzitim velmi osekanejch vyrazovejch prvku.

Projektu nahrady resp. implementace PLC v ruznejch RTOSech, MCU aj. jsou hromady.
Buď jsem to nepochopil, nebo můj dotaz mířil jinam: tak jako kdysi PLCčka nahradily nějaké relé, tak se ptám, jestli se neblíží doba, kdy specializovaná PLCčka nenahradí nějaké obecnější stroje.

Ani jeden z těch dvou bodů mi nepřijde, že by na to nějak odpovídal.
PLC dneska znamená hlavně IEC61131-3, na čem program běží je druhá věc, byl tady zmíněný simatic, který je v evropě asi nejrozšířenější hw, pak tady jsou soft PLC, na krabicích se, kterýma já pracuju běží CoDeSys
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: v 11. 03. 2016, 21:34:06
Buď jsem to nepochopil, nebo můj dotaz mířil jinam: tak jako kdysi PLCčka nahradily nějaké relé, tak se ptám, jestli se neblíží doba, kdy specializovaná PLCčka nenahradí nějaké obecnější stroje.
Ufff, to jsem to napsal nesrozumitelně a ještě s hrubkama. Prostě se ptám, jestli je vývoj takovýhle: relé -> PLC -> (něco obecnějšího softwarově definovaného) nebo ne.
já jsem to asi taky nenapsal dobře, vy jste na ty analogie, tak třeba takto: programátor PLC +- znamená programátor jazyků IEC61131-3, je to skoro jako programátor JVM - programátor jazyka Java/Scala/apod.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Ferda 12. 03. 2016, 13:12:56
Citace
Nevim co si představit pod popisem tvé práce.  Jako v čem programuješ?

C++ nebo C#

Citace
Co za zařízení?

Mycka, pec, pumpa, ctecka kdoviceho, ...

Citace
Jak je připojuješ?

RS232, TCP-IP

Citace
Kdo a jak používá ty aplikace?

Vetsinou delnici.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: K veci 12. 03. 2016, 14:13:41
Za 10 rokov praxe PLC-čkara.
Viac menej mozes PLC programovanie (komunikacie,plc,pohony,roboty,vision systemy...) prirovnat ku klasickenmu programovaniu. Rozdiel je v tom ze PLC je viazane na Hardware a viac menej vzdy mas unikatne riesenie. Ale ak porovnam narocnost, clenitost je to to iste.
Priklad:
= chces jednoduchu web stranku s kontaktnym formularom - nevies o tom nic
-> google priklady za 5 hodin si ju naprogramujes
= chces jednoduche ovladanie brany so snimacom - nevies o tom nic - ale mas elektro znalost a vybavenie
-> google priklady za 5 hodin mas na stole funkne zariadenie.

teda pre porovnanie je to rovnake. Ak chces "kravinku" tak je to naozaj jednoduche. Ak chces ja neviem robota. (3 motory - 3 ovladace - 1 plc) je to tak standardizovane a jednoduche ze to naozaj nie je problem. Vo svete PLC je to nieco ako jednoducha telefonna databaza v PHP.

Ale ak chces napriklad kamerove overovanie barkodu (400ks/min) na dopravniku + vyhadzovanie robotickym ramenom a to cele serializovane tak to uz je niekde ako keby chces naprogramovat novy OS na zakazku. Je dost potrebna znalost elektoniky a celkoveho systemu.

Dobry elektrikar moze byt PLC - ckar v style ok stroj nejde skontrolujem v programe preco, najdem chybu pripadne nieco vyklemujem. Ak nieco zhorelo viem to vymenit a nakonfigurovat.

PLC programator - moze riesit SCADA ,Vision, Serializacne veci, Velmi dobre platene su pohony kde je naozaj problem najst specialistu (sk-cz hodinovka od 40e) takze sa to da prirovnat k podobnej profesii a zameraniu "desktop" programator.

Problem je samozrejme kde a ako sa k tomu dostat kdeze PLC, servo a pripadne HMI nema kazdy doma a to je ten hlavny problem. Takze su to viac menej ludia okolo udrzby servisu, elektro a podobne. Samozrejme ak sa specializujes tak hydraulika, pneumatika atd... rata sa ze obcas zoberies skrutkovac a nieco dotiahnes a elektro schema je pre teba samozrejmost. Za tie prachy ak chces byt dobre plateny musis mat relativne dost prehlad.

Nevyhoda je to ze ked stroj nejde tak neexistuje nieco ako ideme s back-upu alebo zajtra to poriesim. Proste casto a hlavne zo zaciatku su to hodiny a hodiny riesenia priamo u zakaznika nez sa clovek vypraxuje. A samozrejme je rozdiel PLC-ckar v jednej firme co sa toci na 3 strojoch 10 rokov a viac menej ich pozna. PLC-ckar servisak co beha od zakaznika k zakaznikovy a fixuje a PLC-ckar vyvojar co vytvara odladuje atd atd... ale aj ten posledny kvasy u zakaznika :D




Samozrejme bavime sa o PLC v style (Siemens, Allan-Bradley,Vipa,Omron,Systech....) nie o jednocipoch ala arduino.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 12. 03. 2016, 16:36:55
Samozrejme bavime sa o PLC v style (Siemens, Allan-Bradley,Vipa,Omron,Systech....) nie o jednocipoch ala arduino.
Mně by právě docela zajímalo, jestli ta (už nějakou dobu trvající) popularita MCU ala arduino, PIC, STM32, Xilinx apod. třeba s tím trhem nějak hýbe - jestli se dá třeba říct, kolik procent implementací v nějakém sektoru se dřív řešilo nějakým "průmyslovějším" stylem a dneska se na to jde třeba spíš cestou těch MCU, FPGA apod.

...nebo jestli to na ten obor (řekněme automatizace obecně, v celé šíři) nemá vůbec žádný vliv, protože drtvá většina lidí, kteří si hrají s Arduinem a spol., stejně skončí u blikající LEDky a nemají žádné ambice tu svoji znalost nějak dál rozvíjet a komercionalizovat.

Zaznamenal jsem pár lidí, kteří si s MCU jenom hráli a teď sem-tam udělají nějaký menší "komerční" projekt (čti: nějakou blbinku - automatizaci něčeho typu zalívání zahrádky, nic extra kritického), tak by mě zajímalo, jestli se to nějak projevuje i směrem k té "větší", "serioznější" automatizaci, nebo jestli je vůči tomu úplně imunní.

(EDIT: P.S. sorry, že se ptám jako jelito, fakt je tahle oblast pro mě úplně španělská vesnice, buďte prosím tolerantní ;) )
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: robotron 12. 03. 2016, 16:56:47
Mně by právě docela zajímalo, jestli ta (už nějakou dobu trvající) popularita MCU ala arduino, PIC, STM32, Xilinx apod. třeba s tím trhem nějak hýbe - jestli se dá třeba říct, kolik procent implementací v nějakém sektoru se dřív řešilo nějakým "průmyslovějším" stylem a dneska se na to jde třeba spíš cestou těch MCU, FPGA apod.

Ale to jsou porad dokola otazky shodne pobihajici kolem jadra veci. Samozrejme, ze vevnitr v tech PLC jsou uplne obycejny prvky s nijak oslnivym digitalnim vypocetnim vykonem. (Zalezi na desetileti, kdy to bylo navrzeno, ale vzdycky jsou to soucastky z kramu plne odpovidajici dneska treba tem Arduinum/RPi, driv treba stavebnici Alfa-2/Logitronik-01.)

Rozdil je ta slupka: dostatecne steampunkove prgaci rozhrani, vzadu svorkovnice, ktery neuhorej pri pripojeni nesmyslu, integrovatelnost s danou mnozinou prumyslovejch sbernic.

Jakmile tohle zacnete chtit po sebeambicioznejsich Arduinarich, zbyde jich 0.1% a ti se pak pojmenuji nejak jako Telemecanique a proste rozsiri trh PLC o dalsi znacku. Ktera bude stat treba i zlomek Siemense. A stejne si pak do Spolchemie koupej dalsi varku Siemensu.


...nebo jestli to na ten obor (řekněme automatizace obecně, v celé šíři) nemá vůbec žádný vliv, protože drtvá většina lidí, kteří si hrají s Arduinem a spol., stejně skončí u blikající LEDky a nemají žádné ambice tu svoji znalost nějak dál rozvíjet a komercionalizovat.

Zaznamenal jsem pár lidí, kteří si s MCU jenom hráli a teď sem-tam udělají nějaký menší "komerční" projekt (čti: nějakou blbinku - automatizaci něčeho typu zalívání zahrádky, nic extra kritického), tak by mě zajímalo, jestli se to nějak projevuje i směrem k té "větší", "serioznější" automatizaci, nebo jestli je vůči tomu úplně imunní.

(EDIT: P.S. sorry, že se ptám jako jelito, fakt je tahle oblast pro mě úplně španělská vesnice, buďte prosím tolerantní ;) )
[/quote]
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: ehmmm 12. 03. 2016, 17:07:48
Mně by právě docela zajímalo, jestli ta (už nějakou dobu trvající) popularita MCU ala arduino, PIC, STM32, Xilinx apod. třeba s tím trhem nějak hýbe - jestli se dá třeba říct, kolik procent implementací v nějakém sektoru se dřív řešilo nějakým "průmyslovějším" stylem a dneska se na to jde třeba spíš cestou těch MCU, FPGA apod.

To by me taky zajimalo. Zalezi na aplikaci. Kde je potreba neco hodne specialniho a maleho, tak proc to nepostavit na miru na nejakem MCU. Ale kdyz mas hodne binarnich vstupu a vystupu, po kterych nechces zadne velke zazraky, hlavne aby to fungovalo, tak tam zatim vede PLC. Oni ti chlapci od MCU porad resi nejake miliampery a 3,3 vs. 5 V a takovehle veci. Jenze casto si v rozvadeci nekdo drbne dratem o drat, nebo se prekoukne a zapoji 230 V nekam, kam nema. A u PLC obvykle vyhori dany vstup a to je tak vse a jede se dal.

Pri programovani PLC je take velmi vhodne rozumet technologii, kterou ridis. Predejde se tak spouste problemum, pokud tedy neni naprosto exaktni zadani (coz jsem teda jeste nezazil, ale ja to delam jenom jako vypomoc, protoze nemam takovou praxi, takze do velkych zakazek me nepoustej).
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: txt 12. 03. 2016, 17:31:49
Samozrejme bavime sa o PLC v style (Siemens, Allan-Bradley,Vipa,Omron,Systech....) nie o jednocipoch ala arduino.
Mně by právě docela zajímalo, jestli ta (už nějakou dobu trvající) popularita MCU ala arduino, PIC, STM32, Xilinx apod. třeba s tím trhem nějak hýbe - jestli se dá třeba říct, kolik procent implementací v nějakém sektoru se dřív řešilo nějakým "průmyslovějším" stylem a dneska se na to jde třeba spíš cestou těch MCU, FPGA apod.

...nebo jestli to na ten obor (řekněme automatizace obecně, v celé šíři) nemá vůbec žádný vliv, protože drtvá většina lidí, kteří si hrají s Arduinem a spol., stejně skončí u blikající LEDky a nemají žádné ambice tu svoji znalost nějak dál rozvíjet a komercionalizovat.

Zaznamenal jsem pár lidí, kteří si s MCU jenom hráli a teď sem-tam udělají nějaký menší "komerční" projekt (čti: nějakou blbinku - automatizaci něčeho typu zalívání zahrádky, nic extra kritického), tak by mě zajímalo, jestli se to nějak projevuje i směrem k té "větší", "serioznější" automatizaci, nebo jestli je vůči tomu úplně imunní.

PLC je o robustnosti - certifikace na nějaké MTBF v daných podmínkách. Průmysl je konzervativní a životní cyklus dlouhý (při odpovídajícím servisu klidně 10 let). Na obrázky v ladder diagramech jsou namapované funkce knihovny napsané pro OS který na PLC běží. Některé funkcionality mohou být implementovány hardwarově. Vykonání procesů v definovaném čase je vyřešeno výrobcem a PLC programátor řeší aby byly ty výstupy správně nastaveny ve správném čase. A to nemusí být vždycky jednoduchý úkol když se na to díváme z hlediska celé výrobní linky s mnoha PLC. U procesní automatizace je spousta vstupů a výstupů, u strojní automatizace je kritické načasování a může to být i dost rychlé.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: robotron 12. 03. 2016, 17:43:26
Kde je potreba neco hodne specialniho a maleho, tak proc to nepostavit na miru na nejakem MCU.

Kdyz je potreba neco specialniho, tak to skutecne jinak nejde. V ostatnich pripadech maj PLC v prumyslu silene navrch -- klidne si rikejte, ze tou stupiditou, ale z mnoha hledisek vyhrava prave prg. model, kdy mate ruce svazany a vyrazovy prostredky chudy, nez kdyz mate CPU jadro a pomerne slozity periferie.

Konkretneji: odhadnete si pro sebe, kolik asi % z beznejch MCU bastliru (napr. ze zdejsich hojne zavlazovanych vlaken o domovni automatizaci) by dovedlo opravdu nezprasit nejakou aplikaci, at uz na bazi ISR, nebo pollingu. Uz jen ta sebekazen, aby kod vykonanej v kazdy iteraci (a) ISR (b) hlavni smycky nepresahla kritickej cas nutnej k obsluze I/O, neni zdaleka samozrejmosti. A hlavne, *jde* to napsat blbe -- a to na milion zpusobu. Dale pak pri prgani v C je past doslova na kazdym kroku, vynecham-li ukazatele, pak ruzny (un)signed, zarovnani struktur... Co tak ciste koukam kolem sebe, tohle prasi neuveritelny mnozstvi lidi a to vcetne tech, co to delaji leta. Nekdo z nich to aspon vi, ze tak hrozne prasi, spousta ma ale naivni radost, jak jim to primove s tim jednocipem jde, prece to funguje (nekdy, omylem).

(Aby bylo jasno, ja PLC nikterak zvlast nefandim a firmam implementujicim soucasne nestranim -- ba primo naopak, konkretne treba nejmenovane c.1 na trhu se choval k jedne skupine kolem opensource jak dobyrek, v obave, aby neztratil kus hegemonie nad komunikacnim protokolem.)
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 12. 03. 2016, 18:57:51
Konkretneji: odhadnete si pro sebe, kolik asi % z beznejch MCU bastliru (napr. ze zdejsich hojne zavlazovanych vlaken o domovni automatizaci) by dovedlo opravdu nezprasit nejakou aplikaci, at uz na bazi ISR, nebo pollingu. Uz jen ta sebekazen, aby kod vykonanej v kazdy iteraci (a) ISR (b) hlavni smycky nepresahla kritickej cas nutnej k obsluze I/O, neni zdaleka samozrejmosti.
To není samozřejmostí, protože to drtivá většina domácích amatérských bastlířů (mezi který se taky počítám) vůbec nepotřebuje řešit - stačí vědět, že přerušení vždycky doběhne v nějakém "rozumném" čase. Domácí bastlíř většinou neřeší automatizaci ničeho, u čeho by potřeboval mít jistotu, že něco proběhne do 2ms... (A dost často ani vůbec neřeší ani ty handlery, protože prostě použije knihovnu, která to zařídí za něj :) )

...a ono to (zřejmě) není potřeba řešit u spousty aplikací. Docela mě dostala přednáška Pavla Píši z FELu (který určitě ví, o čem mluví), kde rozebíral, jestli je na automatizaci použitelné RPi: https://www.youtube.com/watch?v=I_4cAhW46dM Dost zajímavá je pasáž, kde ukazuje, jak se latence na non-realtime OS dá docela solidně řešit prostě statisticky - pokud to na X pokusů projde, tak je to na daný účel dostatečné (EDIT: na videu někde kolem 1:10:00).

Pokud je na leccos použitelné RPi, tak s jednoúčelovými MCU bez OS je situace ještě o řád lepší...
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: robotron 12. 03. 2016, 19:32:37
Konkretneji: odhadnete si pro sebe, kolik asi % z beznejch MCU bastliru (napr. ze zdejsich hojne zavlazovanych vlaken o domovni automatizaci) by dovedlo opravdu nezprasit nejakou aplikaci, at uz na bazi ISR, nebo pollingu. Uz jen ta sebekazen, aby kod vykonanej v kazdy iteraci (a) ISR (b) hlavni smycky nepresahla kritickej cas nutnej k obsluze I/O, neni zdaleka samozrejmosti.
To není samozřejmostí, protože to drtivá většina domácích amatérských bastlířů (mezi který se taky počítám) vůbec nepotřebuje řešit - stačí vědět, že přerušení vždycky doběhne v nějakém "rozumném" čase. Domácí bastlíř většinou neřeší automatizaci ničeho, u čeho by potřeboval mít jistotu, že něco proběhne do 2ms...

No, tak zrovna pri takovejch tezce nadstandardnich ukolech, jako prijmout blbej bajt z komunikacniho rozhrani, to nastava bezne a v mikrosekundach. Vzpominam na jeden radoby n00b-friendly radiovej modul od Microchipu, s tim byl fakt zazitek pracovat, melo to buffer asi na 16 bitu (ne bajtu) a clovek kolem toho musel poskakovat jak kolem zpovykany knezny, aby nekde neco nepreteklo ani nepodteklo.

Citace
(A dost často ani vůbec neřeší ani ty handlery, protože prostě použije knihovnu, která to zařídí za něj :) )

Jo, to je pak bezva, pokud to teda nema jakost kodu jako treba IAR. To je i nic mnohonasobne lepsi.

Citace
...a ono to (zřejmě) není potřeba řešit u spousty aplikací. Docela mě dostala přednáška Pavla Píši z FELu (který určitě ví, o čem mluví), kde rozebíral, jestli je na automatizaci použitelné RPi: https://www.youtube.com/watch?v=I_4cAhW46dM Dost zajímavá je pasáž, kde ukazuje, jak se latence na non-realtime OS dá docela solidně řešit prostě statisticky - pokud to na X pokusů projde, tak je to na daný účel dostatečné (EDIT: na videu někde kolem 1:10:00).

Pavel Pisa je i muj guru, rovnez si myslim, ze vi, o cem mluvi. Zduraznim souslovi na dany ucel. Mam dojem, ze zde jsme ve vlaknu o PLC. Pokud budu resit spolehlivost systemu a budu mit k dispozici tu samou funkcnost s Linuxem a bez Linuxu uvnitr kriticky smycky, tak celkem bez vahani volim (b). (Sam FPK patch pouzivam, i kdyz na jinym ARMu.)

Za druhe, jak je nekde (slozitej) OS, razem uz nic nez statisticky vyhodnoceni nezbejva, protoze to proste nikdo nedokaze na bazi teroeticky verifikace spocitat. Opet, pokud vam staci stupidni pgm. model, je to jednoznacna vyhra, protoze minimalne ta cast systemu sama o sobe verifikovatelna je a muze bejt implementovana stranou od OS; i kdyby tam ten OS pak prilepenej byl na reseni SW narocnejsich cinnosti.

Citace
Pokud je na leccos použitelné RPi, tak s jednoúčelovými MCU bez OS je situace ještě o řád lepší...

Pouze za predpokladu, ze ten MCU programuje nekdo, kdo nedela zasadni chyby, jinak to muze bejt libovolne horsi. A opet, "leccos" zrovna nebudou aplikace typicke pro PLC.

A az si omezite okruh bastlicu na MCU na podmnozinu, ktera pise spolehlivej kod, urcite vam zbydou ti, jejichz cena prevyzi PLC-opice. A pokud z nich vezmete jeste tu mensi mnozinu, aby vam udelali klon PLC (jakoz se i mnohokrat na ruznejch platformach stalo, pamatuju si, ze jsem pred pomerne davnymi lety oponoval praci o soft-PLC na bazi QNX), pak jich zbyde jeste min a hlavne, vysledkem bude zase neco jako PLC, protoze v konecnem dusledku je potreba ten implementacni delnik, kterej do toho ty "zebriky" naboucha.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: K veci 12. 03. 2016, 19:36:48
 Mirek Prýmek . Nie neohrozuje a nikdy nebude. Ono je to v podstate to iste ale musis si uvedomit jednu podsatnu vec na cu to skoro kazdy zabuda. PLC nie je hracicka v style no tak sa to zaseklo a tak to restartuj a ideme. Vsetko je robustne a xyz overene. Za 10 rokov som vydel presne JEDNO plc ktoremu skapal procesor (r.v. 92 teda v kuse siel cca 20 rokov).

Dalsi rozdiel je v tom ze PLC na 9 z 10 ovlada vyrobnu linku a tam su neplanovane prestoje neraz radovo 10-100te /hodina.
Takze to musi byt overene xyz pretestovane, stabilne. Naprikled elektraren v Mochoviach ma PLC s roku 91. Teda PLC - riadiaci system. Nie ze by bol problem to vymenit modernizovat ale to riadenie bolo naozaj testovane tak ze sa zobralo na saharu a potom do arktidy a oni proste garantuju ze to PLC pojde. A zasa firmicka Arduino s.r.o. jednoducho nema prachy na to aby garantovala ze ich arduino je na 100% kvalitne a stabilne a to kazde jedno tak ze za to rucia nahradou skody. To ze skody v priemysle su realne a xyz vecsie ako v IT je fakt.

Ano v poslednej dobe najdes asi 10 novych super PLC systemov s ethernetom , 5 procesorov 5gb ram 100 I/O a pojde na tom aj android ale prax v tomto obore je taka ze je silne konzervativna skrz to ze nikdo nechce riskovat vyrobne straty.

A neporovnavajte PLC pre "home made" (akoze arduino alebo podobne ) s PLC pre premysel teda to naozajstne PLC.
To nie je "tupo skrinka" ktora dokaze uz aj integer? ( toto napise len debil co o tom nevie nic ). Je to skorej specializovany HW ktory v podstate model od modelu ponuka nieco ine v podstate v modularnej forme a velmi zalezi od zamerania. High Speed Counter, Motion Control, Vision system, PID, Servo Control, Enkoderove modulz proste bla bla.. Vzdy je  to ale o tom co ktory programator "napisal" co naprogramoval a tak sa na to pozera. Zaciatocnik povie je to easy lebo ved len Lader a STL a ved prosim ta. Tomu rozumiem na tom skoleny viac menej nic ine ani nemas ale zacni riesit aplikovane pohony spojene s detekcnov kamerov a serializaciou a hned zistis ze aj to "TUPE" plc nie je az tak tupe. Analogiu mas so zaciatocnikom PHP programatorm po prvom tutorial samozrejme napise co ches do momentu nez to zacne pisat :D
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 12. 03. 2016, 20:18:41
Zduraznim souslovi na dany ucel.
Jo, jasně, já ani náhodou nechci říct, že jsou všichni pitomci, poč používají drahý stroje a proč nepřejdou na Arduino, to vůbec ne, nejsem blázen :) Je mi jasný, že jsou segmenty, kde spolehlivost je absolutně nejdůležitější, pak světelné roky nic a pak teprve se můžeme bavit o něčem dalším. To tak nějak tuším, aniž bych v té oblasti někdy něco dělal.

Spíš ta moje otázka míří na to, jestli se třeba v průběhu času nezjistilo, že se v některých oblastech, kterým dřív dominovaly superspolehlivé superstandardizované stroje, dá použít (EDIT: respektive skutečně v praxi začalo používat) i něco jiného, protože je to prostě (už, teď) podstatně dostupnější a zároveň (na daný účel) dostatečně dobré.

Prostě jestli i v téhle oblasti nedošlo k něčemu podobnému jako v oblasti serverů - megacool proprietární stroje, mainframy a jánevímco byly v některých oblastech nahrazený sprostým x86 komoditním železem, protože to prostě stačí - spolehlivost se nahoní jinak, třeba redundancí a celkově se započítáním všeho to vyjde levněji v dostatečné kvalitě.

aby vam udelali klon PLC (jakoz se i mnohokrat na ruznejch platformach stalo, pamatuju si, ze jsem pred pomerne davnymi lety oponoval praci o soft-PLC na bazi QNX
Jo, přesně tímhle směrem ten dotaz mířil - jestli se objevuje (sorry, zase analogie ze serverů) něco na způsob virtualizace - vezmu ověřené řešení, naroubuju standardním způsobem na jiný podvozek - a celkově to opět vychází plusově.

Takže tohle by mě docela zajímalo - jestli existují třeba nějaké tyhle "soft klony" PLCček, jak jsou dostupné a jestli pro amatérského domácího bastliče má smysl se o to trochu zajímat, nebo má zůstat u svého Arduina, protoře by mu to (řekněme třeba pro tu domácí automatizaci) nic nepřineslo.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 12. 03. 2016, 20:23:53
Takže tohle by mě docela zajímalo - jestli existují třeba nějaké tyhle "soft klony" PLCček, jak jsou dostupné a jestli pro amatérského domácího bastliče má smysl se o to trochu zajímat, nebo má zůstat u svého Arduina, protoře by mu to (řekněme třeba pro tu domácí automatizaci) nic nepřineslo.
Tohle možná můžu napsat ještě jinak: dejme tomu, že coby domácí bastlič si netroufnu na řízení něčeho trochu kritičtějšího Arduinem, protože si prostě nevěřím, že bych správně všechno ošetřil (jak píšeš a úplně tomu rozumím). Existuje pro mě v takové situace nějaká alternativa typu "soft PLC", která by mi něco takového umožnila udělat (v rozumně "domácích" podmínkách - jak cenově, tak vybavením)?

(A nebavím se samozřejmě o kardiostimulátoru. Řekněme třeba jánevím řízení vyhřívání akvárka, u kterého nechci, aby se mi kvůli chybě ryby uvařily :) )
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: eiffel 12. 03. 2016, 21:15:59
Asi takto:
Rychlost scanu PLC programu není nikterak závratná - samozřejmě beru nějaký běžný standard - jsou to jednotky až desítky milisekund podle délky programu a typu PLC.
Každé arduino je teoreticky rychlejší - ale - PLC má na úrovni FW vše ošetřené: zákmity vstupů, rychlé čítače, komunikaci, PID bloky ...
Ladění programu - každý MCU návrhář zná jen breakpoint. Na úrovni PLC vidím online stav proměnných (u siemense dokonce i v daném místě programu), program se přehraje "za chodu" (alespoň u těch lepších PLC), takže ladím SW při běžící technologii (samozřejmě musím vědět co dělám )
S tímto se jako programátor netrápím - jak jsem již psal, jsem o několik pater výše...
Jukni se třeba sem - http://bues.ch/cms/hacking/awlsim.html (http://bues.ch/cms/hacking/awlsim.html).
Tenhle borec napsal dost dokonalé soft PLC (pomáhám mu s testováním)...
Srdce siemensáka zaplesá ...
 
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 12. 03. 2016, 21:28:10
Jukni se třeba sem - http://bues.ch/cms/hacking/awlsim.html (http://bues.ch/cms/hacking/awlsim.html).
Tyjo, to je super, to určitě vyzkouším, až bude někdy chvilka času, dík!

A nevíš o nějaké implementaci pro ty MCU?
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: v 12. 03. 2016, 21:36:28
Jukni se třeba sem - http://bues.ch/cms/hacking/awlsim.html (http://bues.ch/cms/hacking/awlsim.html).
Tyjo, to je super, to určitě vyzkouším, až bude někdy chvilka času, dík!

A nevíš o nějaké implementaci pro ty MCU?
http://www.beremiz.org/
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Mirek Prýmek 12. 03. 2016, 22:10:54
http://www.beremiz.org/
Díky! Je trochu problém se v tom vyznat, co je vlastně co a co to má dělat, ale každopádně mě to mj. zavedlo na zajímavej blog https://serverway.wordpress.com/category/projects/plc-from-scratch/

Mj. tam píše, že těch pokusů je prý teď hodně. A navíc jsem se z jeho diplomky dozvěděl, že slovinsky se controller řekne krmilnik, to taky není k zahození! :))
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Petr 13. 03. 2016, 02:00:52
Zdravím mladší kolegy, po sedmnácti letech práce v průmyslové automatizaci bych se chtěl PLC trochu zastat. Hlavní výhody z pohledu návrháře systémů a programátora:
- Jednoduché připojení prakticky jakýchkoliv V/V do jakékoliv průmyslové sítě (Profibus, průmyslové verze ethernetu, ...). Od digitálních vstupů po pohony či měřicí systémy. To je obrovská výhoda. Žádné bastlení či hraní si s vývojem ovladačů. Moduly jsou v průmyslovém provedení a velice odolné. Rozhodně nesrovnávat s moduly pro Arduino nebo RPi. To jsou jen hračky, které nemají v průmyslu místo.   
- Standardizované jazyky LD, FBD, SFC a pak i nějaký IL nebo něco na způsob jednoduchého C. Můžete se zaměřit na řídicí algoritmus a jazyk je vlastně pořád stejný.
- Realtime systém s definovanou max. dobou odezvy.
- Jednoduchá práce online (za běhu).  Nastavování proměnných (force), změny programu, atd. bez nutnosti zastavovat běžící program.
Možné diskutabilní vlastnosti:
- Závislost na jednom dodavateli. Je to trochu problém, ale výhodou je vysoká spolehlivost. Zákazník má většinou vyškolený personál na jednoho výrobce PLC a tento systém pak požaduje.
- Vysoká cena. Trochu zavádějící argument. Cena PLC systému je většinou v porovnání s cenou řízeného technologického celku zanetbatelná.
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.

Práce programátora (vývoj):
Záleží jakých projektů se účastníte. Na PLC můžete realizovat triviální úlohy typu zapnout/vypnout až po specializované regulátory pro hydrauliku. Na to první Vám stačí SŠ, na to druhé potřebujete znalosti z teorie řízení na úrovni min. klasického VŠ. Bláboly o přeplácených PLC programátorech jsou pak naprostý nesmysl.

Je dobré vědět, že řídicí systémy běží 24/7. Není tady místo pro restarty a výpadky, protože každé zastavení technologie stojí konkrétní velké peníze. Tomu musí odpovídat i kvalita programu. Proto se vše tak dlouho testuje a používají se poměrně triviální ale spolehlivé jazyky. Proto je průmysl tak konzervativní.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: txt 13. 03. 2016, 13:08:02
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
V této oblasti se už začíná trochu šetřit. Místo létání letadlem kvůli každé prkotině lze použít VPN.
Např. http://ab.rockwellautomation.com/Networks-and-Communications/Network-Address-Translation-Device podporuje Ethernet/IP protokol kterým komunikují PLC.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: robotron 13. 03. 2016, 13:22:15
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
V této oblasti se už začíná trochu šetřit. Místo létání letadlem kvůli každé prkotině lze použít VPN.
Např. http://ab.rockwellautomation.com/Networks-and-Communications/Network-Address-Translation-Device podporuje Ethernet/IP protokol kterým komunikují PLC.

To jo, ale predrecnik nemel na mysli jen bezpecnost sitoveho pripojeni, ale provozu jako takovyho -- kdo si vezme na triko, ze zmacknutim klavesy sejme nekde spatne stojiciho delnika do vany s vroucim olejem, treba.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: prezek 13. 03. 2016, 13:47:44
PLC mi nepřijdou nijak závratně drahá. Rád bych s nimi získal nějakou praxi. Teď dělám systémy založené na mikrokontrolérech a od zadání k realizaci je hrozně dlouhá doba. 1. vytipování součástek 2. návrh schématu 3. návrh DPS 4. osazení DPS 5. Oživení DPS, první SW 6. zahození DPS, protože nějaký parametr nevyhovuje (přehřívání, EMI, součástky s jinými parametry, než uvádí výrobce, popletená popiska), návrat k bodu 1.
.... 7. konečně nějak funkční SW. Součástí a HW pak musí být nějaké kontrolní mechanismy, bootloader, obslužný SW pro PC...
U vlastního HW je často potřeba komunikovat s každou součástkou jinak.
U PLC stačí (podle mého nezasvěceného pohledu) nakoupit kompatibilní komponenty, snímače a výstupy a pomocí omezených jednoduchých příkazů vše spojit ve funkční celek.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Yarda 13. 03. 2016, 15:45:00
Teď bude v Brně tahle výstava
http://elektrika.info/news/voucher-na-amper-2016
Divil bych se, kdyby tam nebyly firmy co nějaká ta péelcéčka nabízejí a pořádají o nich školení.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: ewrfiweirh 14. 03. 2016, 11:42:55
 prezek:
Ano mas pravdu par jednoduchych prikazov a vuala... presne ak chces jednoduchy HTML formular par prikazov kdezto v C++ by si musel riesit xyz veci. Ale ak chces od PLC napriklad ovladanie vodnej elektrarne tak uz len to "simple command list" uz nefunguje. :D A k tej praxy. Je uplne genialne ked si doma slasnostne postavis ovladanie vrtacky, Zapni , vypni , chod na poziciu ale uplne na pichu vo vyrobe kde take primitivne veci proste nepouzijes a az tam zistis co je to "PLC chlebik" ale kazdopadne skus.
Pracu PLC programatora si predstav asi takto. Pridem k zariadeniu (dopravnik + miesacka) a nejde len o to ze nasekas program. Musis ho odladit na danu technologiu. Musis si napriklad odladit regulatory, pohony, dokonale ovladat proces tak aby si pripadne vedel upravit co treba. Takze napriklad projekt pre automaticku balicku cukrikov mas tak 30% za PC (programovanie) 30% fyzicky osahavas HW (menice, motory, enkodery....) 40% doladujes a testujes na tu danu technologiu + 100% casu na FAT testy a dokumentacie.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Petr 14. 03. 2016, 12:38:22
Citace
V této oblasti se už začíná trochu šetřit. Místo létání letadlem kvůli každé prkotině lze použít VPN.
Např. http://ab.rockwellautomation.com/Networks-and-Communications/Network-Address-Translation-Device podporuje Ethernet/IP protokol kterým komunikují PLC.

Nejde mi o technické řešení připojení PLC na internet. Stroj nemusí mít motory o výkonu v MW či hydrauliku se silami v MN. I poměrně malý robot Vám může zpřerážet kosti. Sám vím o experimentálním ověření tohoto postulátu spočívajicím ve vyblokování safety okruhu a vstupu na území robota, který se pak nenadále pustil do práce. Věřte, že s tím vetřelcem byl rychle hotov. Budíž mu země lehká.
Pokud uvádíte do provozu nebo testujete reálný stroj s rotujícími nebo pohybujícimi se částmi, tak v civilizovaných zemích ho musíte obehnat páskou a přidat zákaz vstupu. Také tam musí být hlídač pro případ, že by nějaký mentálně znevýhodněný jedinec zákaz vstupu porušil. Dále je dobré předem otestovat ústupovou strategii pro případ nepředvídaných problémů (e-stop, quick stop apod.). Zkrátka někdo musí být schopen okamžitě zmáčknout stopku. To se na dálku dělá dost špatně. Navíc, co když Vaše změna způsobí postranní efekt v jiné části programu? Kdo to pak bude opravovat a znovu testovat? Vůbec už nemluvím o získání kontroly nad PLC nějakým útočníkem. Proto bezpečnost především. Na jednoduché věci lze spíše využít někoho šikovného z místní údržby. Řici mu co a jak a po záloze běžícího programu to změnit a otestovat. Na něco většího si firmy raději zaplatí fyzickou přítomnost programátora. Pokud se jedná o přidání nové funkce, tak se často dělá i nový integrační test.
Ještě poznámka. Na většinu SW v průmyslové automatizaci se vztahuje záruka. Součásti projektu je tzv. Final Acceptance Test, který musí zákazník podepsat. V té době už musí být všechny nedodělky v SW uzavřeny. Jinak nejsou peníze.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Pavel Stárek 15. 03. 2016, 12:53:42
Hlavně je potřeba si uvědomit, že je obrovský rozdíl v programování PLC a desktopových aplikací. Je to dáno už z principu věci. Jak tu již bylo popsáno, PLC funguje (zjednodušeně) takto:

1. - načtou se do proměnných stavy vstupů
2. - vykoná se vlastní program (jedna nebo několik POU - Program Organisation Unit) napsaný v některém z jazyků (IL, ST, LD či dokonce C/C++)
3. - přepíšou se hodnoty na výstupy
4. - ve volné chvíli (tzv. idle time) PLC komunikuje s vnějškem například pro potřeby SCADA programů (OPC, etherenetové komunikace atd.)
5. - jde se na bod 1

Samozřejmě se hlídá doba smyčky (tedy bod 2 nesmí překročit určitou dobu + tolerance) tato doba můžou být stovky mikrosekund až třeba jednotky vteřin, podle toho, jak rychle chci reagovat v programu na "vnější svět - I/O" a samozřejmě podle typu technologie kterou řídím. Třeba na řízení dopravníku a zastavování od fotonky mi stačí smyčka 10ms (což je z hlediska moderních PLC strašně dlouhá doba), kdežto třeba na skenování čárových kódů na jedoucím dopravníku 1,6m/s s jejich realtime odesíláním z PLC někam pryč si nastavím smyčku třeba 1ms, nebo méně. A hlavně při programování PLC se nesmí zapomenout, že program běží stále v té smyčce, na rozdíl od programování desktop aplikací na PC.


Kdežto programování pro desktop je zcela něco jiného. 99% času programu se čeká na nějakou uživatelovou reakci (tedy na nějaký event) a 1% je vlastní program, který něco udělá.

Jinak samozřejmě lze na některé účely využít destičky typu Arduino (jehož programování se spíš podobá PLC programování), nebo RaspberryPi, avšak nejsou to vhodné věci na řízení technologie v ceně statisíců až X milionů korun.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: vana-hb 21. 03. 2016, 09:11:39
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
Řídící systémy jsou k internetu připojeny běžně a je vidět, že hlupák nebudeš možná ty. Budeš se divit, ale existují vpn sítě které bezpečnost docela dobře řeší. Nevim co to má společného s bezpečností lidí v jakémkoliv směru???
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: SP. 21. 03. 2016, 17:31:36
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
Řídící systémy jsou k internetu připojeny běžně a je vidět, že hlupák nebudeš možná ty. Budeš se divit, ale existují vpn sítě které bezpečnost docela dobře řeší. Nevim co to má společného s bezpečností lidí v jakémkoliv směru???

Hochu, vylez ze své IT bubliny, přečti si ještě jednou celý příspěvek od pana Petra a zamysli se nad tím.  Petr ví moc dobře o čem hovoří. Ty ne. Nevím, co jsi chtěl naznačit první větou, pokud jsi chtěl říct, že je pan Petr hlupák, tak se mu omluv, pokud ne zkus to napsat srozumitelněji.

Táta cca od 1980 navrhuje zapojení PLC a dělá technika při uvádění zařízení do provozu. V mládí jsem s ním jezdil jako výpomoc, ale obor mě nezaujal.

Praxe při uvádění zařízení do provozu nebo úpravách je následující: O zařízení se stará tým techniků a programátoři. Technici řeší problémy typu nefunkční, špatně zapojené snímače. Testují se bezpečnostní okruhy. Po vyřešení problémů a kontrole bezpečnostní okruhů programátor spouští program a zařízení se rozbíhá, technici s vysílačkami jsou na místě u kritických přívodů energie (Plyn, stlačený vzduch, elektřina, .... ). V případě, že dojde k něčemu neočekávanému, technici na povel velitele (hlavní technik, nebo programátor) zastaví příslušné přivody energie. Potom se pátrá po příčině, to už bývá programová záležitost. Dále se zařízení testuje v rámci daných provozních omezení. Vždy je ale nutná součinnost techniků a programatorů přímo u zařízení. Chyba v programu může i přes všechny bezpečnostní okruhy pořád způsobit smrt spousty lidí a značné materiální škody (Desítky milionů Kč). Takže představa, že programátor bude sedět v práci a přes net nahraje do PLC program a potom ho upraví je zcela mylná. Bez součinnosti s techniky na místě to prostě nejde a seriozní dodavatel zařízení to ani jinak nedovolí.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: kkjan 21. 03. 2016, 17:33:07
S bezpecnostou ludi to ma spolocne hodne ak nie najviac. Napriklad ak urobis nejaku zmenu na dialku tak ako si zabezpecis aby ti  obsluha nestala pri stroji ak by daco nevyslo? Alebo ako zabezpecis aby sa ti nejaka obsluha nemotala pod nejakou napriklad nadrzou ak by nahodou pretiekla? Pripadne ak daco nevyjde ako ma tak ak nie si priamo pri tom tak nemas sancu rychlo a promptne reagovat na vzniknutu situaciu apod. napriklad aj nudzovym stop tlacitkom:-D Treba si uvedomit ze PLC je priemysel a tam sa pracuje i s tocivymi strojmi, vysokym napatim, nebezpecnymi latkami, kyselinami, zasadami plynovym ohrevom a neviem cim vsetkym este. Ano vyuziva sa to a docela hodne ale iba ako servis na vzdialenu diagnostiku pripadne pre minimalne zasahy. Urcite nie  pre kompletne spustanie technologie alebo rozsiahlejsie upravy programu.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: v 21. 03. 2016, 18:41:26
Napriklad ak urobis nejaku zmenu na dialku tak ako si zabezpecis aby ti  obsluha nestala pri stroji ak by daco nevyslo?
úplně stejně jako když se to dělá místně?
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Yarda 22. 03. 2016, 07:36:12
Napriklad ak urobis nejaku zmenu na dialku tak ako si zabezpecis aby ti  obsluha nestala pri stroji ak by daco nevyslo?
úplně stejně jako když se to dělá místně?
IMHO je dost důležité, aby se řešitel seznámil, nejlépe osobně a opakovaně se situací na místě, kde jeho zařízení má pracovat. Je trochu rozdíl vymýšlet řešení v pohodlí kanceláře a přímo u zařízení ke kterému je přístup vleže po zádech s baterkou v zubech, aby se zjistilo, že vedle je instalované zařízení jiného řešitele co kolem sebe fouká horký vzduch a proto PLC trvale indikuje překročení maximální teploty >:(
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: Pavel Píša 25. 03. 2016, 12:17:48
Dobrý den,

...a ono to (zřejmě) není potřeba řešit u spousty aplikací. Docela mě dostala přednáška Pavla Píši z FELu (který určitě ví, o čem mluví), kde rozebíral, jestli je na automatizaci použitelné RPi: https://www.youtube.com/watch?v=I_4cAhW46dM Dost zajímavá je pasáž, kde ukazuje, jak se latence na non-realtime OS dá docela solidně řešit prostě statisticky - pokud to na X pokusů projde, tak je to na daný účel dostatečné (EDIT: na videu někde kolem 1:10:00).

Pokud je na leccos použitelné RPi, tak s jednoúčelovými MCU bez OS je situace ještě o řád lepší...

byl bych velmi nerad, aby moje přednáška vzbudila v naivněji myslících jedincích a především obchodních (s jejich nechápáním reality mám dost zkušeností) představu, že solidní HW není potřeba a vše nahradíme Raspberry Pi za pár korun. Hlavní motivace k přednášce byla, že i nadšenci mají možnost otestovat přístupy, které se přibližují profesionálním řešením a na svoje hraní mohou taková řešení použít. Zároveň nemusí padat údivem před PLC a mohou si uvědomit, že ty firmy, které PLC vyrábí hluboko pod vrstvami reklamních sloganů a PR používají často otevřené technologie a GNU/Linux, který většina z čtenářů Roota velmi dobře zná.

Bezpečně například vím, že Natial Instruments přechází ve svých novějších vlajkových systémech na fully-preemptive Linux kombinovaný s FPGA (Xilinx Zynq) a spolupracuje s OSADL na trvalém dohledu nad stavem jádra. Zajímavá a velmi otevřená přednáška a diskuze byla na loňském Real-Time Linux Workshopu

https://www.osadl.org/Abstract-7-From-in-house-dedicated-RTO.rtlws17-abstract7.0.html

Přednáška byla v rámci prezentace firem a vývojářů RT patchů a spíše určená pro "domácí publikum" takže stejně jako interní přednáška BMW o zpracování obrazu (detekci chodce) a další nejsou zaznamenané a nejsou ani v tištěných materiálech konference.

Pokud chcete takové "RPi/Arduino" od NI použít, tak jsme pro sestavu s s okolo dvacítkou digitálních vstupů a výstupů, podobným počtem analogových kanálů, nějakými (překvapivě) vstupy PWM a komunikacemi CAN, FlexRay, Lin dostali nabídku něco mezi 500 tisíc až miliónem kč. Protože to potřebujeme pro testování našeho HW (jednotky na bázi bezpečnostního procesoru navrženou původně jednoho velkého výrobce automobilů) a testovací prostředí má běžet jen v místnosti a nakonec jakákoliv chyba i den odstávky nic neznamená, tak si kvůli ceně nakonec vyhovující řešení ubastlíme na Begle Bone Black s našimi studenty.

Ale pokud by se jednalo o reálné nasazení v průmyslu, kde musí být zajištěná spolehlivost, servis, certifikace, tak by volba padla na HW od prověřeného výrobce. Ono i PC, které lze dodat do průmyslu a má naději vydržet v takových podmínkách budete kupovat třeba od firmy Kontron a cena s V/V kartami bude srovnatelná.

Co se programování týče, tak NI nám nabízelo i možnost vlastních bloků do FPGA části i programování na úrovni OS. Ale hlavní hodnota jejich řešení je vizuální nebo PLC programování, kdy jsou bloky a kód na nižší úrovni prověřené.

Sám nemám programování na úrovni PLC jazyků rád a v oblasti, kde především působím - to je interní firmware laboratorních a lékařských přístrojů, ani hotové PLC kvůli ceně a zástavbě použít nelze. Pro průmyslové aplikace ale v mnoha případech striktní programování na úrovni PLC jazyků a blokových řešení je z hlediska kontroly návrhu nutností. Moje expertíza je pak spíš na úrovni vytváření a konzultací řešení pro ty výrobce PLC, kde se plně znalosti RTOS projeví.

Velká část PLC je pak založena nebo přechází na řešení založená na jádře Linux. Wago již desítku let, Siemens po ztrátě týmu okolo x86 kompilátoru přešel (pokud jsou tamtamy pravdivé) před deseti lety s celou vlajkovou lodí Sinumeric na Linux atd.

Mnoho PLC aplikací není jen o otočení ventilu, kde jsou sekundy času. Návrh a ověřování smyček PLC pak není zcela triviální a třeba v systémech NI se rychlé části návrhu převádí na kód/konfiguraci pro FPGA.

Přesto, že se mi prostředí OS Linux líbí a na desktopu je mým hlavním OS asi od roku 1994, tak pro kritické aplikace si stále myslím, že nedozrál a pro mnoho ani nikdy nedozraje. Když jsme před deseti lety řešili návrh hardware infúzních pump, tak jsem rovnou Linux a všechny jeho RT varianty vyřadil a použili jsme otevřený systém RTEMS, který vznikl pro americkou armádu a používá ho ESA i NASA. Stejně jsme ještě systém kvůli bezpečnosti rozdělili na dva procesory a na menším MCU běží řídicí a kontrolní algoritmy bez OS. Dnes je Linux s FPK, co se týče predikce spolehlivosti, udržení latencí odezvy v mnoha oblastech použitelnou alternativou. Kvůli požadavkům na grafiku a ovládání (Qt, animace, video atd.) jsme demonstrátory nové generace infúzní techniky řešili na Linuxu. Ale z hlediska bezpečnosti z toho stále dobrý pocit nemám. Jádro je pouze testovatelné, tak obrovské množství kódu verifikovat nelze. A to je problém. Existují snahy vytvořit podklady, které by umožnily certifikovat řešení na bázi subsetu Linuxu na úrovni SIL2 https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html .

Pro mnoho aplikací je to ale málo  a hardware, který má být opravdu bezpečný většinou ani běh systému velikosti Linuxu neumožňuje. Systémy s plně ECC zabezpečenou Flash, RAM, sběrnicemi a vícenásobným CPU mívají dnes okolo max 200, 300kB RAM a 3 MB Flash. Takže i ta extrémně testovaná výkonná PLC postavená na Linuxu jsou použitelná jen tam, kde stačí zaručení středních dob bez poruchy v miliónech hodin - to je zjednodušeně aplikace, které ohrožují okolí buď jen ekonomicky nebo v jednotkách lidských životů (například jeřáb, jeden ze SIL2 Linux use cases). Pro atomové elektrárny a letadla musí být kritické systémy v jiné třídě bezpečnosti, to dnes znamená extrémně testované a analyzované menší RTOS, specializované nástroje, většinou programování bez jediného použití dynamicky alokované paměti atd.

Co se týče predikce do budoucnosti, tak z pohledu bezpečného programování bude požadavek zůstávat při návrhu aplikací u "relátkových" jazyků - PLC. Ve firmách ale začíná zásadní problém s množstvím různých PLC a především po jejich propojení do sítě, která je přes vyšší úrovně propojená s Internetem, začíná být zásadním problémem bezpečnost a možnost update firmware. Tím již přestává platit původní doktrína nasazení PLC a desítek roků spolehlivé operace bez update. Přitom zajištění update starých PLC je problém. Začíná se tedy objevovat názor deklarovaný lidmi, kteří jsou opravdu špička a vidí do přípravy nové generace řešení od velkých firem (Siemens atd.), že je potřeba vzít PLC z rukou techniků a přenést je pod zprávu síťařů do servroven. Představa je taková, že se bude používat výkonné železo (mnohaprocesorový Intel atd.) kdy v budoucnu bude možné zajistit jeho spolehlivost (ono ECC a mnoho dalších kontrolních technologií již výkonné procesory integrují) a takový hardware se zpátky rozparceluje na jednotlivé subsystémy, ve kterých poběží jednotlivá PLC realizovaná třeba pomocí RTOS softwarově. Vlastní řízení ke strojům bude dotažené rychlými distribuovanými vstupně výstupními sběrnicemi a vlastní IO rozhraní budou tak jednoduchá, že je po mnoho let nebude nutné updatovat. Příkladem je třeba projekt Siemensu Jailhouse

https://github.com/siemens/jailhouse

Určitě na "serveru" pro správu poběží Linux, ale kritická PLC budou nejspíš pod jiným OS. My třeba uvažujeme o systému Erica Enterprise od našich partnerů a to i pro řízení autonomních vozidel na platformě spíše postavené nad ARMem

http://hercules2020.eu/

K centralizaci mnoha řídicích procesů v automobilech, mobilních telefonech na méně výkonnějších procesorů dojít nejspíše musí, současná situace s mnoha desítkami rozdílných systémů uvnitř jedné krabičky od tictacu je neudržitelná. V průmyslovém řízení to asi také tak bude, druhou alternativou je naopak distribuce řízení, kdy jednotlivé vodiče již jsou a do budoucna plně budou nahrazené sběrnicemi. Ale jak bude rozložená v těchto systémech inteligence a řídicí algoritmy je otázkou. Dnes již komunikační rychlosti dovolují rozdělení v podstatě libovolné.

Jinak pokud máte zájem se naučit jak programovat a pracovat s PLC, tak na naší katedře je celá skupiny na tuto oblast zaměřené. I když vždy je základem mít představu, jak vytvořit algoritmus, chápat, jak se ovlivňují a synchronizují věci probíhající na mnoha jednotkách (a i v reálném světě) paralelně a jaká existují fyzikální omezení (na komunikaci po čipu, sběrnici, zastavení motoru) a dynamika vnějšího světa mimo počítač, a tak je vlastně jedno, jestli dobře umíte základy souhry procesů v tisíci systémovém cloudu, nebo se problémy naučíte na souběhu a pipeliningu instrukcí na jednoduchém CPU, nebo na začátek programujete Lego robota http://www.robosoutez.cz/ . Pokud si dokážete ze všech takových předmětů a externích podmětů vytvořit schopnost nadhledu a i analýzy od základů směrem nahoru, tak zjistíte, že se oblasti překrývají a schopnosti pohledu z různých perspektiv a oborů se vzájemně násobí. Zde mám obavu, že mnoho studentů si to dnes neuvědomuje a chce rychle být špičkou (nebo dobře oplaceným zaměstnancem) v úzkém oboru.

Pro zájemce o pochopení a pohrání si s řízením na levném (často vysloveně "pouťovém") HW, připravuji s redakcí Roota dva články shrnující moje prezentace a bude-li zájem, tak třeba bude i pokračování. Pokud by se našli zájemci, co by si téma pořádně nastudovali, zkusili si mnou prezentované levné řešení nabastlit a pak se chtěli sejít a poradit s dotažením do funkčního stavu, tak nabízím uspořádat seminář/workshop v rámci setkání SUT. Bohužel z minima reakcí na přednášky mám spíš pocit, že většina se ráda nechá pobavit, ale o to trávit kvůli opravdovému pochopení hodiny s pájkou a desítky hodin před klávesnicí zájem nemá.

Pokud chcete pokročit na vyšší úroveň znalostí, tak je nejlepší se po nějakém takovém seznámení (např. náš předmět
Programování systémů reálného času  https://support.dce.felk.cvut.cz/psr/) zapojit do nějakého projektu na některé univerzitě, kde se počítá s tím, že na projektu nepracují ještě hotoví, najmutí profesionálové/zaměstnanci a máte možnost se učit od pedagogů/vývojářů se zkušenostmi a především od svých kolegů, kteří třeba již v určité oblasti pokročili dále (někdy i než jejich pedagogové/vedoucí). Přitom v projektech na školách není většinou problém s uzavřeností, hlídáním know-how a konkurencí (mezi-firemní i mezi zaměstnanci) jako je v reálném životě.

S pozdravem

Pavel Píša

ČVUT FEL, Katedra řídicí techniky, člen týmu
http://industrialinformatics.cz/

Vývojář a vedoucí koncepcí řešení firmy
http://www.pikron.com/
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: v 25. 03. 2016, 12:48:36
Bohužel z minima reakcí na přednášky mám spíš pocit, že většina se ráda nechá pobavit, ale o to trávit kvůli opravdovému pochopení hodiny s pájkou a desítky hodin před klávesnicí zájem nemá.
a nebo to může být formou, já jsem neschopen přetrpět sledování přednášky (víc než 10min) na youtube, nikdy bych na žádnou nejel, ale už třetí rok se bavím vývojem překladače IEC61131-3 :)
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Jarous 25. 03. 2016, 16:19:20
Ahoj všem

dělám programátora PLC ( DCS , PAC,  HMI , SCADA atd. ) už 25 roků. A mohu z vlastní zkušenosti říct, že

programování u toho není zdaleka to hlavní. Ten kdo to chce dělat, by měl být všeobecně technicky vzdělán,

nejlépe VŠ elektro, nějaký praktický co nejobecnější obor.
Můžete se dostat k programování nalých stroječků až, po rozsáhlé technologické systémy za miliardy.
A hlavně platí, že pro zbrklouny v tonhle oboru místo není. Čím váš "software" řídí dražší technologii, tím

jste lépe placeni ( bez ohledu na složitost software ).
Software jsem napsal v uvozovkách proto, že programy PLC z hlediska práva vlastně SW není, je to pouhé

nastavení stroje. Takže programatoři i z jiných firem po sobě běžně opisují, kopírují celé programy a

vzájemně si upravují software ( po záruce ).
Každá tvorba technolgického softwaru začíná jednáním s výrobci nebo správci technologie ( kteří většinou

neví co chtějí ). Kdo je schopen proniknout do technologického problému co nejvíce má obrovskou výhodu.
Bude te to vy, kteří při najíždění budete zírat do dynamizovaného software a budete muset udělat rychlý

zásah pokud se technologie, kotel , turbína , chemický reaktor atd. začne chovat nenormálně a budete muset

vědět co udělat. Takové stresové šoky, kde se z vysílaček ozíval křik a technologové mluvili jeden přes

druhého jsem zažil několik.
Samostatné kapitoly jsou je programování bezpečnostních a kritických aplikaci. Zde jste svázáni předpisy a

cetifikovaným hardwarem i programovacím prostředím.
Pak musíte řešit programování paralelních ( redundantních ) CPU jednotek, nebo paralelních celých systému a

ošetřovat jak při výpadku a poruše některé konponenty zaskočí konponenta jiná.
Dále nastupují pravní a vztahové problémy. Pokud třeba na žádost nějakého technologa provedete v SW nějakou

úpravu "per huba" a ta se ukáže jako špatné nebo dokonce způsobí škodu. Pokud to nemáte na papíře máte

problém.
Dále programátor Velkých systénů také provádí nebo se zůčastní návrhu struktury a topologie systému včetně

komunikací a spojením na vedlejší tecnologie a propojení do administrativních systémů firem.
Také musím říci,že specializované školy na programování jsou dle mého názoru trochu mimo mísu a je skoro jedno jestli tuto práci jde dělat člověk co vystudoval PLC nebio třeba el. pohony. Znalost technologické problematiky je zde skoro důležitější než znalost programování.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Mirek Prýmek 25. 03. 2016, 16:37:13
Dobrý den,
Dobrý den, díky moc, že jste mezi nás zavítal a věnoval nám tak vyčerpávající komentář, je to velká čest! (bez ironie)

byl bych velmi nerad, aby moje přednáška vzbudila v naivněji myslících jedincích a především obchodních (s jejich nechápáním reality mám dost zkušeností) představu, že solidní HW není potřeba a vše nahradíme Raspberry Pi za pár korun.
Vzhledem k tomu, že jste reagoval na můj příspěvek: takovému dojmu jsem nepodlehl a ani ho nechtěl vyvolat. Pokud to tak působilo, je to moje chyba, nevyjádřil jsem se dostatečně srozumitelně.

ve kterých poběží jednotlivá PLC realizovaná třeba pomocí RTOS softwarově. Vlastní řízení ke strojům bude dotažené rychlými distribuovanými vstupně výstupními sběrnicemi a vlastní IO rozhraní budou tak jednoduchá, že je po mnoho let nebude nutné updatovat. Příkladem je třeba projekt Siemensu Jailhouse

https://github.com/siemens/jailhouse
To je přesně to, co mě zajímalo, děkuju moc za odpověď!

Když už vás tady máme, můžu otázku? Zajímalo by mě, jaký volně šiřitelný RTOS byste doporučil právě pro to amatérské hraní a seznamování se - ideálně aby se výsledky pokusů pak třeba daly použít i polo-profesionálně (např. nějaká ta nekritická domácí automatizace vyrobená pro sebe sama, ne komerčně prodáváná).

Krátce jsem zkoušel několik RTOSů, konkrétně pro devboard stm32f429 a nejlíp se mi pracovalo s ChibiOS v kombinaci s grafickou knihovnou uGFX. Máte případně nějaký jiný tip, co by pro takové nasazení bylo vhodné? Jaký OS používáte pro výuku? Děkuji předem za odpověď.

Pro zájemce o pochopení a pohrání si s řízením na levném (často vysloveně "pouťovém") HW, připravuji s redakcí Roota dva články shrnující moje prezentace a bude-li zájem, tak třeba bude i pokračování. [...] Bohužel z minima reakcí na přednášky mám spíš pocit, že většina se ráda nechá pobavit, ale o to trávit kvůli opravdovému pochopení hodiny s pájkou a desítky hodin před klávesnicí zájem nemá.
To je skvělé! Myslím, že by to mohlo nemálo lidí chytnout, nejrůznější články a přednášky o "domácím bastení pro zábavu" jsou myslím hodně populární. Málo reakcí na přednášky by mohlo být způsobeno tím, že jsou Vaše přednášky vyčerpávající a laik se cítí být spíš ohromen (aspoň já ano) než že by ho napadala spousta otázek :) Pokud byste byl schopný a ochotný napsat návod dostatečně jednoduchý a zajímavý i pro nás laiky, abychom si mohli po večerech pohrát s technologiemi a postupy, ke kterým se jinak nedostaneme, byl by o to imho zájem, nepropadal bych skepsi! :)
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Pavel Píša 25. 03. 2016, 21:40:53
Tak se omlouvám, napsal jsem obsáhlou odpověď, ale když jsem ji odeslal tak mě redakční systém odhlásil a o text jsem přišel a čas už nemám.

Takže krátce

FreeRTOS ne

mBED https://www.mbed.com/  ano (jen ze zběžného testování) chybí Posix API, uživatelsky přívětivé C++ (jako Arduino (které poslalo svět ve vývoji o roky nazpět) ale u mBED o řád výš), jen ARM

RTEMS https://www.rtems.org/ ano a to v budoucnu (4.12) i na SMP integrace s GCC OpenMP atd (4.11 SMP považovat jen za technology preview, jinak OK i Posix API)

Nuttx http://nuttx.org/ ano (hezké API, Posix, snaha být malý Linux) zatím jen na UP a tak max 5 až 10 procesů v ready queue. Na rozdíl od autora si msylím, že k SMP a propustnosti má strašně daleko, velmi malé nároky

S dalšími již osobní zkušenost nemám

Erika Enterprise http://erika.tuxfamily.org/ podle partnerů a studia kódu rozumné

TinyOS koncept nezavrhuji

Contiky kód vypadá rozumně

A to je pro teď asi vše.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: v 25. 03. 2016, 21:52:56
FreeRTOS ne
proč?
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Pavel Píša 26. 03. 2016, 11:42:40
FreeRTOS ne
proč?

V ztracené odpovědi jsem to měl rozumně rozepsané.

FreeRTOS, alespoň podle všech informací, co mám, je řešení, které vysloveně nepodporuje komunitní vývoj. Zkusím vysvětlit dále. FreeRTOS nabízí relativně použitelný plánovač a základní synchronizační primitiva ovšem jen s vlastním nepřenositelným API. Pro malé systémy a stavbu vlastních řešení to nemůsí být vysloveně špatně a mnoha výrobcům čipů to dokonce vyhovuje. Každý má své HAL řešení (např Ti HalCoGen) které s FreeRTOS sintegruje. Stále OK až na to, že tím ztrácíte jeden z hlavních důvodů používání operačních systémů -- možnost přenést aplikaci používající rozumné API ovladačů na libovolný daným systémem podporovaný HW nebo architekturu. Je to mínus, ale lze se toho stále vzdát. O něco horší je, jak je kód FreeRTOS bez rozumných vrstev naplácaný do sebe s šíleným množstvím ifdefů (žádné pořádné rozdělení jako třeba RTEMS SuperCore, architekturně závislá část, BSP, Posix obálka, RTEMS originál API obálka). Jen analýza kódu je pak šílená a nakonec třeba zjistíte, že do verze vydané před před rokem a půl na bezpečnostních procesorech Ti dochází k přeplánování na v přerušení uvolněný task s vyšší prioritou až při příštím tiku nebo když se task s nižší prioritou sám vzdá procesoru nebo zastaví na synchronizačním objektu. Z pohledu kritické aplikace to lze považovat za kooperativní plánovač, a ten spíš do takové aplikace nepatří. Přitom zdokumentované takové chování není a v změti ifdefů se na začátek zdá, že to může být v pořádku. Ale není, to by si musel člověk základní operace pro Cortex-R přepsat a doplnit hooky po svém. V základu OS to nebylo. Teď je to zrovna na TMS570 vyřešené přes phantom interrupt, OK. Ale než použijete FreeRTOS někde jinde, tak si proveďte kompletní analýzu, co se vám vlastně zkompilovalo. A v tom prasáckém kódu to nakonec může znamenat víc času než si jednoduchý přepínač tasků napsat vlastní. OK, lze říct, že systém je ve vývoji a že se díky otevřenému charakteru a příspěvkům komunity časem dostane na slušnou úroveň.

Jenže s komunitou je hlavní kámen úrazu. FreeRTOS vás donutí používat nepřenositelné API, přitom pro svojí deklarovanou jednoduchost neobsahuje drivery téměř žádných periferií a ani příklady jak periferie typu SPI, CAN, I2C implementovat a jak vytvořit API nebo IOCTL podle nějakých pravidel. Přitom napsat na různých architekturách a BSP použitelnou infrastrukturu pro jednotlivé třídy zařízení je mnohem více kódu než jádro OS a podpora architektur. (Linux arch 136M (všech 31), kernel 7.2M, drivers 387M). Firmy a jejich obchodníci nadšeně vyberou OS zdarma (vždyť to má v názvu -- FreeRTOS), ale vlastně v každé firmě většinu OS píší znova a bez dobrých příkladů a často programátorští začátečníci. Výsledkem je vysloveně spatný kód a model. Každý má pak vlastní API zařízení a nemohou tedy využít efektu spolupráce. Některým firmám to i vyhovuje, nechtějí aby jejich "skvělou" investici do podpory jejich NDA hardware dali někomu zdarma. Bohužel i když si uvědomí, že mají totální bastl, tak alespoň podle mého dřívějšího hledání nějaká centrální koordinace práce na FreeRTOS neexistuje.

Důvody k této situaci jsou celkem pochopitelné, FreeRTOS vás dovede k používání API, ze kterého aplikaci přepsat na něco jiného je extrémně nákladné a tak nakonec začnete hledat, jak se ze situace dostat. A dostanete nabídku na certifikovaný SafeRTOS od firmy WITTENSTEIN. FreeRTOS je v podstatě code drop (možná i naschvál staré verze) z několika adresářů jejich komerčního řešení. V okamžiku, kdy do jeho nákupu nainvestujete velké peníze a dostanete i USB stack a další subsystémy ovladačů, tak přece nebudete vlastní vývoj i jen proti původnímu FreeRTOS dávat zdarma. A i když by jste chtěli, tak v okamžiku, kdy využijete infrastrukturu SafeRTOS, tak ani licenčně nemůžete. Asi vám stejně jako u Mathworksu nezbude nic jiného než pod cenou prodat své řešení do licencovaného poolu společnosti kontrolující danou technologii.

Alespoň takto jsem eko(nomy)systém okolo FreeRTOSu hned v jeho začátku vyhodnotil já a i při zatlačení na vystavovatele nějakého rozšíření pro FreeRTOS a SafeRTOS na letošním Embedded Worldu jsem nedostal uspokojivou odpověď, která by naznačovala, že se situace od té doby zlepšila.

U RTEMSu, Nuttx atd. opravdu neexistuje hlavními vývojáři podporovaná shaddow branch pro komerční řešení. Není to žádný code drop, vývoj probíhá v hlavních větví veřejných repositářů. Když máte nápad nebo nové drivery a kód napíšete dobře, dostanete ho do mainline. V mainline vidíte, jak se ovladače pro dané třídy zařízení dají napsat správně a s využitím již existující infrastruktury, takže je to psaní i pokud ovladač ještě neexistuje o řád jednodušší, při integraci do mainline dojde k review od těch, co znají systém nejlépe, takže máte určitou jistotu, že neděláte něco špatně, že díky nepochopení dokumentace chodí řešení jen náhodou a po drobném update systému nebo při jiném časování nedojde třeba k těžce odhalitelným chybám které se projeví pádem celého systému jednou za rok (v nejnevhodnější chvíli - selhání brzd, start letadla atd.). Zároveň pokud firma řešení nad shaddow branch používá, tak postupně oddiverguje od mainline a řeší opakovaně problémy, které jsou na mainline vyřešené správně a tak třeba jádra Androidu různých výrobců táhnou s sebou tisíce patchů z nichž je většina úplně zbytečných. Při integraci podpory a ovladačů do mainline se pak většinou přizpůsobení změnám infrastruktury provede v rámci změn v jádře/subsystémech. Prostě postupné sed/Coccinelle editace. Pokud po letech divergence chcete projekt/produkt nakolejit zpět na mainline, tak je to často těžší, než portaci provést celou znova. To si většina firem neuvědomuje a pak shání pomoc například u i u naší firmy.

Takže to je můj pohled na FreeRTOS a i vývoj trochu obecněji a doporučení spolupracovat s těmi, kdo mají o spolupráci a vzájemnou pomoc zájem a nekrmit vlastní energií ekonomiku, která je založená na zavírání kódu.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: PLC vývojář 05. 09. 2018, 13:06:30
- Nutnost cestovat. PLC lze samozřejmě připojit k internetu, ale ještě jsem nezažil tak hloupého zákazníka, který by to udělal. Ovládat technologický komplex za miliony eur na dálku je už kvůli bezpečnosti lidí ošemetné.
Řídící systémy jsou k internetu připojeny běžně a je vidět, že hlupák nebudeš možná ty. Budeš se divit, ale existují vpn sítě které bezpečnost docela dobře řeší. Nevim co to má společného s bezpečností lidí v jakémkoliv směru???

Hochu, vylez ze své IT bubliny, přečti si ještě jednou celý příspěvek od pana Petra a zamysli se nad tím.  Petr ví moc dobře o čem hovoří. Ty ne. Nevím, co jsi chtěl naznačit první větou, pokud jsi chtěl říct, že je pan Petr hlupák, tak se mu omluv, pokud ne zkus to napsat srozumitelněji.

Táta cca od 1980 navrhuje zapojení PLC a dělá technika při uvádění zařízení do provozu. V mládí jsem s ním jezdil jako výpomoc, ale obor mě nezaujal.

Praxe při uvádění zařízení do provozu nebo úpravách je následující: O zařízení se stará tým techniků a programátoři. Technici řeší problémy typu nefunkční, špatně zapojené snímače. Testují se bezpečnostní okruhy. Po vyřešení problémů a kontrole bezpečnostní okruhů programátor spouští program a zařízení se rozbíhá, technici s vysílačkami jsou na místě u kritických přívodů energie (Plyn, stlačený vzduch, elektřina, .... ). V případě, že dojde k něčemu neočekávanému, technici na povel velitele (hlavní technik, nebo programátor) zastaví příslušné přivody energie. Potom se pátrá po příčině, to už bývá programová záležitost. Dále se zařízení testuje v rámci daných provozních omezení. Vždy je ale nutná součinnost techniků a programatorů přímo u zařízení. Chyba v programu může i přes všechny bezpečnostní okruhy pořád způsobit smrt spousty lidí a značné materiální škody (Desítky milionů Kč). Takže představa, že programátor bude sedět v práci a přes net nahraje do PLC program a potom ho upraví je zcela mylná. Bez součinnosti s techniky na místě to prostě nejde a seriozní dodavatel zařízení to ani jinak nedovolí.

Kolega má pravdu. Řešení Safety z dálky je blbost a také se to striktně nedoporučuje. Safety neřeší VPN to jest v PLC programátorském slova smyslu, ale jen ,, bezpečnejší připojení do interní sítě´´ to jsou dva úplně rozdílné případy.
To co se ti snaží kolega vysvětlit s tou IT bublinou neber jako urážku, ale ber to tak, že on ví co to znamená když ti prolítne nějaký bit někde kde by normálně neměl (mě se to stalo už nesčítaně a pak seguencer z toho měl trauma :-) bavíme se o strojích velkých jako celá hala kde cykly mají běžně 40 - 100 ms u procesoru Siemens S7-400 Fail-Safe CPU a u strojích kde jsou pro změnu zase 4 CPUčka v ještě ne úplně dostavěné další hale).

Já osobně už mám za sebou několik projektů, ale co se týče safety funkcí tak před tím mám OPRAVDU VELKÝ RESPEKT.
Jednou se mi stalo i to co zde bylo popsáno s robotem KUKA, kde jsem zapoměl v safety FC a safety DB vrátit zpět některé skutečnosti. Nahrál jsem vše do CPU a uvedl do RUN a stroj se najednou rozjel a co se nestalo, omylem jsem bypassoval bezpečnostní okruch dveří, který byl na Profi-Safe telegramu a vuala vzniklo málem neštěstí, kde robot se rozjel a já byl pořád v kleci s otevřenými dveřmi. Detaily dále nemusím zmiňovat.

Tímto jsem se snažil naznačit to, že PLC programování na dálku téměř nikdo z mých zakazniků nedělá ne jenom kvůli safety, ale i z principu.

Jinak co tady čtu, tak názory TwinCATu vedou od Beckhoff, nemám pravdu?
Jen tak se ptám jelikož vidím názvy jako LD, IL atd.
U Siemensu máme strukturu jazyků prakticky stejnou (už jenom proto, že jsou standarizované), ale pod jinými názvy jako LAD, FBD, STL, SCL. Osobně preferuji pouze SCL (vypadá to skoro jako Pascal), ale u Safety jde pouze LAD a FBD, tam jsem musel ustopit. XD
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: anon36 06. 09. 2018, 16:51:15
Co to tady čtu, ta práce vypadá docela zajímavě, hlavně to cestování, a taky že člověk dělá na něčem hmatatelném.
Já teď dělám bakaláře na FEL, ale informatiku, takže se s tímhle ve škole docela minu..
Myslíte, že o mě firmy budou mít zájem, i když studuji "čistou" informatiku, ne elektro? A nebo, jak se k tomuhle oboru ještě na škole přiblížit?
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Youda 06. 09. 2018, 17:38:59
PLC programovani je velice dobre placene take z duvodu, ze mas velkou odpovednost.

Znam pripad OSVC PLC kodera, ktery momentalne splaci nekolik milionu skody, protoze programoval linku, ze ktere nekdo ukradl dorazove cidla a bez nich doslo k havarii. Prohral u soudu, ze SW mel i s eventualitou ukradenych cidel pocitat.

PLC koder jedine jako zamestnanec bez podepsane osobni zodpovednosti - tedy max 4,5 mesicniho platu pokuty.
Název: Re:Promena programatora Desktop -> PLC
Přispěvatel: ffef 06. 09. 2018, 19:42:08
Zadek  otlačený z letadel a aut, bolavá záda ze špatných hotelových postelí, žaludeční vředy z hospodské stravy.
Programování PLC (pokud Vás nenutí být prase a neprogramuje se to ve strukturovaném textu) je vcelku triviální.
Grafiku na OP řešíte taháním myší, o komunikaci se nestaráte, to si řeší PLC sama implementovanými průmyslovými protokoly, takže pokud víte, co má technologie dělat, jste v podstatě sakra velmi dobře placený úředník.
Stačí se naučit základní pravidlo, že :
1. PLC načte vstupy
2. Interpretuje program (program běží shora dolů a zleva doprava)
3. Nastaví výstupy
4. Komunikuje
... a tak stále dokola ...
No a pc programátor má zadek otlačený ze židle v kanceláři a chodí taky do hospod na oběd ... v tom neni zas takový rozdíl.

Rozdíl jsem ty služební cesty, ale nedělají je všichni a jsou dobře placené. K platu programátora přibude i dieta.

Co se týkám samotných programů tak záleží co se programuje. Ono jedna věc je dopravník na láhve kde je pár čidel a tím to hasne. A něco jiného je specializovaný provoz kde se do toho zamíchá i nějaká ta matematika (výpočty) a je potřeba vědět co se vlastně děje v celém výrobním procesu.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: ffef 06. 09. 2018, 19:47:13
... Znam pripad OSVC PLC kodera, ktery momentalne splaci nekolik milionu skody, protoze programoval linku, ze ktere nekdo ukradl dorazove cidla a bez nich doslo k havarii. Prohral u soudu, ze SW mel i s eventualitou ukradenych cidel pocitat. ...
Tak je logické, že smrtelně důležité čidlo se zapojí tak, aby při jeho poškození (samotného čidla, konektoru nebo třeba i kabelu k němu) linka zastavila.
Když nemyslíš tak zaplatíš. Druhá věc je, zda by neexistovala pojistka pro osvč, něco jak pojistka na blbost.
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: Mirek 06. 09. 2018, 22:51:13
... Znam pripad OSVC PLC kodera, ktery momentalne splaci nekolik milionu skody, protoze programoval linku, ze ktere nekdo ukradl dorazove cidla a bez nich doslo k havarii. Prohral u soudu, ze SW mel i s eventualitou ukradenych cidel pocitat. ...
Tak je logické, že smrtelně důležité čidlo se zapojí tak, aby při jeho poškození (samotného čidla, konektoru nebo třeba i kabelu k němu) linka zastavila.
Když nemyslíš tak zaplatíš. Druhá věc je, zda by neexistovala pojistka pro osvč, něco jak pojistka na blbost.
Samozřejmě že existuje...
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: fela 07. 09. 2018, 07:05:06
Dobrý deň,

spomínalo sa to tu, ale nepoložil sa na to dostatočný dôraz.
Podľa mojej praxe musí byť takýto programátor i dobrý elektrotechnik a u mnohých strojoch musí byť i zručný v mechanike a príbuzných oblastiach (pneumatika, hydraulika...).
Ak cestuje cez pol sveta, a príde na chybu v hardvéri, tak sa očakáva, že ju aj odstráni. Nejde len o to, nájsť chybný snímač, ale vedieť poriešiť i mechanické záležitosti, najmä u strojov, ktoré nie sú sériovo vyrábané.
Alebo - robíte komunikáciu medzi strojmi rôznych výrobcov - tak treba poznať nejaké štandardy. Napr. ide RS485 cez LAN a potom z LAN na RS232 do PLC. Ak to nejde, kde je chyba? Takže znalosti treba mať, a hodí sa i osciloskop (napr. raz blbol jeden stroj, ktorý posielal správu cez RS232 a časovanie nebolo niekedy korektné, ale to som zistil až s osciloskopom. Detto ak chceme napr. nájsť chybu v rýchlych enkóderoch...)

Toľko moje skúsenosti. Proste klient sa neuspokojí s odpoveďou, že - áno, viem, kde je chyba, príde iný mechanik a odstráni to... ;)
Najmä ak sa napr. kopia kamióny na dvore a linka neexpeduje... :)
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: DragonMaster 07. 09. 2018, 10:08:58
Přechod na PLC je snadný, přesouváš jen krabičky a sestavuješ žebříčky. 8)
Název: Re:Proměna programátora desktop → PLC
Přispěvatel: DragonMaster 07. 09. 2018, 10:17:42
Co to tady čtu, ta práce vypadá docela zajímavě, hlavně to cestování, a taky že člověk dělá na něčem hmatatelném.
Já teď dělám bakaláře na FEL, ale informatiku, takže se s tímhle ve škole docela minu..
Myslíte, že o mě firmy budou mít zájem, i když studuji "čistou" informatiku, ne elektro? A nebo, jak se k tomuhle oboru ještě na škole přiblížit?

Tak na kyru nějaký předmět mají
http://www.fel.cvut.cz/cz/education/bk/predmety/46/66/p4666706.html