Elektroda.pl
Elektroda.pl
X
Computer ControlsComputer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Dlaczego w fabrykach nie stosuje się Arduino tylko PLC?

29 Lis 2018 21:01 10758 80
  • #61
    Rariusz
    Specjalista Automatyk
    Witam,

    jestam napisał:

    :shocked!: obiektowe jest całkowicie niemodne,
    B.P.A.N.M.S.P.


    Nie modne ale przyszłościowe. Obecnie można programować obiektowo w ST na PLC
    ale skypty hmmmm.....

    Pozdrawiam,
  • Computer ControlsComputer Controls
  • #62
    Neuromancer_Kathar
    Poziom 12  
    Rariusz napisał:
    Witam,

    jestam napisał:

    :shocked!: obiektowe jest całkowicie niemodne,
    B.P.A.N.M.S.P.


    Nie modne ale przyszłościowe. Obecnie można programować obiektowo w ST na PLC
    ale skypty hmmmm.....

    Pozdrawiam,


    Widzę, że wdaje się tutaj nieporozumienie. Skryptem należy rozumieć dowolny ciąg bitowy danych. Albo w formie binarnej, albo innym kodzie (BCD przykładowo). Nawet plik tekstowy można rozważyć jako skrypt.


    Realizować to można albo poprzez osobną kartę w HMI, albo przez DIP Switche i podobne.

    Z drugiej strony po głębszym zastanowieniu skrypty to mogą być must have jeżeli chodzi o połączenia urządzeń z bazami danych.
  • Computer ControlsComputer Controls
  • #63
    Rariusz
    Specjalista Automatyk
    Witam,

    Neuromancer_Kathar napisał:

    Widzę, że wdaje się tutaj nieporozumienie. Skryptem należy rozumieć dowolny ciąg bitowy danych. Albo w formie binarnej, albo innym kodzie (BCD przykładowo). Nawet plik tekstowy można rozważyć jako skrypt..


    Ooooo to coś nowego!!!. Możesz rozwinąć swoją myśl ? :). Dla mnie skrypt
    to np plik w vb. na panel HMI.

    Pozdrawiam,
  • #64
    Neuromancer_Kathar
    Poziom 12  
    W C istnieje coś takiego jak pobieranie danych z pliku tekstowego. Tylko, że dane nie musisz pobierać z pliku, a z dowolnego źródła - np. z sposobu ustawienia jakichś wejść.
  • #65
    Rariusz
    Specjalista Automatyk
    Witam,

    Neuromancer_Kathar napisał:
    W C istnieje coś takiego jak pobieranie danych z pliku tekstowego. Tylko, że dane nie musisz pobierać z pliku, a z dowolnego źródła - np. z sposobu ustawienia jakichś wejść.


    Nie żebym się czepiał ale odczyt wejść a odczyt pliku to nie odczyt skryptu...
    Jak mówisz skrypt to ludzie mają na myśli jakiś plik z kodem w jakimś jezyku
    który coś robi. Odczyt wejść mówi że odczytujesz dane z konkretnych wejść
    a nie że odczytujesz bądź uruchamiasz jakiś skrypt. Zbyt duże uogólnienie
    wprowadziłeś które jest moim zdaniem błędne i może wprowadzać w błąd.

    Pozdrawiam,
  • #66
    Neuromancer_Kathar
    Poziom 12  
    Nie zmienia to faktu, że zmiana takiego źródła zmienia zachowanie maszyny. Taki PLC wykorzystujący C można podłączyć za pomocą wejść wyjść do takiego raspberry, czy czegokolwiek, na czym już uruchomisz dowolny język skryptowy. Od zwykłego basha przez Pythona do co uda się wymyślić.

    Pi to przykład rozwiązania lowcost.
  • #67
    jestam
    Specjalista Automatyk
    Neuromancer_Kathar napisał:
    jestam napisał:
    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.


    Jeszcze raz od początku. Diagram sekwencji (SFC, Grafcet, itp.) pozwala łatwo programować sekwencje. Kodowanie sekwencji w drabince, ST, C++, Pythonie, itp. jest trudne z powodów podanych wcześniej. Programowanie obiektowe w niczym tu nie pomaga. Trochę, ale tylko trochę, pomaga, jeśli w języku jest async/await (np. C#), ale środowiska z automatycznym zarządzaniem pamięcią mają swoje ograniczenia. Kodowanie, diagnostykę i debuggowanie sekwencji najłatwiej robić w języku graficznym, który obrazuje kroki, tranzycje i ich połączenia.

    Pomysły niektórych firm, żeby do PLC wstawiać dynamiczną alokację pamięci i polimorfizm ("obiektowe ST" od B. z operacjami typu __NEW i __DELETE, wskaźnikami do instancji bloków FB i tak dalej) wołają o pomstę do nieba. Ale oni nazywają swoje produkty IPC ("Industrial PC"), więc jeśli chcesz PLC to kup coś innego :roll:

    Neuromancer_Kathar napisał:

    Widzę, że wdaje się tutaj nieporozumienie. Skryptem należy rozumieć dowolny ciąg bitowy danych. Albo w formie binarnej, albo innym kodzie (BCD przykładowo). Nawet plik tekstowy można rozważyć jako skrypt.

    Realizować to można albo poprzez osobną kartę w HMI, albo przez DIP Switche i podobne.

    Z drugiej strony po głębszym zastanowieniu skrypty to mogą być must have jeżeli chodzi o połączenia urządzeń z bazami danych.


    Czyli skryptem wg Twojej definicji jest filmik ze śmiesznym kotem.
    Reszta cytatu to kompletne pomieszanie pojęć.

    Wracając do tematu.
    Niedrogi Raspberry Pi w wykonaniu przemysłowym.
  • #68
    Neuromancer_Kathar
    Poziom 12  
    jestam napisał:


    Czyli skryptem wg Twojej definicji jest filmik ze śmiesznym kotem.
    Reszta cytatu to kompletne pomieszanie pojęć.



    Jeżeli efektem będzie wykonanie przez urządzenie danej akcji to nie widzę przeszkód.

    PLC mają jedną zaletę która dyskwalifikuje Arduino - RT.


    Poważne urządzenia jednak działają już na PC z odpowiednimi rozszerzeniami kontaktującymi się z PLC. Linux Realtime albo VxWorks to podstawa dla takich w sumie to już maszyn. Zwykłe PLC to się nie nadaje do niczego bardziej skomplikowanego.
  • #69
    Rariusz
    Specjalista Automatyk
    Witam,

    Neuromancer_Kathar napisał:
    Poważne urządzenia jednak działają już na PC z
    odpowiednimi rozszerzeniami kontaktującymi się z PLC. Linux Realtime albo VxWorks
    to podstawa dla takich w sumie to już maszyn. Zwykłe PLC to się nie nadaje do niczego
    bardziej skomplikowanego.


    Sterowniki RX3i, RX7i, Roboty KUKA działają pod systemem VxWorks.
    Wyżej wymienione sterowniki do komunikacji z modułami korzystają
    z magistrali PCI. Dodatkowo to co chyba nie zostało powiedziane:
    Program do sterowania urządzeniami przemysłowymi zrealizujemy
    za pomocą dostępnych języków programowania w PLC z wyłączeniem
    C/C++. Mówiąc dokładnie wszelkie praktyczne zastosowania są
    do zrealizowania za pomocą PLC i dedykowanych języków. Wystarczy
    przejść sie po dużym zakładzie przemysłowym.

    Neuromancer_Kathar napisał:
    Zwykłe PLC to się nie nadaje do niczego
    bardziej skomplikowanego.


    Jeśli popatrzymy na to do jakich aplikacji sterowniki są przystosowane okazuje się że
    można wykonywać bardzo wiele. Wystarczy popatrzeć na stare maszyny wyposażone
    w sterowniki Simatic S5. Przecież to stare zwykłe sterowniki. Widziałem wiele skomplikowanych maszyn
    z tymi sterownikami i naprawdę szacunek dla programistów. Bo teraz są ładne i wygodne narzędzia do programowania,
    debagowania itp. A przecież Simatic S5 to lata 80-90 czyli dawno dawno temu. Oprogramowanie
    do sterowników S5? No cóż kto programował ten wie :)

    jestam napisał:
    Pomysły niektórych firm, żeby do PLC wstawiać dynamiczną alokację pamięci i polimorfizm
    ("obiektowe ST" od B. z operacjami typu __NEW i __DELETE, wskaźnikami do instancji bloków FB i tak dalej)
    wołają o pomstę do nieba.


    Mają dużą zaletę ale nazwijmy to "tradycyjni" programiści PLC będą mieli kłopot z ogarnięciem tematu
    bo tutaj już trzeba zmienić tok myślenia.


    Pozdrawiam,
  • #70
    Neuromancer_Kathar
    Poziom 12  
    Bardzo wiele to można też zrobić za pomocą wyłącznie przekaźników idąc potem do układów DTL i TTL. Chodzi o to aby współczynnik koszt efekt był najlepszy.

    Wiadomo, że na PLC nie zrobisz IOT. Ogólnie Przemysł 4.0 będzie dążył do tego, aby jak najbardziej specjalizować zadania w maszynach. Co będzie bardziej niezawodne w PLC zostanie dalej wykonywane w PLC, ale inne rzeczy niekoniecznie.
  • #71
    Rariusz
    Specjalista Automatyk
    Witam,

    IoT Link Poza tym masz bramki IoT.

    Pozdrawiam,
  • #72
    gremik
    Poziom 10  
    Cześć,
    Pytanie jest trochę nie na miejscu.
    Porównałbym to do czegoś takiego: "dlaczego w firmach budowlanych stosuje się koparki zamiast łopat?"
    Odpowiedź: Stosuje się i to i to.
    Łopata (Arduino) może się czasami przydać do wykonania jakiejś niewielkiej pracy. Arduino to nic innego jak mikrokontroler z uproszczonym środowiskiem programowania i na ustandaryzowanej płytce PCB. Mikrokontrolery są w przemyśle wszechobecne - w każdym trochę bardziej skomplikowanym czujniku czy elemencie wykonawczym. Nawet wiele (o ile nie wszystkie) małych PLC jest budowanych w oparciu o mikrokontrolery i to w zupełności wystarcza.
    Arduino jest jednak dość spore i może być kłopotliwe w wielu zastosowaniach. Jak je zmieścić w czujniku który ma 3x2x2cm?
    Ale ten sam chip AVR w odpowiedniej obudowie już jak najbardziej tam zmieścimy. Tylko zwykle użyjemy już profesjonalnego środowiska do jego oprogramowania a nie Arduino IDE.

    Jest kilka specyficznych wymagań których Arduino nie spełnia, a spełniają PLC.
    - PLC mają już obudowę o której użytkownik nie musi myśleć,
    - PLC mają I/O w standardach przemysłowych i użytkownik nie musi myśleć jak dopasować sterownik do reszty układu sterowania,
    - PLC mają wbudowane porty komunikacyjne/protokoły (Modbus, Profibus) używane w przemyśle i klient nie musi szukać bibliotek C które by je wspierały, ani zastanawiać się jak użyć tej biblioteki do zestawienia połączenia z innym urządzeniem.
    - PLC wspierają diagnostykę on-line i wszystkie mocniejsze PLC wspierają modyfikowanie programu on-line (to znaczy podczas ruchu maszyny),
    - PLC posiada system operacyjny (RTOS) który zarządza jego pracą i wykonywaniem programu (obsługa I/O, przerwań, komunikacji, autodiagnostyki) i programista nie musi już o tym myśleć. Wielu programistów nawet nie wie że RTOS siedzi w środku!
    - Wielu programujących i większość obsługujących/modyfikujących oprogramowanie sterowników PLC to elektrycy którzy radzą sobie dość dobrze z językiem drabinkowym i nie bardzo z C/C++,
    - Średnie PLC wspierają do kilku tysięcy punktów I/O a duże nawet do kilkudziesięciu tysięcy I/O - pojedyncze Arduino tego nie obsłuży!
    - Wszystkie większe (i wiele małych) PLC maja wbudowany zegar RTC - czy ma je Arduino?
    - i pewnie jeszcze kilka które nie przychodzą mi teraz do głowy.

    Mówienie o większej prędkości Arduino w porównaniu z PLC to spore nieporozumienie.
    Co porównujemy? Częstotliwość zegara Arduino z cyklem obiegu całego programu w PLC?
    Podobnie z próbkowaniem wejść I/O - większość standardowych wejść I/O ma wbudowany filtr 8-16ms do wytłumienia zakłóceń - na przykład po to aby odczytać prawidłowo przyciśnięcie przycisku na pulpicie sterowniczym (albo zadziałanie krańcówki) zamiast wszystkich drgnięć styku w tym przycisku.
    Specjalizowane wejścia na PLC (te gdzie wyłączono filtrowanie) mogą odczytywać sygnały o częstotliwości powyżej 1kHz.

    Użycie Arduino do sterownia jakąś małą maszyną jest również trochę bez sensu. Czasami może zadziałać ale co jeśli klient wymaga zmodyfikowania maszyny pod swoje konkretne wymagania - trzeba program przepisać a może dołożyć trochę elektroniki do sterownia. W PLC dołożenie i oprogramowanie nowych I/O albo karty komunikującej się w jakimś innym protokole to pikuś - czy w Arduino również?
    Jak podłączyć Arduino do korporacyjnego HMI i MES - będziecie pisać sterownik (mam na myśli oprogramowanie) obsługujący Arduino dla tego HMI? Ile czasu to zajmie i jaki będzie koszt takiego sterownika?

    Podsumowując:
    - Arduino jest za słabe do wielu (jeśli nie większości) zastosowań przemysłowych w roli sterownika,
    - Arduino wymaga większego nakładu pracy aby go użyć w zastosowaniach przemysłowych (a praca to teraz największy koszt),
    - Arduino nie posiada wielu cech PLC które są kluczowe w zastosowaniach przemysłowych.

    Pozdrawim,
    gremik
  • #73
    przemwach
    Poziom 15  
    Spór i rozważania ciekawe PLC czy Arundino (czytaj uProcesor w czystej postaci).
    Mam wrażenie, że Panowie zapomnieli lub nie wiedzą dla kogo zostały zbudowane PLC. Otóż dla zwykłych elektryków. Tak dla elektryków, którzy w latach 80 i wcześniej ubiegłego wieku projektowali maszyny na stycznikach i przekaźnikach. To pod nich i dla nich stworzono języki drabinkowe, blokowe i dorzucono coś ala asembler oraz Basic czy Pascal (to dla tych trochę obytych z programowaniem). Wówczas programowanie zajmowali się głównie Panowie na uczelniach wyższych a ich czas kosztował i nie było ich wielu.
    To też by ułatwić i uprościć budowę maszyn sięgnięto po procesory, które mogły i mogą zastąpić logikę opartą na stycznikach i przekaźnikach. Pomysł trafiony, ale kto to obsłuży? Kto w zakładzie produkcyjnym zatrudnia programistów (lata 80)?
    Mamy rzeszę inż. elektryków i elektryków to zróbmy oprogramowanie, które oni będą rozumieli i tak powstały języki drabinkowe. Dzięki tym prostym językom sterowniki podbiły świat. Masa ludzi zaczęła programować, świat szedł dalej z postępem, dziś prawie w każdym technikum i na studiach inżynierskich uczy się podstaw programowania. To jest inna epoka, teraz już są ludzie znający podstawy programowania i dla nich łatwiej jest tworzyć program w językach tekstowych.
    Każdy język programowania jest dobry jeśli cel jest osiągnięty i programista jest świadomy co napisał i wie jak jest to realizowane w programie.
    Wszelkie języki graficzne powstają w celu ułatwienia programiście pracy, łatwiejszego zobrazowania problemu, czy łatwiejszej diagnostyki. To co jest możliwe do napisania w językach graficznych bez problemu realizuje się w językach tekstowych. To czy to jest czytelne zależy tylko i wyłącznie od piszącego. Tekst jest prosty do formatowania a to poprawia czytelność.
    Dlaczego nie Arduino a PLC wielu już tu napisało prawdę, dodam tylko bo prościej, łatwiej, jest wsparcie, są gotowe rozwiązania programowe i sprzętowe. Ale pamiętajmy PLC to nic innego jak mikroprocesor, to co można zrobić na PLC można zrealizować na Arduino czy innym mikroprocesorze.
    Z mojego doświadczenia PLC zazwyczaj stosuje się przy produkcji jednostkowej, mało seryjnej. Dla produkcji seryjnej taniej jest stworzyć dedykowany sprzęt od podstaw lub skorzystać z gotowych rozwiązań jak Arduino czy Raspberry Pi i przystosować je w jakimś stopniu (dziś staje się już to normą, tak się tnie koszty a sprzęt sprawdzony).

    Czy iść w stronę PLC czy Arduino, warto znać to i to. Pierwsze jest powszechnie stosowane i dziś łatwe do nauki bo oprogramowanie jest za darmo (jak np. oprogramowanie CoDeSys) warto zajrzeć by coś wiedzieć. Drugie jak się podejdzie do tematu na poważnie pomoże zrozumieć zasadę działania procesorów, komputerów i całej elektroniki na nich opartej łącznie z PLC.
  • #74
    gervee
    Specjalista Automatyk
    przemwach napisał:

    Z mojego doświadczenia PLC zazwyczaj stosuje się przy produkcji jednostkowej, mało seryjnej. Dla produkcji seryjnej taniej jest stworzyć dedykowany sprzęt od podstaw lub skorzystać z gotowych rozwiązań jak Arduino czy Raspberry Pi i przystosować je w jakimś stopniu (dziś staje się już to normą, tak się tnie koszty a sprzęt sprawdzony).


    Ciekawe jest to co piszesz bo wielkoseryjna produkcja fabryk automotive jedzie na PLC. Praktycznie większość maszyn/linii na tym jest postawiona.

    Być może masz na myśli produkty będące wynikiem produkcji - małe serie PLC, duże serie - specjalizowane sterowniki "szyte" na miarę potrzeb urządzenia. Jeśli to masz na myśli to zgadzam się z Tobą.
    Niemniej jednak Arduino to do domu się nadaje a nie do fabryki czy przemysłu i nikogo "chcenie" nic tu nie zmieni.
  • #76
    Zgoodie
    Poziom 22  
    Arduino jest opensorce'owy . Info ze strony
    Arduino Uno is open-source hardware! You can build your own board using the following files... (gerber schemat itp)

    To oznacza ze mozesz sam stac sie producentem i modyfikatorem plyt a wiec sam nadac CE w takim przypadku. CE nadaje tylko producent urzadzenia.


    BTW nie wszystkie komponenty w szafach elektrycznych wymagają CE, a samo urządzenie z nich wykonane może miec CE i w takim przypadku nadaje je Tworca urządzenia dla urządzenia, a nie elektroniki w srodku !!!!!
  • #77
    jotko
    Poziom 20  
    To zapodaj link do takich urządzeń.
    Cytat:

    nie wszystkie komponenty w szafach elektrycznych wymagają CE

    Rozumiem że można wyprodukować coś (maszynę) zgodnie z zharmonizowani normami i zasadami wiedzy technicznej ale później należy przejść żmudny proces oceny zgodności CE oraz wyznaczyć poziom bezpieczeństwa SIL i PL czyli ocenę funkcji bezpieczeństwa. A sam tego nie zrobisz. Myślę że dla prototypu maszyny nie zmieścisz się w 40kPLN.
  • #78
    Zgoodie
    Poziom 22  
    oj juz nie przesadzaj z tym żmudnym procesem. Nie domunizujcie juz tego CE tak bardzo, nie święci garnki lepia.
    "Sam tego nie zrobisz" - a czemuż to nie...
  • #79
    jotko
    Poziom 20  
    Poczytaj sobie o konsekwencjach oraz o obowiązkach producenta.
    Np znalezione na gorąco w necie:
    Osoba wprowadzająca produkty nie posiadające oznaczenia CE, bądź też niespełniające wymagań dyrektyw i norm, naraża się na wiele nieprzyjemnych sytuacji. Po pierwsze taka osoba taka może otrzymać karę grzywny, w wysokości do 100 000 złotych ..

    Ze tak się zapytam, czytałeś kiedyś Dyrektywę Maszynową 2006/42/WE?
  • #80
    Zgoodie
    Poziom 22  
    oczywiscie ze to prawda. CE jest obowiazkowe dla producentow wprowadzajacych/sprzedajacych w unii urzadzenia. Wszystko sie zgadza.
  • #81
    tzok
    Moderator Samochody
    Arduino z założenia jest platformą deweloperską, nie produkcyjną. Sama płytka Arduino to mikrokontroler, kwarc i stabilizator, oraz ew. konwerter rs232 na USB. Wbudowywanie Arduino w urządzenie produkcyjne nie ma większego sensu, bo i tak trzeba zaprojektować PCB na peryferia z miejscem na osadzenie Arduino... to lepiej po prostu na tym PCB umieścić mikrokontroler z niezbędnym otoczeniem. Stosowanie Arduino może ma sens przy prototypach i produkcji jednostkowej, ale nie w produkcji seryjnej. Taniej wyjdzie umieścić te same komponenty na jedynym PCB z interfejsami i układami wykonawczymi. Jeśli już ktoś produkuje coś z płytką Arduino w środku, to są to jakieś startupy, którą chcą być "trendy".

    Druga sprawa to programowanie - PLC są mocno ustandaryzowane i w razie potrzeby można za 5 czy 10 lat łatwo wprowadzić zmiany w programie, bo zmienił się proces produkcyjny. W PLC też siedzi mikrokontroler lub FPGA. Języki programowanie PLC są językami wysokiego poziomu, trudno w nich popełnić błędy programistyczne, nie trzeba się martwić o wycieki pamięci, przepełnienie stosu, konflikty przerwań i masę tego typu kwestii. Skupiasz się tylko na logice programu, a nie na kwestiach technicznych.

    RT... kwestia dyskusyjna, bo mając uK wykonujący jedynie zaszyty w nim na stałe program sterujący dokładnie wiemy ile zajmie jego wykonanie. Systemy RT próbują udawać takie środowisko dla współbieżnych procesów w obecności systemu operacyjnego.

    CE jest certyfikatem samo-przyznawalnym, to tylko deklaracja zgodności - nie musisz robić żadnych badań, ale oczywiście w razie czego odpowiadasz za niespełnienie norm, określonych w tej deklaracji.