PLC a mikrokontroler

0

Czym się różni sterownik PLC od mikrokontrolera?

0

A niechaj narodowie wżdy postronni znają, iż Polacy nie gęsi, iż swój język mają.

0

Tak w najprostszych słowach:
Zarówno mikrokontroler (zwykle) jak i PLCk służą do sterowania.
PLC dzięki bogatym modułom wyjścia może służyć do bezpośredniego sterowania urządzeń automatyki z wyjść, mikrokontroler może jedynie służyć do wygenerowania sygnału sterującego jakimś układem zasilającym. Oczywiście PLC też mają ograniczenia fizyczne ;). Takie działanie sterowników PLC jest najpowszechniejsze, o ile mi wiadomo.
Mikrokontrolery programuje się zwykle w C, do PLC są dedykowane proste języki, albo nawet narzędzia typu NI LabView.
Ogólnie rzecz biorąc - zawsze byłoby taniej pokompletować wszystko od podstaw - bo przecież PLC ma mikrokontoler - do danego zastosowania. Niestety takie projektowanie jest drogie, trzeba płacić ludziom, którzy stworzą odpowiedni układ elektronicznego sterowania. W PLC masz "wszystko co potrzebne" w typowych zastosowaniach. To trochę jak z procesorami - na dobrą sprawę można do każdej aplikacji pisać kod w HDL albo od razu produkować ASIC, ale mamy procesory ogólnego przeznaczenia, które nadają się do wszystkiego - praktycznie nigdy nie wykorzystasz wszystkich funkcjonalności, prawie zawsze niektórych nam brakuje, ale hej - mamy uniwersalne narzędzie, które potrafi zaprogramować i używać każdy. No i chyba to przyświecało twórcom PLC.

0

Mikrokontrolery: niski koszt, niskie zużycie mocy, mała wielkość urządzenia (wysoka kompaktowość), większa elastyczność zastosowań.

Tak jak ktoś wyżej wspomniał: mikrokontroler jest także elementem sterownika PLC.

0

@pioflor: znalezione w sieci:
Porównanie ATmega i sterownika

1

Różnica jest taka, że mikrokontroler jako układ scalony może być elementem sterownika PLC w druga stronę to nie działa (na mikrokontrolerze można zrealizować sterownik PLC). Do PLC są języki zgodne z normą IEC 61131-3 (np. drabinka, lista instrukcji itd.). Mikrokontroler ma zastosowanie tam, gdzie liczy się niski koszt sprzętu produkowanego w tysiącach,dziesiątkach tysięcy czy setkach tysięcy egzemplarzy np. sterowanie pralką, mikrofalówką urządzeniami typu. regulator temperatury itp.
PLC to taki elastyczny sterownik (powstał by zastąpić układy stycznikowe, które logikę miały zaszyta na sztywno), który jest przeznaczony głównie do pracy w maszynach, instalacjach w przemyśle i stąd jego odpowiedni design, właściwości, spełniane standardy. Stosunkowa łatwość programowania albo analizy programu pozwoliła na szerokie rozpowszechnienie się tego typu urządzeń przez ostatnie kilkadziesiąt lat. Ogólnie temat rzeka.

0

@0livaw: Bardzo słaby przykład porównania.

1

No powiem ci, kolego, że pytanie bardzo ogólne. A czym się różni mikrokontroler od pralki? Jednak jeśli dobrze rozumiem chciałbyś się dowiedzieć dlaczego stosuje się sterowniki PLC zamiast sklecić sobie coś na uC.

Tak się składa że kiedys pracowałem na produkcji. Też się nad tym zastanawialem jak zobaczyłem piec sterowany z PLC. Najprostsza rzecz na świecie - po załączeniu zasilania PLC miał rozłączać zasilanie po godzinie + prosty interfejs na dwóch przyciskach i kilku kontrolkach. PLC co prawda najtańsze możliwe ale i tak pewnie kosztował kilka stówek a robił coś co można ogarnąć za kilkanaście złotych na uC.

Dopiero bardziej doświadczony kolega wytłumaczył mi jak bardzo jestem w błędzie. Pomijając to, że za takie samoróbki można zamknąć produkcję to jest kwestia serwisu. PLC podłączasz do kompa zrzucasz program i możesz szukać błędu. Możesz też wymienic cały sterownik na nowy.

Wyobraź sobie teraz jakbyś miał naprawić samoróbkę gościa który już nie pracuje. Najczęściej nawet najdroższy sterownik jest tańszy niż godzina zatrzymanej produkcji.

