Proměna programátora desktop → PLC

v

Re:Promena programatora Desktop -> PLC
« Odpověď #45 kdy: 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 :)


Jarous

Re:Proměna programátora desktop → PLC
« Odpověď #46 kdy: 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í.

Re:Proměna programátora desktop → PLC
« Odpověď #47 kdy: 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! :)

Re:Proměna programátora desktop → PLC
« Odpověď #48 kdy: 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.

v

Re:Proměna programátora desktop → PLC
« Odpověď #49 kdy: 25. 03. 2016, 21:52:56 »


Re:Proměna programátora desktop → PLC
« Odpověď #50 kdy: 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.

PLC vývojář

Re:Promena programatora Desktop -> PLC
« Odpověď #51 kdy: 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

anon36

Re:Proměna programátora desktop → PLC
« Odpověď #52 kdy: 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?

Youda

Re:Proměna programátora desktop → PLC
« Odpověď #53 kdy: 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.

ffef

Re:Promena programatora Desktop -> PLC
« Odpověď #54 kdy: 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.

ffef

Re:Proměna programátora desktop → PLC
« Odpověď #55 kdy: 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.

Mirek

Re:Proměna programátora desktop → PLC
« Odpověď #56 kdy: 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...

fela

Re:Proměna programátora desktop → PLC
« Odpověď #57 kdy: 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... :)

DragonMaster

Re:Proměna programátora desktop → PLC
« Odpověď #58 kdy: 07. 09. 2018, 10:08:58 »
Přechod na PLC je snadný, přesouváš jen krabičky a sestavuješ žebříčky. 8)

DragonMaster

Re:Proměna programátora desktop → PLC
« Odpověď #59 kdy: 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