On Sun, 10 Jan 2010 09:10:32 +0100, Sebastian Biały wrote:
>> Nie uważam drabinek za pokemonowe pisanie.
>
>"Panie Krzysiu, a dalo by radę, żeby ilość elementów na lini zrzucic pod
>koniec dniówki do naszej siciowej bazy danych razem z indetyfikatorem
>pracownika który montował?"
>
>"Nie".
>"Aha".
>
>Pi razy drzwi tak wyglądają dyskucje z drabinkowcami.

Jak bedziesz mial bardziej zaawansowane programy to rozmowa moze sie
skonczyc tak samo.
"nie"
"czemu nie ?"
"bo musialbym dodac do programu TCP/IP i pare innych protokolow, a do
hardwaru ethernet i jeszcze pare innych portow do czytnika, i pamiec,
a wiec zaprojektowac sterownik calkowicie od nowa".

Kazde urzadzenie ma swoje ograniczenia.

I paradoksalnie za rok odpowiedz moze byc: "Da sie, tylko musimy
wymienic sterowniki na nowy model. Ja potem szybko przeniose program,
bo drabinkowy to latwo, i tylko troche doprogramowac musze".

>> łatwiej analizować w rybie online.
>
>:D Bez przesady, debugowanie w zwykłym programie jest po wielokroć
>bardziej elastyczne wlacznie z mozliwością napisania sobie własnego
>narzedzia do debugowania wewnątrz żywego kodu.

Przy wielowatkowym programie z koniecznoscia dzialania na zywym
obiekcie tez nie jest tak prosto :-)

J.

do góry

Paweł Sujkowski pisze:
> Witam
>
> Ja też chciałem stanąć w obronie języka drabinkowego. Przy aplikacjach
> automatyzacji maszyn ma moim zdaniem niezaprzeczalne zalety w postaci
> czytelności kodu i łatwości debugowania oraz sporej przenośności. To,
> że aktualnie można odnieść wrażenie że "wiedza potaniała" i za
> programowania w drabince biorą się ludzie o różnym stopniu
> przygotowania nie powinno być argumentem przeciw programowaniu w
> tymże, a przeciw zajmowaniu się takimi zadaniami przez przypadkowych
> ludzi. Ogólne szukanie oszczędności powoduje że jest duża presja na
> działy utrzymania ruchu, aby to one zajmowały się modernizacją maszyn.
> I takie są efekty. NIeporozumieniem jest moim zdaniem także ładowanie
> jakiś płytek z uC i programowanie tego w C/C++/Assemblerze do
> aplikacji maszynowych. Czy bariera powiedzmy 5, 10 czy 15kPLN za
> porządny sterownik jest dla potencjalnego inwestora nie do
> przeskoczenia? Jeśli myślimy na krótką mętę, to potencjalnie przejęcie
> części z różnicy pomiędzy przemysłowym rozwiązaniem a rozwiązaniem na
> uC może się wydać atrakcyjne.

I tak i nie. Jak Ci się uda przekonać klienta, że trzeba wydać na
sterownik 15 tysięcy to nie jest będzie problemem przekonać go do
zapłacenia Ci np. 5kpln za programowanie. Jak dasz się namówić na
robienie tego na Atmelu to ciężko jest przekonać klienta, że taka płytka
w uniwersalnej obudowie jest warta 5kpln. A w tym jest wykonanie płytki,
zaprogramowanie, gwarancja na sprzęt. Narobisz się znacznie więcej i
jeszcze boisz się o takie pierdoły jak CE. Dlatego stanowczo odradzam
klientowi robienie sterowania maszyny na samoróbce.

Ale sterowania powinny być projektowane
> w szerokiej perspepktywie czasowej. Zdarzało mi się ratować maszyny z
> przed ~20 lat, na sterownikach firm o których nigdy nie słyszałem ale
> z wydrukowanym oprogramowaniem w drabince. I po przepisaniu tego i
> wsadzeniu do jakiegoś S7 czy jakiegokolwiek współczesnego sterownika
> ruszało to omal z kopa. Czy program w C na jakiejś płytce to zapewni?
> Ogólnym problemem jest świadomość osób które podejmują decyzje
> finansowe dotyczące takich inwestycji. Dla nich nie liczą się
> standardy, normy i zdrowy rozsądek. Ma być po prostu tanio. Muszę się
> przyznać że sam czasem też stosuję uC do specyficznych funkcji. A to
> przetłumaczenie jakiś protokołów, a to specyficzne uzależnienie
> czasowe itp. Ale ładować logikę maszyny łącznie z funkcjami
> bezpieczeństwa w wyłącznie swoje dzieło to już za dużo. Pozdrawiam.