0

Mikrokontroler stanowi element sterownika PLC. Jeden i drugi służy do sterowania, z tym, że mikrokontrolery wykorzystuje się do wygenerowania sygnału sterującego układem zasilającym. Ze swojej strony polecam mikrokontrolery Atmel https://www.micros.com.pl/mikrokontrolery-i-pamieci/mikrokontrolery-atmel/

0

PLC co prawda najtańsze możliwe ale i tak pewnie kosztował kilka stówek a robił coś co można ogarnąć za kilkanaście złotych na uC.
Dopiero bardziej doświadczony kolega wytłumaczył mi jak bardzo jestem w błędzie. Pomijając to, że za takie samoróbki można zamknąć produkcję to jest kwestia serwisu. PLC podłączasz do kompa zrzucasz program i możesz szukać błędu. Możesz też wymienic cały sterownik na nowy.

W sterownikach PLC błąd diagnozuje się najczęściej na ruchu. Podpinasz soft do sieci po czy do sterownika i na żywko patrzysz/zmieniasz. Takie debugowanie, na suchu to robi sie rzadziej.

W kazdym razie to tylko kawałek hisotrii. Ludzie mówią patrz mam atmegę za parę zł. i pacz zrobi to samo(to akurat bzdury bo małego scalaka regulatory PID dojadą w większej ilości). Po pierwsze to bzdura bo taki plc nawet tani będzie miał jakąś komunikacje z zewnętrznym światem ethernet czy nawet jakiś modbus po RS. i działa od kopa.
Ale największa różnica jest taka. Możesz sobie kupić scalaka, wytrawić płytkę, dodac jakieś przekaźniki na nią itd. Ale o ile nie jesteś specem od elektrowniki to nie zrobisz tego czego zrobił producent plc. tzn. starał ise zadbać o odpornośc np. na pole elektromagnetyczne.

0

A tutaj 8-bitowa Atmega w sterowniku, który można programować w C, Basic (BASCOM), Arduino i asembler:
https://www.e-tronix.eu/3,sterownik-plc-programowalny-su-1-5.html

A jeśli chcemy programować w Ladder, ST, SFC itd. to jest do tego sterownik model wyżej:
https://www.e-tronix.eu/46,sterownik-plc-programowalny-su-1-7.html

Najprawdopodobniej jedyny taki sterownik, który oferuje możliwość programowania w tak dużej liczbie języków.

0
0livaw napisał(a):

A tutaj 8-bitowa Atmega w sterowniku, który można programować w C, Basic (BASCOM), Arduino i asembler:
https://www.e-tronix.eu/3,sterownik-plc-programowalny-su-1-5.html

A jeśli chcemy programować w Ladder, ST, SFC itd. to jest do tego sterownik model wyżej:
https://www.e-tronix.eu/46,sterownik-plc-programowalny-su-1-7.html

Najprawdopodobniej jedyny taki sterownik, który oferuje możliwość programowania w tak dużej liczbie języków.

po co? Po pierwsze do poważnej firmy to nie ma szans wejść. Uwierz mi chłopcy z utrzymania ruchu nie programują C ani w Asm. Gdyby ktoś mi przyniósł to do jakiegoś projektu to bym go wyśmiał.

To mi wygląda bardziej na shield doa atmegi niż sterownik plc. Jedyne zastosowanie to widzę w edukajci albo prymitywne sterowanie światłem w jakiejś rozpadającej się oborze.

0

@revcorey: To czego używają ?A raspberry pi mogło by być?

Producenci jakiegoś plc podniecali się tym że ich plc może komunikować się z mysql dzięki specjalnemu rozszerzeniu. Dla mnie to jest śmieszne. W raspbery pi to żaden problem. Arduino wydaje mi się w tym zbyt trudne w modyfikacji(jak z ethernet shield jedna linijka w kodzie źle i problem , a nowe osoby mogą mieć problem przy wdrożeniu, Cena takiego będzie zbliżona do raspbery pi najtańszego pewnie). Obsługuje to się jak normalny komputer. Zwykli programiści mogą napisać program do kontroli pinów bez żadnej wiedzy. Poza 1 biblioteką(do kontroli tych pinów) do jakiegoś frameworka jak qt.

0
kamil kowalski napisał(a):

@revcorey: To czego używają ?A raspberry pi mogło by być?

Producenci jakiegoś plc podniecali się tym że ich plc może komunikować się z mysql dzięki specjalnemu rozszerzeniu. Dla mnie to jest śmieszne. W raspbery pi to żaden problem. Arduino wydaje mi się w tym zbyt trudne w modyfikacji. Obsługuje to się jak normalny komputer.

