Proměna programátora desktop → PLC

[Ferda]

Nevim co si představit pod popisem tvé práce.  Jako v čem programuješ?

C++ nebo C#

Co za zařízení?

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

Jak je připojuješ?

RS232, TCP-IP

Kdo a jak používá ty aplikace?

Vetsinou delnici.

[Reklama]

[K veci]

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




Samozrejme bavime sa o PLC v style (Siemens, Allan-Bradley,Vipa,Omron,Systech....) nie o jednocipoch ala arduino.

[Mirek Prýmek]

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í )

[robotron]

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]

[ehmmm]

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).

[Reklama]

[txt]

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é.

[robotron]

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.)

[Mirek Prýmek]

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ší...

[robotron]

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.

(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.

...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.

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.

[K veci]

 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

[Mirek Prýmek]

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.

[Mirek Prýmek]

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 )

[eiffel]

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.
Tenhle borec napsal dost dokonalé soft PLC (pomáhám mu s testováním)...
Srdce siemensáka zaplesá ...
 

[Mirek Prýmek]

Jukni se třeba sem - 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?

[v]

Jukni se třeba sem - 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/