Też raczej robię tylko pomiar na uC a z niego wyjście do PLC na RS485
lub przekaźnikami. Chociaż bywało, że zostałem"zmuszony" do sterowania
ruchem maszyny z Atmela :) Ale była to zamiana czyjejś umioerającej
prowizorki na moją.

--
Pozdrawiam
MD

do góry

Mario wrote:
>> Doceniam to że ich metody są skuteczne. Ale one sa skuteczne dla
>> trywialnej logiki.

> No cóż jeśli masz do czynienia z ludźmi którzy mogą tylko trywialną
> logikę w drabince to współczuję. Ale to nie wina drabinki. W niej można
> napisać większość kodu odpowiedzialnego np. za ruchy maszyny, a
> specyficzne zadania umieścić w odrębnym bloku pisanym jak tam sobie
> chcesz.

O widzisz. I w tym cały problem z drabinkami. Same w sobie są
bezużyteczne do poważniejszych zastosowań. Co najwyżej można klepać
przekaźnikami.

> Zaleta jest taka, że drabinkowy kod łatwiej później przerobić
> przez innego automatyka.

Jak bym slyszał starego wykładowcę fizyki (współcześnie): "Piszcie w
fortranie, inni będa sie mogli łatwo połapać" ;)

> Zaleta o ile podchodzisz do tego inżynierko a
> nie handlowo :)

Podchodze do tego w jedyny możliwy sposób. Maszyna musi: kłapać
przekaźnikami, ale poza tym znacznie więcej: łaczyc się z bazą danych,
czytac barkody, komunikowac się z paronastoma silnikami krokowymi,
czytać z 4 enkodery kwadraturowe, wykonywac analizę widmową pewnego
sygnalu i na tej podstawie sterować całością, prezentować wyniki na
monitorze dotykowym, generowac raporty etc. Po prostu projekt przerasta
logikę drabinkowa nawet uzbrojona w dodatki o parę rzedow wielkości.

> Miałem na myśli coś co u Schneidera nazywa
> się Structured Text Language a u Siemensa Statement List Programming
> Language.

Masz na mysli to BASICo podobne coś ? Obrzydliwe, smierdzi tutaj ta samą
koncepcja co TigerBasic. Z reszta to znakomicie potwierdza teze: logika
drabinkowa jest tak prymitywna, ze trzeba ja łatac byle czym co
przypomina jakis jezyk imperatywny. Pechowo istnieje ogólne pojecie, że
basic jest najlepszy. Efekty widać: setki dialektów basicowych zgodne
tylko same z soba z coraz to bardziej chora składnią "bo nam się taki
akurat parser zrobił".

> Dla mnie jest wystarczająco komfortowo gdy widzę w którym wierszu
> (networku) maszyna mi utknęła i jak są wysterowane styki drabinki.

Żebym ja miał _tak prymitywne_ problemy jak to gdzie maszyna utkneła ;)

> Nie
> wiem co to u Ciebie zwykły program ale pewnie coś w C/C++.

To ciężko okreslić. U mnie to mieszanka C++,Javy,SQL i JavaScriptu.

> piszę w FBD/STL zakładając, że ktoś obcy będzie to rozwijał to po co mu
> utrudniać.

Ktos obcy nie da rady. Kod sterujący ma grubo ponad 10 tysięcy linijek
skomplikowanego kodu obiektowego. Nie, nie da się prośćiej.

> Natomiast do własnych produktów na mikrokontrolerach piszę w C/C++ i
> zakładam ze to ja będę ten kod rozwijał.

Mikrokontolery (w parunastu sztukach) to jakies 0.5% kodu całości.

Zmierzam do tego, że projektu który zrobiłem (i rozwijam) automatyk z
workiem sterowników PLC nie da rady zrobić nawet w małym fragmencie.
Automatyki jest mniej niz 10%, reszta to informatyka. I prawda jest taka
że tego nikt kijem uzbrojonym w drabinki nie ruszył od dawna. Nie dałby
rady i wiekszośc sobie z tego doskonale zdawała sprawę.