Przy programowaniu plc zazwyczaj korzysta się z drabinki, fbd. Duże systemy jak PCS czy SPPA3000 nie pozwalają ci w ogóle na nic innego jak ich jeden język. W mniejszch systemach gdzie można wrzucić kod pascalo czy c-podobny stosuje się je raczej do powtarzalnych rzeczy np. z excela wyenerujesz sobie czytanie z przetworników analogowo-cyfrowych i zapis do jakiegoś rejestru niż miałbyś wrzucać tak każdy fbd osobno. Ale jak wspomniałem w dużych systemach klasy DCS nie musi to być dostępne.
Podsumowując w przemyśle strict nie używa się do programowania PLC C czy Pascala(ASM sterowników bywa używany ale to raczej starsze żyłowane projekty). Zazwyczaj jezyki graficzne dwa.

Dwa nie rpi teoretycznie nie mogło by być ale w małych projektach dla fabryk czasami się używa rpi. Robia to małe firmy po kosztach i nie są to zazwyczaj ważne systemy co więcej czesto te rpi niczym nie sterują a dopala się na nich np. przeglądarkę żeby gdzieś tam na zakładzie podglądali scade.

Producenci jakiegoś plc podniecali się tym że ich plc może komunikować się z mysql dzięki specjalnemu rozszerzeniu. Dla mnie to jest śmieszne.

Bo nie znasz specyfiki systemów i branży. PLC miały być zawsze do sterowania itp. One łączyły się z SCADA(z resztą w DCS to jest spięte w jeden duży system) i scada tam zpaisuje do bazy. Taki dodatek do plc to ciekawy feature chociaż jak o tym myślę to średnio przydatny. A ile bloków sterowania zawormai ma qt?

W raspbery pi to żaden problem. Arduino wydaje mi się w tym zbyt trudne w modyfikacji. Obsługuje to się jak normalny komputer.

Tak rpi super. Tylko projekty w przemyśle to a:
a) Algorytm sterowania i regulacji które działają na plc. Łatwiej robić taki system regulacji czy sterowania w PLC niż wygibasy w C++ czy pythonie/
b) Scada które odpowiadają za prezentację i działają na PC albo jakimś dedykowanym urzadzeniu.
c) rpi to ma słabe luty.
d) RPI w porównaniu do tego co daje PLC(wejścia wyjścia, protokoły, wysypy ipt.) jest słabe. I to wykonane porządnie.
e) żaden przez ciebie z wymienionych produktów(rpi czy arduino) nie ma zrobionych badań pod kątem kompatybilności elektromagnetycznej. Na zakładzie potrafi być od groma silników. Od małych po paro mw napędy.
g) RPI i inne wynalazki nie mają żadnej certyfikacji na sterowniki bezpieczeństwa.
f) UTRZYMANIE RUCHU TO ŻADNI EKSPERCI OD DŁUBANINY NA RPI W C++ CZY PYTHONIE, a w zalezności od typu zakładu moga to być kolesie którzy się znają na watowaniu bezpieczników i dodaniu bramki or w sterowniki.
h) mnogośc gotowych bloków których rpi nie ma.

Zwykli programiści mogą napisać program do kontroli pinów bez żadnej wiedzy. Poza 1 biblioteką(do kontroli tych pinów) do jakiegoś frameworka jak qt.

I co dalej? Kto to będzie pisał? Automatycy? Programiści ez ci pojadą na pół roku na zakład to uruchamiać? I jak to będą debugować na zakładzie? Debugowanie plc na ruchu jest banalnie proste, podświetlają ci się bloczki a c++? Wszyscy wiemy jak sie appki debuguje. Rok temu miałem telefon, czy z procka arm da się ściągnąć program(takie było pytanie), bo producent maszyny się ultonił a zrobił sterowanie nie na plc a na procku i płytce opartej o arm ale kopi oprogramowania nie dał. Z sterownika plc ściągniesz program i git masz. I do tego plc sa przez wiele wiele lat w produkcji i masz zapewnione części zmaienne.

