Dlaczego w fabrykach nie stosuje się Arduino tylko PLC?

Kol. Zgoodie, nie rozumiem jaki masz cel namawiając do partactwa. Nie musisz "pokazywać alternatywy", wszyscy ją znamy.

Amatorsko do zabawy można wszystko, byle tanio. Ale w pracy inżynier stosuje aparaty w warunkach, jakie przewidział ich producent.

Arduino nie jest zaprojektowane do pracy 24x7x365 w warunkach przemysłowych. To kończy dyskusję; świadomy klient ma wymagania i po prostu nie akceptuje takich rzeczy w istotnych biznesowo procesach.

Na marginesie: istnieje klon arduino, którego producent deklaruje stosowalność w przemyśle. Nazywa się to Controllino i swoje kosztuje. Używałem; widzę dla tego pewną niszę na rynku, ale zwykłych PLC to nie wymiecie. Zrób na arduino zmianę programu bez zatrzymania sterowanej maszyny, powodzenia.

Opowieści o zastępowaniu języków PLC przez C/C++ to zupełna bajka. Napisz sekwencję rzędu 30 kroków z fragmentami współbieżnymi (tj. kilka kroków aktywnych jednocześnie) w diagramie sekwencji (SFC) i w C, poczujesz różnicę.

jestam - namawiam do partactwa...hmmm gdzie ? mówiąc ze widziałem rozwiazania na arduino (redpack) albo dedykowanych plytach w Ilapak i Bosch. To jest namawianie? Pewnie mieli swoje powody.

"Arduino nie jest zaprojektowane do pracy 24x7x365 w warunkach przemysłowych. To kończy dyskusję; świadomy klient ma wymagania i po prostu nie akceptuje takich rzeczy w istotnych biznesowo procesach"
dlaczego konczy dyskusje? Czyzby "jestam" był jedynym słusznym głosem inzynierii?
Przeciez w Redpack o ktorym pisze we wczesniejszych postach - tez pracuja inzynierowie (partacze??? -prosze nie osadzaj) z tymi samymi wymaganiami przemyslu jakie znasz pewnie i Ty.
"24x7x365" przeciez firma z Anglii wypuszcza pewnie z dziesiatki maszyn rocznie na caly swiat. Myslisz ze serwuja sobie ciągły serwis? Uzytkuje jedna z tych maszyn i nie zauwazylem problemow.

Co do "c" w przemysle to chyba tez nie najlepiej odebrales.
" Napisz sekwencję rzędu 30 kroków z fragmentami współbieżnymi (tj. kilka kroków aktywnych jednocześnie) w diagramie sekwencji (SFC) i w C, poczujesz różnicę."
po co takie wypuchy? mam napisac napisz filtr na sygnal z wejscia analogowego w drabince - to pogadamy ...pliz nie znizaj sie z takim poziomem jaki posiadasz na elektrodzie do przepychanek rodem z piaskownicy. Nie pisz prosze sprobuj tego czy tamtego. TO jest słabe. Kazdy jezyk ma swoje zalety i wady. Ja zauwazylem tylko (to moje zdanie) i nie nazywam Twojego bajką, ze ST i C wypieraja drabinki z uwagi na trudniejsze aplikacje ot co. A powodem tego moze byc ukierunkownie/pochodzenie Tworców srodowisk PLC (programisci)

napisalem z Anglii bo nie chcialem powtorzyc dwa razy nazwy firmy bo w poprzednim poscie - byloby to niestylistyczne:) a nie dlatego ze oni sa Anglicy. nie mam kompleksów Polaka wrecz przeciwnie.Poza tym autor postu pyta dlaczego sie nie stosuje Arduino a nie co Ja albo Ty polecamy do stosowania przy budowie sprzetu/maszyn/linii...

To nie żadna jakość techniczna wyklucza Arduino z przemysłu tylko wiedza o jego użytkowaniu, a dokładniej programowaniu. Ta wiedza rośnie i spodziewam się większego udziału różnych malinek arduino i innych bananów w przemyśle.
Jest oczywiste ze arduino jest za słabe pociągnąć linię produkcyjną, ale jako różne konwertery sygnałów, zbieracze sygnałów, rozszerzenia funkcjonalności itp. będą używane coraz częściej, wykonując pomocniczą pracę dla jednostki głównej.
Kluczowe znaczenie ma czas programisty - jak pokolenie arduino będzie w nim robić te same rzeczy co w PLC i to taniej i szybciej, to przemysł (a dokładniej księgowi) to ogarną - pojawią się PLC, logicznie zgodne z arduino, aby wykorzystać tę wiedzę

Zgoodie wrote:

Przeciez w Redpack o ktorym pisze we wczesniejszych postach - tez pracuja inzynierowie (partacze??? -prosze nie osadzaj) z tymi samymi wymaganiami przemyslu jakie znasz pewnie i Ty.