do góry

J.F. wrote:
> Jak bedziesz mial bardziej zaawansowane programy to rozmowa moze sie
> skonczyc tak samo.
> "nie"
> "czemu nie ?"
> "bo musialbym dodac do programu TCP/IP i pare innych protokolow, a do
> hardwaru ethernet i jeszcze pare innych portow do czytnika, i pamiec,
> a wiec zaprojektowac sterownik calkowicie od nowa".

I dlatego dopytywalem w tym watku o sterownik z dużym zapasem ficzerów.
Wtedy taka argumentacja nie ma sensu.

> Przy wielowatkowym programie z koniecznoscia dzialania na zywym
> obiekcie tez nie jest tak prosto :-)

Kwestia tego czy się jest programista czy programatorem.

do góry

Paweł Sujkowski wrote:
> Ja też chciałem stanąć w obronie języka drabinkowego. Przy aplikacjach
> automatyzacji maszyn ma moim zdaniem niezaprzeczalne zalety w postaci
> czytelności kodu i łatwości debugowania oraz sporej przenośności.

Innymi słowy w swojej logice drabinkowej spokojnie wykonujesz zapytania
SQLowe wciskając do bazy danych wartośc 3-ciej harmonicznej kształtu pradu?

Wiesz, na wyraźnie zaznaczylem, że tego projektu nie dotknął żaden
automatyk jak zobaczył co należy zrobić i jak. Niektórzy bardziej
światli proponowali LabView, ale szacowana wartość sprzetu
pomiarowo-sterującego + licencja + wynagrodzenie przerosła by wartość
urządzenia kilkukrotnie, a i tak trzeba by częśc RT pisać na
mikrokontolerach.

> I takie są efekty. NIeporozumieniem jest moim zdaniem także ładowanie
> jakiś płytek z uC i programowanie tego w C/C++/Assemblerze do
> aplikacji maszynowych.

Sa sytuacje które wymagają samorobek choćby z tego powodu że nie ma
gotowych rozwiązań, albo są w cenie przekraczającej zdrowy rozsądek.

> przed ~20 lat, na sterownikach firm o których nigdy nie słyszałem ale
> z wydrukowanym oprogramowaniem w drabince. I po przepisaniu tego i
> wsadzeniu do jakiegoś S7 czy jakiegokolwiek współczesnego sterownika
> ruszało to omal z kopa.

Jesli zdołałeś wydrukować kod drabinkowy i go ponownie przepisać bez
błedow to zaryzykuje stwierdzenie, że bylo to cos przerażająco
trywialnego. Nie o taki projekcie tu rozmawiam. Gdybym potrzebował
kłapać paroma przekaźnikami i czytać pare sensorów to bym sie nie bawił
w jakieś pierdoły z wlasnymi uC.

> Czy program w C na jakiejś płytce to zapewni?

Niektórzy złośliwcy twierdzą, że jeśli programista nie był idiotą to tak.

> przyznać że sam czasem też stosuję uC do specyficznych funkcji. A to
> przetłumaczenie jakiś protokołów, a to specyficzne uzależnienie
> czasowe itp.

No widzisz. Nie wszystk da się zrobic drabinkami.

do góry

Witam

> Innymi słowy w swojej logice drabinkowej spokojnie wykonujesz zapytania
> SQLowe wciskając do bazy danych wartośc 3-ciej harmonicznej kształtu pradu?
>

Nie traktuj obrony drabinki jako osobisty atak na siebie i swoje
dokonania. Są fragmenty softu które lepiej będzie pasowało
zaimplementować w drabince a inne w czymś innym. Ale nie znaczy to, że
zaraz należy brać się za budowanie wszystkiego od podstaw. Od kilku lat
stosuję między innymi sterowniki B&R. Można je programować we wszystkich
językach IEC, oraz w ichnym basicu a także C/C++. Jak się bliżej
przyjrzeć narzędziu, to pod spodem leży gcc. Ze strony sprzętowej, to
aktualnie i386 od 100MHz do GHz. Przy możliwościach i niezawodności
typowego PLC możesz mieć do dyspozycji też PC-ta. Do tego wszystkie
sieci przemysłowe, certyfikacje standardy itp.