A i powiedz mi czy tak łatwo rpi podebpnie sie do własnościowych protokołów jak profibus czy innych firm? Odpowiedź brzmi nie bo nawet takich os bibliotek nie ma do profibus ktoś próbował robić os to go szybciutko złapali prawnicy siemens.
Trzeba zrozumieć że przemysł oprócz małych tanich projektów to nie dłubanina na rpi, którego i tak lepiej zastapić tanim sterownikiem PLC. Tu sie liczy niezawodność, pewność dostaw czesci zamiennych i prostota użycia.
te projekty plc na rpi czy atmedze to ciekawostki, od fajne amatorskie projekty do sterowania światłem w oboże. I takie projekty nawet były.

0

Uważam że program powinien być trzymany w jeszcze jakimś miejscu niż tylko w samym urządzeniu. Z tym programowaniem raspberry to jest tak że jest masa frameworków mogąca się wykorzystywać jego możliwości pinów(więc co kto lubi). Jest jeszcze środowisko codesys i automatycy mogą go używać . Ja osobiście wolę frameworki. Bo są elastyczne. Może być też processing ide(jak ktoś zna arduino to z tym sobie też poradzi i w nim też można kontrolować piny raspberry pi). Jedyny protokół przemysłowy jaki znalazłem który jest obsługiwany przez większość frameworków (nawet arduino z ethernet shieldem sprawdzałem i działało) to modbus tcp. Przecież są inne protokoły udp, http. W firmie co miałem praktyki byłem w dziale it byli tam programiści i znali te protokoły i by sobie pewnie poradzili z tym co ja mówię. A jakby mieli kogoś kto im tylko to pokaże to na pewno. Pewnie są też jakieś konwertery protokołów z udp na profinet i na odwrót. Pewnie debuggowanie to nie problem. Na arduino ponoć ma być w przyszłości debuggowanie. Ale ja za tym nie przepadam. Jak coś chcę zobaczyć co program oblicza itd co siedzi w zmiennych to używam komunikacji uart z komputerem jeszcze się nie zawiodłem. Z rasberry pi jeszcze prościej pewnie.

0

Z tym programowaniem raspberry to jest tak że jest masa frameworków mogąca się wykorzystywać jego możliwości pinów(więc co kto lubi). Jest jeszcze środowisko codesys i automatycy mogą go używać

Ale oczym my mówimy. Duży system automatyki to jest więcej pinów niż jakiekolwiek rpi ma. Po prostu nie znasz przemysłu. To jest dłubanina. Takie dłubaniny robia czasami małe firemki. Nikt w poważnych dużych projektach tego nie stosuje.

. Ja osobiście wolę frameworki. Bo są elastyczne. Może być też processing ide(jak ktoś zna arduino to z tym sobie też poradzi i w nim też można kontrolować piny raspberry pi)
Ale ty nie jesteś automatykiem i nigdy nie robiłeś projektu dla przemysłu stąd mówisz "a ja wolę frameworki". Poległbyś na uruchomieniu. Powiem ci że na uruchomieniu czasami bardzo mocno zmienia się algorytmy, i pałuj się z pythonem wtedy.

Jedyny protokół przemysłowy jaki znalazłem który jest obsługiwany przez większość frameworków (nawet arduino z ethernet shieldem sprawdzałem i działało) to modbus tcp. Przecież są inne protokoły udp, http.
Modbus się szerzy od dawna bo jest uniwersalny ale i on ma ograniczenia. Co więcej sa problemy kiedyś łączyłem systemy siemensa z emerson po modbus, tragedia. opóźnienia po 6-9 sekund. a np. taki schnaider ma modbus+ jakąś swoją wriację. Co zrobisz jak będziesz miał falownik po profibus a nie modbus? Jakie udp i htpp chłopie to przemysł a nie frontend sklepu internetowego. Tu sa protokoły przemysłowe często zamknięte.

A jakby mieli kogoś kto im tylko to pokaże to na pewno. Pewnie są też jakieś konwertery protokołów z udp na profinet i na odwrót. Pewnie debuggowanie to nie problem. Na arduino ponoć ma być w przyszłości debuggowanie. Ale ja za tym nie przepadam. Jak coś chcę zobaczyć co program oblicza itd co siedzi w zmiennych to używam komunikacji uart z komputerem jeszcze się nie zawiodłem. Z rasberry pi jeszcze prościej pewnie.

Ale chłopie ty mówisz o amatorce pokroju arduino do przemysłu? Sama złożoność nieco bardziej skompilkowanego systemu sterowania go położy. Ty nie rozumiesz że nikt logów z rs232 nie bedzie analizował jak może zobaczyć coś takiego.
poza tym powiedz mi jedną rzecz. Czy ty zdajesz sobie sprawę że taki autmatyk siedzi np. na nastawni czy innym miejscu i stamtąd dopiera sie do PLC a nie idzie bezpośrednio do systemu sterowania żeby podpiąc się po rs232? To też nie poważne bo czasami trzeba patrzeć na parę systemów i być w jednym miejscu a nie z rs232 200 metrów dalej przy maszynie(to już w oŋóle abstrakcja w dużych systemach). Albo będę się bawił w milion konwerterów moxa po to żeby podpiąć arduino, gdzie moxa jest droższa od arduino.