Z zawodowej uprzejmości zakładam, że stosują Arduino w warunkach, jakie przewidział producent tej płytki. Jeśli nie, jest to partactwo i druciarstwo; być może wymuszane przez księgowych i akceptowane przez tych spośród klientów, którym "nie robi różnicy, przecież działa". Reszta potencjalnych klientów znajduje sobie innych dostawców.

Chris_W wrote:

Kluczowe znaczenie ma czas programisty - jak pokolenie arduino będzie w nim robić te same rzeczy co w PLC i to taniej i szybciej, to przemysł (a dokładniej księgowi) to ogarną - pojawią się PLC, logicznie zgodne z arduino, aby wykorzystać tę wiedzę

PLC czyli sprzęt i jego oprogramowanie do kupienia z półki (w tym specjalizowane języki programowania i funkcje, takie jak zmiana programu "w locie"), to narzędzie przeznaczone do budowy systemów sterowania w przemyśle. Dobrze jest używać narzędzi przeznaczonych do danej pracy.

Istnieje klon Arduino w wykonaniu przemysłowym, pisałem wyżej, furory to nie robi, bo brakuje mu tychże specjalizowanych funkcji oprogramowania. Czy to się zmieni w przyszłości, zobaczymy.

Istnieje też runtime CodeSys na Raspberry, do nauki i zabawy. Jakoś nie używa się tego masowo do sterowania, choć programowo ma większość funkcjonalności innych sterowników PLC z runtime CodeSys. Podobnie jak nie używa się biurowego PC z runtime CodeSys, tylko specjalne wykonania dla przeznaczone przemysłu.

jestam:

Quote:

PLC czyli sprzęt i jego oprogramowanie do kupienia z półki (w tym specjalizowane języki programowania i funkcje, takie jak zmiana programu "w locie"), to narzędzie przeznaczone do budowy systemów sterowania w przemyśle"

przy seryjnych maszynach zmiana programu w locie nie jest tak wazna bo producent dopracowuje je na etapie developmetu pozniej to tylko ctr+c -> ctrl+v wiec debugowanie bez zatrzymania nie ma az takiego naczenia.

Quote:

Jeśli nie, jest to partactwo i druciarstwo; być może wymuszane przez księgowych i akceptowane przez tych spośród klientów, którym "nie robi różnicy, przecież działa".

jesli działa i MTBF jest taki sam jak dla maszyny na PLC to po co zaglądać "pod kiecke"- a wychodzi taniej

jestam

Quote:

Jeśli nie, jest to partactwo i druciarstwo; być może wymuszane przez księgowych

btw. a Ty naprawde myslisz ze ksiegowi sa oszczedni z natury? Przeciez to Ci sami klienci o ktorych wspominasz powoduja ze ksiegowi sa oszczedni i chca byc konkurencyjni.

Jedno najważniejsze pytanie , jaka jest trwałość "rzeczy" nie przemysłowej .W sumie kto zagwarantuję ,że maszyna w swym cyklu życiowym ok.6-10 lat wyprodukuję ileś milionów "czegoś" (potem jeszcze załóżmy after market w pracy przerywanej) . Żaden inwestor nie zainwestuję coś domowego , choćby było ze złota. No chyba że to foliowarka ....

Inwestor ma to gdzieś czy w środku siedzi PLC, RPi czy stado Krasnoludków. Amortyzacja maszyny to nie jest pojęcie abstrakcyjne lecz ze słownika księgowego. Nie wszędzie na świecie zajeżdża się przechodzone maszyny po odkupieniu w cenie złomu. Normalnie jest tak, że po pewnym czasie, cyklicznie maszyny są modernizowane przez ich dostawcę lub firmę, która się tym zajmuje. Inwestor ocenia modernizację nie przez pryzmat markowości PLC a jej kosztu i okresu gwarancji oraz wsparcia.
Ktoś z was Koledzy przeprowadził test wytrzymałości na drgania oraz w komorze klimatycznej RasPi Model
B ? Spróbujcie.

Każdy obiekt rozpatrywany jest pod względem niezawodności.
Wyróżnia się tu:
- Gotowość czyli zdolność do wykonywania określonych zadań w każdej chwili i w danych warunkach.
- Nieuszkadzalność czyli rozpatrując obiekt pod względem współczynnika MTBF to dla komponentów np Siemensa producent określa model uszkodzeń na typ wannowy.
Oznacza to, że tym modelu uszkodzeń wyróżnia się etap I czyli najgorsze nowe z problemami projektowymi oraz uszkodzeniami losowymi, następnie mamy etap II długiej eksploatacji kilkanaście lat bezawaryjnej pracy, aż następuje etap trzeci czyli stopniowa degradacja elektroniki do trwałego uszkodzenia.
- Obsługiwalność czyli podatność obiektu do przeprowadzania na nim działań związanych z obsługą techniczną. I tu mowa o podatności na analizę projektu, diagnostykę, backupy, możliwość podłączenia do historiana itp.
- Zapewnienie środków obsługi – zdolność organizacji do zapewnienia niezbędnych zasobów do obsługi danego obiektu.