> Sa sytuacje które wymagają samorobek choćby z tego powodu że nie ma
> gotowych rozwiązań, albo są w cenie przekraczającej zdrowy rozsądek.

Moi zdaniem kwestia ceny. Pułap zdrowego rozsądku jest mocno zaniżany
przez klientów, którzy chcieli by cuda za pół darmo.To moim zdaniem jest
problem.

> Jesli zdołałeś wydrukować kod drabinkowy i go ponownie przepisać bez
> błedow to zaryzykuje stwierdzenie, że bylo to cos przerażająco
> trywialnego. Nie o taki projekcie tu rozmawiam. Gdybym potrzebował
> kłapać paroma przekaźnikami i czytać pare sensorów to bym sie nie bawił
> w jakieś pierdoły z wlasnymi uC.
>

Zapewniam cię że nie było to zadanie dla logo czy s7-200. Może maszyna
nie łaczyłą się z SQL-ową bazą ale dobra setka wejść i podobna ilość
wyjść tam była. Pozdrawiam.

Paweł

do góry

Paweł Sujkowski wrote:
> Nie traktuj obrony drabinki jako osobisty atak na siebie i swoje
> dokonania.

Odwrotnie. To drabinkowcy traktują implementacje czegokolwiek większego
nie-w-drabinkach jako atak na swoje środowisko. Gdyby tylko mógł napisać
to co pisze w drabinkach, to bym to zrobił. Nie moge. Mając do wyboru
hermetyczną implementację hardware/software (jak np. wspominany Tiger)
albo otwarte środowisko programistyczne wybór wydaje sie dość jasny.

> przyjrzeć narzędziu, to pod spodem leży gcc. Ze strony sprzętowej, to
> aktualnie i386 od 100MHz do GHz. Przy możliwościach i niezawodności
> typowego PLC możesz mieć do dyspozycji też PC-ta. Do tego wszystkie
> sieci przemysłowe, certyfikacje standardy itp.

Część RT znając życie trzeba skrobac w uC. Ale pozerkam.

> Zapewniam cię że nie było to zadanie dla logo czy s7-200. Może maszyna
> nie łaczyłą się z SQL-ową bazą ale dobra setka wejść i podobna ilość
> wyjść tam była. Pozdrawiam.

Jaki był poziom logiki sterowania tych setek wyjśc? To algorytm zapisany
za pomocą seri if'ów drabinkowych? Czy liczyleś moze transformatę
fouriera? Ja nie podaje ile mam przekaźników do sterowania cz sensorów
bo to nieistotne. Bardziej istotne co robił. Jesli tylko podejmowal
proste decyzje to akurat mógł miec i milion wyjść.

Stoje na stanowisku ze logika drabinkowa jest zdecydowanie zbyt
prymitywna do mojego zastosowania. W dodatku prawie wszyscy to
potwierdzają (włącznie z Tobą) że istnieją do trudniejszych zagadnień
lepsze narzedzia. No więc wlasnie o tym mówie. Do mojego zastosowania
logika drabinkowa się nie nadaje (a zostało to odebrane "ze nie nadaje
sie do wszystkiego" - nigdy tak nie twierdziłem). Swoją droga nie
nadawały się też sterowniki programowalne w językach wyższego poziomu
(ze względu na to że czesto hasło "RT" to zwykła ściema). Znalezienie
dekodera sygnału kwadraturowego z funkcja łapania wartości i sterującego
nadążnym silnikiem krokowym rozbijalo się o problem typu "nie wyrobi się
na tej predkosci" i zostalo tylko rekodzieło. Fakt, nieprofesjonalne,
ale za to dzialające za $50 lepiej niż niedziałający gotowiec za $500.

do góry

Sebastian Biały pisze:
> Mario wrote:
>>> Doceniam to że ich metody są skuteczne. Ale one sa skuteczne dla
>>> trywialnej logiki.
>
>> No cóż jeśli masz do czynienia z ludźmi którzy mogą tylko trywialną
>> logikę w drabince to współczuję. Ale to nie wina drabinki. W niej
>> można napisać większość kodu odpowiedzialnego np. za ruchy maszyny, a
>> specyficzne zadania umieścić w odrębnym bloku pisanym jak tam sobie
>> chcesz.
>
> O widzisz. I w tym cały problem z drabinkami. Same w sobie są
> bezużyteczne do poważniejszych zastosowań. Co najwyżej można klepać
> przekaźnikami.
>
>> Zaleta jest taka, że drabinkowy kod łatwiej później przerobić przez
>> innego automatyka.
>
> Jak bym slyszał starego wykładowcę fizyki (współcześnie): "Piszcie w
> fortranie, inni będa sie mogli łatwo połapać" ;)
>
>> Zaleta o ile podchodzisz do tego inżynierko a nie handlowo :)
>
> Podchodze do tego w jedyny możliwy sposób. Maszyna musi: kłapać
> przekaźnikami, ale poza tym znacznie więcej: łaczyc się z bazą danych,