Odpowiem ci tak, jestem nie tylko z wykształcenia automatykiem ale i miałem okazję pracować na najwięlszych systemach sterowania opartych o DCS siemensa (i na mniejszych też). Spotkałem tez ludzi z utrzymania ruchu. Wiem jak systemy sterowania potrafią być skomplikowane. Jak ktos mi mówi że on będzie w c++,python,qt i milionie innych frameworków robił projekt automatyki to wiem że jest nie powazny i za dużo o tym nie wie. Począwszy od tego że to marny sprzęt(wykonanie, kompatybilność) po samą ergonomie i dostepność rzeczy. Chyba nie zdajesz sobie sprawy ile jest rozszerzeń dla różnych plc IO itp. Ile potrafi być protokołów i płaowania się.
Powiem ci więcej ja sam obecnie opracowuję moją własną analize wizyjną na produktach nvidi do przemysłu i korzystam z jetsonów, ale one tylko analizują obraz i pchają dane do plc po modbus a przecież jetson ma takie same i/o jak rpi. Nie robie tego bo to nie profesjonalne i nie potrzebne. Ja teraz rozważam trwalsze komputery jendopłytkowe dla przemysłu, droższe ale i wytrzymalsze. U mnie mógłbym dać rpi tylko do forwardowania obrazu z kamerki ale i tak wolę jednopłytowce dla przemysłu.

Oczywiście są czasami projekty na rpi w przemyśle do sterowania czy w arduino. mikro projekty po taniości. Sam rodzicom zrobiłem oparte o atmegę pomiary temp i wilgotności do takiej szopki co mieli. Miałem elementy ale to amatorka dla rodziny. I to rozumiem.

ważam że program powinien być trzymany w jeszcze jakimś miejscu niż tylko w samym urządzeniu.

i co ci to da że masz np. kod w C++ jak nikt z utrzymania ruchu nie ma o tym pojęcia?

0

Ja od początku mówiłem o raspberry pi Arduino podałem jako przykład. Właśnie dlatego rasberry pi bo jest to komputer i można się z nim zdalnie połączyć choćby. Napisałem że nawet na arduino jest prosto debuggować. Na raspberry pi mozna to zdalnie i wszystko jest prostsze.

0

Napisałem że nawet na arduino jest prosto debuggować. Na raspberry pi mozna to zdalnie i wszystko jest prostsze.

Chcesz mi powiedzieć że tekstowy log programu w c++ z rpi po rs232 jest prostszy na uruchomieniu/pracy ssytemu automatyki jak debug z plc co ci wszystko pokazuje w relatime na bloczku w kolorach?

Powiedz mi czy ty kiedys debugowałeś system automatyki na plc na jakiejś fabryce?

0
revcorey napisał(a):

Chcesz mi powiedzieć że tekstowy log programu w c++ z rpi po rs232 jest prostszy na uruchomieniu/pracy ssytemu automatyki jak debug z plc co ci wszystko pokazuje w relatime na bloczku w kolorach?

A jak poziom napięcia zmienia się 100 razy na sekundę to ci to pomoże ? Tam gdzie użyłem uarta do debuggowania(ostatnio) to połowa obliczeń to było obliczanie kątów z funkcji trygonomertrycznych.
Do tego co jest w twoim filmie o debuggowaniu to używam po prostu milimetru czasem ewentualnie oscyloskopu. Bo prościej i widzę ostateczne efekty pracy.

0

A jak poziom napięcia zmienia się 100 razy na sekundę to ci to pomoże ? Tam gdzie użyłem uarta do debuggowania(ostatnio) to połowa obliczeń to było obliczanie kątów z funkcji trygonomertrycznych.
Do tego co jest w twoim filmie o debuggowaniu to używam po prostu milimetru czasem ewentualnie oscyloskopu. Bo prościej i widzę ostateczne efekty pracy.