Prosta zgrzewarkę proszę bardzo można nawet na SIEMENS LOGO. Ale maszynę od której zależy wydajność w długim okresie produkcyjnym raczej nie na Arduino.
Ponadto producent maszyn też dąży do zapewnienia niezawodności ponieważ to zwiększa prestiż ich wyrobów.
Producent będzie dążył też do cięcia kosztów, a okres gwarancyjny to przeciętnie 18 mc, gdzie każda dodatkowa wizyta to koszt.

Natomiast firma która zbudowała markę na rynku i walczy o pozycje lidera nie zastosuje u siebie maszyny firmy Krzak. W takiej firmie są wprowadzone wskaźniki KPI którymi rozlicza się każda minute niedostępności parku maszynowego. Dla takiej firmy są sprowadzane maszyny z najwyższej półki, gdzie niezawodność działania nie jest określana modelem uszkodzenia Stałe losowe awarie.
Ponadto już widzę programistę w Arduino, który będzie dla każdej poprawki wciąż kompilował program i wgrywał go do procesora. Ile to trwa pewnie sporo, a jak tu zrobić diagnostykę? Oczywiście robi się ją offline w głowie programisty.

RitterX wrote:

Normalnie jest tak, że po pewnym czasie, cyklicznie maszyny są modernizowane przez ich dostawcę lub firmę, która się tym zajmuje. Inwestor ocenia modernizację nie przez pryzmat markowości PLC a jej kosztu i okresu gwarancji oraz wsparcia.
Ktoś z was Koledzy przeprowadził test wytrzymałości na drgania oraz w komorze klimatycznej RasPi Model
B ? Spróbujcie.

Markowość PLC jest bez praktycznego znaczenia, byle to było PLC. Arduino czy Raspberry to nie PLC. O tym jest wątek.

Testów mechanicznych Raspberry nie robiłem, ale dawno temu widziałem testy kompatybilności EMC. Sama płytka wychodziła niezbyt zachęcająco, a po przyłączeniu I/O był dramat.

RitterX wrote:

Inwestor ma to gdzieś czy w środku siedzi PLC, RPi czy stado Krasnoludków

Oj ma, no chyba że papiery gniecie...

@jestam, w pierwszym wpisie dotyczącym tego tematu zwróciłem uwagę na kilka wyższości PLC w tym pewność co do EMC, sterownika jako całości. W ten sposób należałoby dla uczciwego podejścia potraktować i RasPi. Czyli RasPi z płyką interfejsu, który ma zabezpieczenia I/O jak właściwą obudowę. Wtedy to tak kiepsko już nie wypada. Wystarczająco dużo PLC obejrzałem od środka by wiedzieć jakiego poziomu posiadają zabezpieczenia. Także nie są one aż takie wszechmocne.
To czym wygrywa PLC, już pisałem, to standaryzacja rozwiązania. Gdy padnie moduł odczytuje się długi numer z PLC wbija do wyszukiwarki a potem do zamówienia i już. Pod warunkiem, że mamy oprogramowanie - wsad, którym nakarmimy zamówiony sterownik? Liderzy branży sterowników PLC dbają o to by ich nie zabrakło, również w przyszłości. To punkt dla PLC gdyż trudno powiedzieć jak będzie wyglądała przyszłość RasPi? Sporo tego typu rozwiązań po czasie znikało z rynku. Najzwyczajniej nie potrafię tego określić i to chyba jest największy problem RasPi w dającej przewidzieć się perspektywie w odniesieniu do, w sumie absolutnej pewności, kontynuacji PLC. Przynajmniej czołowych producentów. Nawet potencjalne przejęcia dadzą wsparcie przynajmniej w okresie przejściowym i prostą ścieżkę migracji.

W RasPi zwykle jest jądro Linux-a jako system i tutaj pojawia się pewien problem bo to z całą pewnością nie jest "twardy" system czasu rzeczywistego. Nawet z łatką Rt. Wygrana, przynajmniej pewnej części sterowników PLC.
Kolejny aspekt to wydajność obliczeniowa. Pod tym względem PasPi jakoś siedzenia nie urywa . W przypadku problematycznego sterowania np. obiektem nieliniowym PLC może okazać się ,że to za mało i wiem co napisałem. Zresztą RasPi podobnie dlatego tutaj dajmy 1:1 w straconych bramkach . Tu nikt się nie plącze i podłącza jakiegoś mocarza w przemysłowym, militarnym wykonaniu i zwykle jest po problemie.
No to w czym wygrywa RasPi? A no w wielkości samego rozwiązania. W dedykowanym rozwiązaniu przemysłowym np. przenośnym urządzeniu pomiarowym zapakowanie PLC to średnio udany pomysł. No bo tak, PLC moduł CPU + Moduł Interfejsu pomiarowego + Moduł transmisji danych i mamy dobre 30cm szyny TS + Moduł wyświetlacza graficznego TFT i klawiatury . No i jak to zasilić ?!
Nie kojarzmy automatyki przemysłowej ze stacjonarnymi rozwiązaniami w wielkich szafach. W węźle kinematycznym "stawie" robota trzeba to i owo raz zmierzyć a dwa wysterować. Nie koniecznie ciągnięcie długich i szerokich magistrali do szafy sterującej musi mieć praktyczny sens.