Sterownik w maszynie nie jest najlepszym urządzeniem do tego.

> czytac barkody,

Nie ma problemu nawet w drabince.

komunikowac się z paronastoma silnikami krokowymi,

Także

> czytać z 4 enkodery kwadraturowe,

czytają liczniki. W drabince obsługujesz tylko wartosći liczników.
Ladder to nie tylko styki i cewki ale też bloczki matematyczne.

> wykonywac analizę widmową pewnego
> sygnalu

No to już gorzej - zwłaszcza że pasmo częstotliwości chwytane przez
wejścia analogowe w PLC jest żałosne.

i na tej podstawie sterować całością, prezentować wyniki na
> monitorze dotykowym,

To robi miniSCADA w panelu który łyka dane z PLC. Zakładam że pisząc o
monitorze dotykowym miałeś na myśli panel graficzny.

generowac raporty etc.

Masz to w panelu ale jak chcesz można to zrobić w ladderze na PLC i
wysłać portem szeregowym.

>Po prostu projekt przerasta
> logikę drabinkowa nawet uzbrojona w dodatki o parę rzedow wielkości.
>
>> Miałem na myśli coś co u Schneidera nazywa się Structured Text
>> Language a u Siemensa Statement List Programming Language.
>
> Masz na mysli to BASICo podobne coś ? Obrzydliwe, smierdzi tutaj ta samą
> koncepcja co TigerBasic. Z reszta to znakomicie potwierdza teze: logika
> drabinkowa jest tak prymitywna, ze trzeba ja łatac byle czym co
> przypomina jakis jezyk imperatywny. Pechowo istnieje ogólne pojecie, że
> basic jest najlepszy. Efekty widać: setki dialektów basicowych zgodne
> tylko same z soba z coraz to bardziej chora składnią "bo nam się taki
> akurat parser zrobił".
>
>> Dla mnie jest wystarczająco komfortowo gdy widzę w którym wierszu
>> (networku) maszyna mi utknęła i jak są wysterowane styki drabinki.
>
> Żebym ja miał _tak prymitywne_ problemy jak to gdzie maszyna utkneła ;)

No wiesz do sterowania większymi procesami to masz raczej DCSy a nie PLC
opragromawane w C++.

>> Nie wiem co to u Ciebie zwykły program ale pewnie coś w C/C++.
>
> To ciężko okreslić. U mnie to mieszanka C++,Javy,SQL i JavaScriptu.

Realizowane w sterowniku PLC?
>
>> piszę w FBD/STL zakładając, że ktoś obcy będzie to rozwijał to po co
>> mu utrudniać.
>
> Ktos obcy nie da rady. Kod sterujący ma grubo ponad 10 tysięcy linijek
> skomplikowanego kodu obiektowego. Nie, nie da się prośćiej.
>
>> Natomiast do własnych produktów na mikrokontrolerach piszę w C/C++ i
>> zakładam ze to ja będę ten kod rozwijał.
>
> Mikrokontolery (w parunastu sztukach) to jakies 0.5% kodu całości.
>
> Zmierzam do tego, że projektu który zrobiłem (i rozwijam) automatyk z
> workiem sterowników PLC nie da rady zrobić nawet w małym fragmencie.
> Automatyki jest mniej niz 10%, reszta to informatyka. I prawda jest taka
> że tego nikt kijem uzbrojonym w drabinki nie ruszył od dawna. Nie dałby
> rady i wiekszośc sobie z tego doskonale zdawała sprawę.