Wiesz chłopie napisz że nie wiesz jak się debuguje w przemyśle automatykę, w huku, pośpiechu itd. A nie że ty czytasz z loga obliczenia kątów. Super sprawa tyle że to co piszesz ni jak ma się do automatyki przemysłowej. Co do oscyloskopów np. siemens sprzedaje walizki do diagnozowania sieci profibus które są de facto oscyloskopami obudowanymi softem i elektroniką. Tyle nawet tu nie robisz jakiś cudów tylko podpinasz i testujesz a na końcu dostajesz wydruk z diagnozą i przebiegami. Nie bawisz się w samodzielne sprawdzanie oscyloskopem. czas to pieniądz.

Jak byś miał debugować/optymalizować wielopoziomowy system regulacji to sto razy lepiej to robić w języku graficznym. Bo taki rysunek w fbd wygląda prawie jak ten w projekcie wykonawczym a nie jak ściana tekstu.

Stary nie bierz swoich doświadczeń z jakiś projektów co masz na biurku na to co się wyprawia na uruchomieniu(a że nie odpowiedziałeś co do doświadczenia to mniema że go nie masz). Nie bez powodu wybiera się plc a nie rpi czy komputery PC z kartami a'la plc. Tak jest łatwiej, szybciej i pewniej.
Z resztą często wybiera się drogie produkty siemensa zamiast tańszych jak np. panasonica bo tam potrafią być takie babole w ładowaniu programu że szok.
No i później trzeba pamiętać, taki system utrzymuje klient i jego utrzymanie. A tam potrafią pracować ludzie po filologi anie programiści c++. On ma łatwo debugować i wiedzieć jak trywialnie dostawić bramkę or a nie nawigować się po strukturze klas.

edit:
Jeszcze po słowie żeby skomentować klaunów z elektrody.
Systemy plc są różnej klasy małe(nic innego jak przekaźniki programowalne), średnie z większymi możliwościami sprzętowymi, wyspami, lepszym softem i językami i bardzo duże systemy DCS. I te narzekania że w przekaźniku programowalnym masz tylko LD są aż nie poważne.
Taki system PLC ma sterować/regulować procesem ale na dość wysokim procesie abstrakcji. Dostaje dane z czujników i innych urządzeń na podstawie podejmuje decyzje czy też wystawia jakaś wartość do sterowania. Do niego bywa podpięty system SCADA który przechowuje i wizualizuje. Oczywiście to trochę uproszczone bo są opcje jak serwery www, ekstra logika w scada itd. W każdym razie takie systemy zapewniają

  • Prostą prezentację logiki i jej zmian, służby utrzymania ruchu to nie programisci30k, czasami są automatycy a czasami kolesie z łapanki.
  • Łatwe i szybkie debugowanie nawet rozległych systemów np. możesz mieć X wysp wpiętych do systemów i zobaczysz je w jednym miejscu
  • Profesjonalne urządzenia z przemysłowymi standardami, badane pod kątem kompatybilności elektromagnetycznej, konstrukcyjnie wytrzymałe. Ponadto produkowane latami, z wsparciem itp. Coś czego przemysł wymaga
  • Są sterowniki bezpieczeństwa(takie żółte) do kwesti związanych z bezpieczeństwem np. spadek ciśnienia oleju zatrzymaj prasę. Takie sterowniki mają zubożone możliwości programistyczne i podłączeń innych elementów ale mają być bardzo niezawodne.
  • Mnogość obsługiwanych bloków do zaworów, do sieci neuronowych itd.
  • łatwość zmian(czego o sofcie w python czy c++ nie można powiedzieć).

Co się z tego wyłania. taki system jest de facto na wysokim stopniu abstrakcji ale i częściowo na niższym. Bo nie ma problemu żeby urządzenie zapewniające pomiar czy coś innego było oparte o taką atmegę i wysłało modbusem do niego dane, a on nawet bezpośrednio(przez przekaxnik) załączy jakiś napęd bo trzeba.
To jest PLC serce systemu. dam przykład kiedyś do sterowników siemens miałem podpięty taki siemnsowy most co tłumaczył wiele protokołów na siemensowe. Co to było? A nic innego jak minikomputer przemysłowy zamknięty w przemysłowej obudowie w szafie, na którym hulał linux + ekstra port debugujący dla dostawcy gdzie żygał wyjątkami z javy bo appka translacyjna była oparta o jave. Ale ja w sterowniku widziałem tylko nóżki konfiguracyjne i kody błędów + wyjścia. rs232 to był dla serwisu.
To system zaprojektowany dla pewnej klasy problemów gdzie sie sprawdza ale to nie jest do wszystkiego.

1 użytkowników online, w tym zalogowanych: 0, gości: 1