Podsumowując, idzie nowa generacja, która nie została wychowana na schematach drabinkowych i nad czym ubolewam może nawet nie konieczne umieć je z sensem czytać i analizować choćby pod kątem przenośności na coś innego. PLC podobnie jak systemy wbudowane np. RasPi mają swoje ograniczenia. Czasami wręcz głupio byłoby dany typ rozwiązania pakować na siłę. No chyba, że ktoś się tylko na jednym zna. To wtedy sprawa jest dosyć oczywista.
Trudno mi określić kto szybciej i taniej wyrzeźbi program sterujący. Na PLC czy na RasPi? Zapewne zwolennicy każdego z tych rozwiązań będą twardo obstawali przy swoim .
Uważam, że jak ktoś nauczy się czegoś nowego np. oprogramowania wbudowanego, które można zaimplementować na np. RasPi to nic złego się z nim nie stanie. Może nawet nieco lepiej, albo i nie , będzie pisał oprogramowanie na PLC.

Temat rzeka. Powiem tylko, że w prawdziwym przemyśle gdzie maszyny kosztują >>100000zł cena sterownika nie ma znaczenia i nikt nie skusi się na oszczędność nawet kilku tysięcy zł.
Tu bierze się pod uwagę takie kwestie jak:
- niezawodność - sterowniki PLC są naprawdę odporne na kurz, na wstrząsy, na wilgoć, na przepięcia itp.
- wygodę budowy, rozbudowy o kolejne moduły, panele operatorskie.
- możliwość ewentualnej naprawy. W każdej chwili możemy kupić identyczny sterownik, panel, moduł rozszerzeń, wgrywamy program i maszyna po max 2 dniach zaczyna pracować.
- możliwość zmiany konfiguracji, dołożenia funkcji nie tylko przez producenta, ale przez każdego specjalistę znającego język plc (no może nie każdego, wiadomo o co chodzi).
- ogólnoświatowe standardy. Podobnie buduje się maszyny w Europie, USA, Rosji czy Chinach. Jeśli maszyna oparta będzie na tym samym PLC to nie ma znaczenia w jakim kraju będzie kupiona (pomijając język interfejsu i napięcie zasilania) i zawsze spełnione będą wszystkie powyższe warunki.

Admin:
"Powiem tylko, że w prawdziwym przemyśle gdzie maszyny kosztują >>100000zł cena sterownika nie ma znaczenia i nikt nie skusi się na oszczędność nawet kilku tysięcy zł"

czyli rozumiem ze sa przemysły prawdziwe i te mniej prawdziwe ? Ciekawe kto je dzieli.

ale zeby post nie byl tylko pustym podsumowaniem wypowiedzi własnie wpdał w moja skrzynke newsletter:

... jako alternatywa dla tych co nie chca przyjąc do wiadomosci ze to tylko kwestia czasu. Co prawda o RPi ale pewnie i Arduino sie cos niebawem ukaże

https://elektronikab2b.pl/biznes/49937-raspberry-pi-coraz-wiecej-profesjonalnych-zastosowan?utm_source=newsletter&utm_medium=mailing&utm_content=elapa&utm_campaign=050918

Zgoodie wrote:

czyli rozumiem ze sa przemysły prawdziwe i te mniej prawdziwe ? Ciekawe kto je dzieli.

Poniekąd miałem na myśli duże, profesjonalne zakłady z dużym parkiem maszynowym. Ale są też firmy, które życzą sobie rozwiązania budżetowe: maszyna uspawana przez "pana janka", silniki, siłowniki z odzysku, szafa również składana z kilku. Tu jeśli ktoś zaproponuje "inwestorowi" że założy sterownik za kilkadziesiąt zł + koszty programowania to ma to szanse powodzenia. Tylko co w przypadku gdy będzie awaria a osoba, a która programowała tą maszynę będzie akurat niedostępna? Od wielu lat są też dostępne przekaźniki programowalne czy bardzo tanie sterowniki plc, na których też można uruchomić większość aplikacji - nie trzeba od razu kupować Siemensa.

Zgoodie wrote:

... jako alternatywa dla tych co nie chcą przyjąć do wiadomości ze to tylko kwestia czasu. Co prawda o RPi ale pewnie i Arduino sie cos niebawem ukaże
https://elektronikab2b.pl/biznes/49937-raspberry-pi-coraz-wiecej-profesjonalnych-zastosowan?utm_source=newsletter&utm_medium=mailing&utm_content=elapa&utm_campaign=050918