Pisałeś że:
c) półzawodowo robie bardzo nietypowe rzeczy z automatyki przemyslowej
(głównie to czego inni pokemoni od logiki drabinkowej kijem nie dotkną,
bo "panie, nie da rady")

Jeśli projekt, który realizujesz jest w głównej mierze informatyczny
realizowany na komputerach technologiami informatycznymi to wydaje się
oczywiste, że automatyk z workiem sterowników sobie z nim nie poradzi.
Nie poradzi sobie też ze zrobieniem systemu informatycznego do banku i
żaden w tym powód do chwały dla fachowca który będzie to realizował
technologiami odpowiednimi do zadania.

--
Pozdrawiam
MD

do góry

Mario wrote:
>> przekaźnikami, ale poza tym znacznie więcej: łaczyc się z bazą danych,
> Sterownik w maszynie nie jest najlepszym urządzeniem do tego.

U mnie jest to komputer, prawie normalny pecet.

>> czytać z 4 enkodery kwadraturowe,
> czytają liczniki. W drabince obsługujesz tylko wartosći liczników.

Że by to było takie proste... liczniki nie dość, ze musza być szybkie,
to musza oferować dodatkowo dwa niezależne zatrzaski 24 bitowe z
prezycją zatrzaśnięcia nie gorsza niż 1 impuls i w dodatku robiąc
mechanizm nadążny do silnika krokowego. Prędkośc impulsow kwadraturowych
około 10kHz. Zajmuje się tym u mnie wydzielony uC, bo zadanie czysto RT.

> Ladder to nie tylko styki i cewki ale też bloczki matematyczne.

O tak, wiem. O ileż wygodniejsze niż napisanie nieczytelnego: pos = (
(encoder_position + initial_offset) * number_of_gears ) / diameter;

> To robi miniSCADA w panelu który łyka dane z PLC. Zakładam że pisząc o
> monitorze dotykowym miałeś na myśli panel graficzny.

Mam na myśli zwyczajny komputer z monitorem dotykowym.

> generowac raporty etc.
> Masz to w panelu ale jak chcesz można to zrobić w ladderze na PLC i
> wysłać portem szeregowym.

Że co ? Raporty to ja mam na mysli pliki pdf, albo wrzucanie tego online
do www w celu analizy statsytycznej procesu. To jest dla mnie "raport",
nie wyjaśnilem tego precyzyjnie.

> No wiesz do sterowania większymi procesami to masz raczej DCSy a nie PLC
> opragromawane w C++.

Ale to nie jest "większy proces" tylko wymagający (w sensie RT i
algorytmicznym). DCS ? Po co.

>> To ciężko okreslić. U mnie to mieszanka C++,Javy,SQL i JavaScriptu.
> Realizowane w sterowniku PLC?

Nie. Sterownikiem jest PC. Część RT delegowana jest do kontrolerów. Dane
sa zbierane i analizowane przez normalny komputer z rozsadną moca
obliczeniową i możliwością debugowania. Komputer wykonuje również
elementy sterowania nie wymagające RT.

> c) półzawodowo robie bardzo nietypowe rzeczy z automatyki przemyslowej
> (głównie to czego inni pokemoni od logiki drabinkowej kijem nie dotkną,
> bo "panie, nie da rady")

> Jeśli projekt, który realizujesz jest w głównej mierze informatyczny
> realizowany na komputerach technologiami informatycznymi to wydaje się
> oczywiste, że automatyk z workiem sterowników sobie z nim nie poradzi.

No dokładnie. Czy aby o tym wlasnie nie mówię?

> Nie poradzi sobie też ze zrobieniem systemu informatycznego do banku i
> żaden w tym powód do chwały dla fachowca który będzie to realizował
> technologiami odpowiednimi do zadania.

Czekaj. Chcesz teraz powiedziec że PLC i drabinki sa nieodpowiednie dla
tego zadania? To po co to ciagłe przekonywanie mnie ze powinienem
zamienić jasny i wygodny jezyk programowania na masę poziomych kresek
wsadzonych w urzadznie xN razy drozsze i nie spelniające żadnych
docelowych zadań tego systemu?

I jakiej chwały?

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:hia7no$6lc$1@achot.icm.edu.pl...
> Witam.
>
[mlask]

http://emea.kontron.com/products/computeronmodules/x
board/
http://emea.kontron.com/products/computeronmodules/e
2brain/

@

do góry