Ale ten artykuł jest jakby o czymś innym. RPi może być oczywiście częścią większego modułu, czy panela operatorskiego czy nawet sterownika PLC. Z tym, że to nie będzie tak, że programista będzie kupował płytkę RBi i na tym będzie budował maszynę - dostępne będą (i zapewne już są) gotowe rozwiązania modułowe, spełniające określone standardy, posiadające interfejsy itp, których sercem może być jakaś znana platforma. Mam nadzieję, że widać różnicę.

Sęk w tym ze wiekszość z piszących przy tym pytaniu z tematu posta widzi od razu sterowanie całą linia produkcyjną wielomilionowe lub "setkotysięczne" inwestycje. A jednak przemysl - każdy - to setki drukarek(znakowarek produktów), etykieciarek i owijarek palet i kartonów z produktem i maszyn pakujacych. Mysle ze tych drobnych rzeczy w przemysle jest duzo wiecej niz DCS-ów itp. sterowan - nawet w skali kraju. W tych urzadzeniach własnie jest miejsce na rozwiazania Arduino i RPi pewnie po wpakowaniu w obudowe i dodaniu Bread'a. Wiec jedna z odp. pytanie autora postu "Dlaczego w fabrykach nie stosuje się Arduino tylko PLC?" moze to tylko kwestia czasu.

Oczywiście masz rację, to się już dzieje odkąd owe platformy się pojawiły.

Przeczytałeś cytowany newsletter? 1/3 treści jest o powodach, dla których RPi nie nadaje się do przemysłu, 1/3 zachwytu nad ideą open source, reszta to reklama klonów RPi, które mają je dostosować do zwyczajnych przemysłowych wymagań.

Przemysł zarabia wielkie mnóstwo gdy produkuje i traci wielkie mnóstwo gdy stoi. Za tym idą konkretne potrzeby, oraz narzędzia do ich zaspokajania. Arduino i Raspberry służą do realizacji innych potrzeb.

W tym wątku jest wiele merytorycznych postów o potrzebach przemysłu i technice używanej do ich realizacji. Mimo to część kolegów sprowadza zagadnienie do "przyjdzie nowe pokolenie, to będą robić po nowemu", ignorując fakt, że narzędzia dobiera się do potrzeby, nie odwrotnie.

RitterX wrote:

Nie kojarzmy automatyki przemysłowej ze stacjonarnymi rozwiązaniami w wielkich szafach. W węźle kinematycznym "stawie" robota trzeba to i owo raz zmierzyć a dwa wysterować.

Ramię robota stosuje się kompletne wraz z kontrolerem. Mierzy i steruje producent ramienia, nie producent maszyny. Ten sam argument dotyczy wszelkich urządzeń automatyki z procesoram i w środku. Urządzenia pomiarowe także kupuje się "z półki", jak dalece to możliwe. Dopiero gdy wychodzimy poza możliwości dostępnych seryjnie rozwiązań może mieć sens użycie czegoś niezwyczajnego. Wtedy staje się drogo, bardzo drogo.

RitterX wrote:

Trudno mi określić kto szybciej i taniej wyrzeźbi program sterujący. Na PLC czy na RasPi?.

Proponuję eksperyment. Użyj darmowego CodeSys do napisania sekwencji 50 kroków z zagnieżdżonymi współbieżnymi fragmentami, w języku SFC. Dla porównania Napisz tą samą sekwencję w dowolnie wybranym innym języku programowania. SFC da się nauczyć w dwa popołudnia.

@jestam newsletter odczytalem tak jak nalezy i wiem co pisze. Przekaz jest czytelny. Na pewno nie wykluczajacy przyszlosci Rpi w przemysle

poza tym:
napier piszesz to:
Opowieści o zastępowaniu języków PLC przez C/C++ to zupełna bajka. Napisz sekwencję rzędu 30 kroków z fragmentami współbieżnymi (tj. kilka kroków aktywnych jednocześnie) w diagramie sekwencji (SFC) i w C, poczujesz różnicę.

pozniej to

"Proponuję eksperyment. Użyj darmowego CodeSys do napisania sekwencji 50 kroków z zagnieżdżonymi współbieżnymi fragmentami, w języku SFC. Dla porównania Napisz tą samą sekwencję w dowolnie wybranym innym języku programowania. SFC da się nauczyć w dwa popołudnia." - takie podpuchy pisza ludzie z kompleksami... jak czytam takie rzeczy to zastanawiam sie co ty chcesz komus udowodnic. Swoja szybkosc? wyższosc ?
.

Odpusc sobie takie wypuchy a odpowiadaj na pytanie z posta.

jestam wrote:

Ramię robota stosuje się kompletne wraz z kontrolerem. Mierzy i steruje producent ramienia, nie producent maszyny. Ten sam argument dotyczy wszelkich urządzeń automatyki z procesoram i w środku. Urządzenia pomiarowe także kupuje się "z półki", jak dalece to możliwe. Dopiero gdy wychodzimy poza możliwości dostępnych seryjnie rozwiązań może mieć sens użycie czegoś niezwyczajnego. Wtedy staje się drogo, bardzo drogo.

Jak to jest z budową robotów wiem świetnie. Dlatego twierdzę, że w przemyśle, nawet tym masowym nie wszędzie i do wszystkiego jest miejsce na PLC, tyle.

jestam wrote:

Proponuję eksperyment. Użyj darmowego CodeSys do napisania sekwencji 50 kroków z zagnieżdżonymi współbieżnymi fragmentami, w języku SFC. Dla porównania Napisz tą samą sekwencję w dowolnie wybranym innym języku programowania. SFC da się nauczyć w dwa popołudnia.

Teoria grafów i teoria automatów jest całkiem dobrze rozwinięta do poziomu praktycznych implementacji i dostępnych bibliotek. Dlatego to nie jest problem dla języka wysokiego poziomu. SFC także na czymś bazuje. Moje obawy budzi coraz większe grono, które przedkłada skomplikowane metody nad proste rozwiązania. Dobrze się czują np. w programowaniu obiektowym a schemat drabinkowy kojarzy się z czarną magią dawnych czasów. Ciekawe co z tego wyniknie dalej? Wtedy gdy w znaczący sposób wzrośnie liczba tych drugich a ubędzie pierwszych?
W sumie nie tak dawno zakończyła się epoka klekoczących szaf z przekaźnikami układów sekwencyjnego sterowania. W niecałe 10 lat wielką, klekoczącą szafę sterowniczą zastąpiła mała cicha szafeczka z PLC. A w środku tych PLC siedziały np. SAB80C535, SAB80C517 albo SAB80C166 i też mocą obliczeniową nie epatowały.

jestam wrote:

Proponuję eksperyment. Użyj darmowego CodeSys do napisania sekwencji 50 kroków z zagnieżdżonymi współbieżnymi fragmentami, w języku SFC. Dla porównania Napisz tą samą sekwencję w dowolnie wybranym innym języku programowania. SFC da się nauczyć w dwa popołudnia.

Abstrahując od tego, że są programy które kompilują LAD na wsad hex do uC Więc automatycznie problemy z językami wysokiego poziomu znika, bo nie wyobrażam sobie pisać skomplikowanych sekwencji algorytmu grafcet czy SFC w cpp, C, java etc.

A wracając do CodeSys jest specjalna wersja pod malinke

Witam,

RitterX wrote:

poziomu praktycznych implementacji i dostępnych bibliotek. Dlatego
to nie jest problem dla języka wysokiego poziomu. SFC także na czymś bazuje. Moje obawy
budzi coraz większe grono, które przedkłada skomplikowane metody nad proste rozwiązania.
Dobrze się czują np. w programowaniu obiektowym a schemat drabinkowy kojarzy się z czarną
magią dawnych czasów. Ciekawe co z tego wyniknie dalej? Wtedy gdy w znaczący sposób wzrośnie
liczba tych drugich a ubędzie pierwszych?

Nic nie wyniknie Jak ktoś od początku uczył się powiedzmy języka C a potem przeszedł na C++ i
obiektowość to mam poprostu inny tok myślenia i podejścia do rozwiązania problemu. Z tego właśnie
wynika zdziwienie ludzi jak widzą drabinkę. Świat informatyków i języków obiektowych jest całkiem inny
niż automatyków programujących w drabince.

"Ale" - no właśnie jest jedno "ale". Koleżanka na jednej z uczelni prowadziła zajęcia z programowania
PLC dla automatyków i informatyków. Informatycy dużo lepiej sobie radzili .

Wracając do tematu:

bestler wrote:

Temat rzeka. Powiem tylko, że w prawdziwym przemyśle gdzie maszyny kosztują >>100000zł
cena sterownika nie ma znaczenia i nikt nie skusi się na oszczędność nawet kilku tysięcy zł.

Odpowiedź moim zdaniem mówiąca wszystko. Przy poważnych projektach nie ma możliwość zastosowania Artuino itp.
Co do małych projektów, również PLC. Czemu nie Arduino itp ? Bo to nie jest jeszcze jakikolwiek standard w przemyśle
a przemysł rządzi się swoimi prawami i ma dużą inercję jeśli chodzi o wprowadzanie nowych standardów i ciężko będzie się
przebić z tego typu rozwiązaniami. Teraz przemysł to sterownk PLC oraz sterownik PAC lub PC, z większą mocą obliczeniową.
Oczywiście możemy się nadal sprzeczać że dla małych projektów można Arduino a dla większych PLC. Jak ktoś chce stosować
nie ma problemu jednak przemysł jak pisałem wyżej rządzi sie swoimi prawami.

Pozdrawiam,

Wojciech. wrote:

Abstrahując od tego, że są programy które kompilują LAD na wsad hex do uC

RitterX wrote:

Teoria grafów i teoria automatów jest całkiem dobrze rozwinięta do poziomu praktycznych implementacji i dostępnych bibliotek. Dlatego to nie jest problem dla języka wysokiego poziomu. SFC także na czymś bazuje.

Tylko jak to debugować, a później diagnozować problemy z urządzeniem? Drabinka bardzo ułatwia funkcje kombinacyjne, ale pod warunkiem, że można zobaczyć stan styków i cewek na żywo, w pracującym PLC. SFC bez graficznej reprezentacji nie ma sensu. Sam edytor + kompilator nie wystarczy. Znacie jakieś narzędzia z taką funkcjonalnością dla Arduino czy RPi?

RitterX wrote:

Moje obawy budzi coraz większe grono, które przedkłada skomplikowane metody nad proste rozwiązania. Dobrze się czują np. w programowaniu obiektowym a schemat drabinkowy kojarzy się z czarną magią dawnych czasów. Ciekawe co z tego wyniknie dalej? Wtedy gdy w znaczący sposób wzrośnie liczba tych drugich a ubędzie pierwszych?

Jakoś to będzie. Myślę, że część się dostosuje wg reguły o wronach i krakaniu, a pozostali wrócą do apek na smyrfony, horoskopów www dla kotów i poważnych aplikacji biznesowych za grube pieniądze. Ostatecznie dinozaury będą miały żniwa, jak obecnie spece od COBOL.

Wojciech. wrote:

A wracając do CodeSys jest specjalna wersja pod malinke

No właśnie

Zgoodie wrote:

Napisz tą samą sekwencję w dowolnie wybranym innym języku programowania. SFC da się nauczyć w dwa popołudnia." - takie podpuchy pisza ludzie z kompleksami... jak czytam takie rzeczy to zastanawiam sie co ty chcesz komus udowodnic. Swoja szybkosc? wyższosc ?
Odpusc sobie takie wypuchy a odpowiadaj na pytanie z posta.

Kolego pohamuj emocje, bo ktoś może pomyśleć, że mierzysz innych swoją miarą. Studenci Politechniki ogarniają SFC po wykładzie i 2 laborkach po 2h 15min. Dawali radę za moich studenckich czasów, dają radę i dzisiaj.

Przykład bardzo prostej sekwencji z Wikipedii: https://en.wikipedia.org/wiki/Sequential_function_chart


Implementacja w C mogłaby podobnie do kodu poniżej:


Problem pojawia się przy wyjściu ze stanu CHARGE_B. Jak reprezentować operację współbieżną? Co zrobić, gdy w obu gałęziach będzie po kilka kroków? Co zrobić, gdy w gałęzi będzie kolejny fragment współbieżny?

Rozmiar kodu już robi się kłopotliwy, brakuje całego środowiska wykonania, które PLC po prostu ma gotowe, a debugowanie wymaga zatrzymania programu, żeby podejrzeć wartości zmiennych stanu. A to tylko banalna sekwencja z kilku kroków i tranzycji.

Z takich, między innymi, powodów z reguły stosuje się PLC programowane SFC+ST+drabinką, a nie Arduino, RPi czy cokolwiek innego programowane w C/C++.
Oczywiście są też sytuacje wyjątkowe, gdy zwykłe metody, siły i środki nie wystarczają.

Ogólnie pewnym powodem jest też chęć pozostania przy tym co jest.

W przemyśle często można spotkać standardy które powstały parę dekad temu.
Mamy przykład MODBUS- lata 70-te
A wciąż ma się dobrze.

O standardach sprzętowych też można by sporo mówić.
Siemens S7-1200 z którego korzystałem na zajęciach(jestem studentem automatyki) miał przetworniki ADC o prękości maksymalnej kilku ksps.

Dla porównania Arduino ma ADC pracujący z maksymalną prędkością równo 10ksps.
Byle STM32 trzyma już 1Msps.
Porty szeregowe też są bardzo popularne.

Certyfikaty, przygotowanie do pracy w trudnych warunkach oraz profesjonalizm(wsparcie, dokumentacja, oprogramowanie) robią swoje.

Aby zrobić z Arduino,Rpi czy innego mikrokontrolera dobry sterownik trzeba sporo pracy.
Jak uda się samemu to oszczędzamy sporo pieniędzy(pospolite części bez atestów i wsparcia kosztują grosze w porównaniu z profesjonalnymi częściami), jednak kiedy coś pójdzie nie tak, to odpowiadamy za to jako projektant/konstruktor.

Może trochę z innej branży. Zgrzewarki punktowe profesjonalne kosztują ~2000zł.
Zgrzewarka punktowa na podstawie trafa z mikrofali kosztuje kilka razy mniej.
Jednak ktoś musi to poskładać, zaprojektować i dać na to gwarancję.
Dlatego w fabryce baterii rzadko spotykane są samoróbki.
Co innego w warsztacie naprawczym albo innego typu serwisie.

jestam wrote:

Studenci Politechniki ogarniają SFC po wykładzie i 2 laborkach po 2h 15min. Dawali radę za moich studenckich czasów, dają radę i dzisiaj.

SFC czy GRAFCET nie są jakoś zbytnio skomplikowane bo już na egzaminach mechatronicznych w technikum jest dość trudnym poziomie zagmatwania. Ale to zależy od rodzaju pracy maszyny, bo jedna może mieć prosty liniowy algorytm bez rozgałęzień a druga może być zagmatwana.
Ale plusem tego wszystkiego jest to że idzie bardzo prosto przejść z algorytmu na język drabinkowy. Czasami bezmyślnie się błądzi i szuka rozwiązania a tutaj wyciągamy wcześniej przygotowany algorytm i przechodzimy z kroku do kroku spełniając tranzycje.

Dodano po 21 [minuty]:

Rariusz wrote:

Nic nie wyniknie Jak ktoś od początku uczył się powiedzmy języka C a potem przeszedł na C++ i
obiektowość to mam poprostu inny tok myślenia i podejścia do rozwiązania problemu. Z tego właśnie
wynika zdziwienie ludzi jak widzą drabinkę. Świat informatyków i języków obiektowych jest całkiem inny
niż automatyków programujących w drabince.

"Ale" - no właśnie jest jedno "ale". Koleżanka na jednej z uczelni prowadziła zajęcia z programowania
PLC dla automatyków i informatyków. Informatycy dużo lepiej sobie radzili .

Schemat drabinkowy to jest istota algorytmiki czyli zwięzłego i jednoznacznego zapisu zadania, stanów. Tu nie ma specjalnie znaczenia język programowania choć niektóre są lepsze do tego a inne gorsze. Niepokojące to jest to, że coraz większa rzesza sobie z tym nie specjalnie radzi. Zaliczenie przedmiotu tak, praktyczna umiejętność tworzenia takiego zapisu już nie. Stąd zapewne pojawiają się i będą coraz częściej próby "informatycznego" obejścia tego typu problemów. Programy staną się bardziej ociężałe, większe a tym samym bardziej podatne na uszkodzenia i nieprzewidziane działanie. Często "wyjeżdża" się z problemem EMC, który w sumie jest techniczne błahy. Gdy tymczasem przemysłowe i nie tylko stricte przemysłowe systemy mają wbudowane mechanizmy autodiagnostyki. Tym bardziej niskopoziomowe im odpowiedzialniejsze jest zadanie. Nawet jak nie wszyscy sobie zdają sprawę z istnienia tego typu mechanizmów to one są zaimplementowane. Choć nie zawsze widoczne z warstwy oprogramowania użytkowego. Bardzo ważnym elementem zabezpieczeń jest autodiagnostyka sterownika by w trakcie pracy, w przypadku awarii przeszedł w dosyć określony stan. Na tyle na ile pozwalają jeszcze nie uszkodzone wyjścia, ograniczenie szkód.
Bywa, że moduł sterujący ulegnie awarii. Wtedy zwolennicy EMC ruszą z pielgrzymką "To na pewno było wyładowanie" na co naturaliści "Jakie tam wyładowanie, to był skok temperatury, czujecie tę wilgoć w kościach" . A prawda jest taka, że moduł trzeba wymienić i puścić sprzęt w ruch by zarabiał.

Wracając do tematu wątku. Nie próbowałem osadzić na Arduino np. FORTH-a a zbliżyłoby, w sensie działania, ten moduł do PLC a konkretniej filozofii PLC.

jestam wrote:

Problem pojawia się przy wyjściu ze stanu CHARGE_B. Jak reprezentować operację współbieżną? Co zrobić, gdy w obu gałęziach będzie po kilka kroków? Co zrobić, gdy w gałęzi będzie kolejny fragment współbieżny?

Rozmiar kodu już robi się kłopotliwy, brakuje całego środowiska wykonania, które PLC po prostu ma gotowe, a debugowanie wymaga zatrzymania programu, żeby podejrzeć wartości zmiennych stanu. A to tylko banalna sekwencja z kilku kroków i tranzycji.

I tutaj pojawia się programowanie obiektowe pobierające parametry z odpowiedniego skryptu nie zaś na sztywno.

Podchodzę do automatyki od strony informatycznej i pierwsze co zawsze widzę jak przychodzi mi poprawiać program to niechlujstwo osoby budującej pierwotny algorytm. Z tego wychodzi niechlujna drabinka i konieczność debugowania.

Witam,

Neuromancer_Kathar wrote:

I tutaj pojawia się programowanie obiektowe pobierające parametry z odpowiedniego skryptu nie zaś na sztywno.

Jak to wykonasz na sterowniku PLC?

Pozdrawiam,

Neuromancer_Kathar wrote:

I tutaj pojawia się programowanie obiektowe pobierające parametry z odpowiedniego skryptu nie zaś na sztywno.

obiektowe jest całkowicie niemodne, skrypty programują hipsterów tylko w paradygmacie funkcjonalnym!

B.P.A.N.M.S.P.