Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Arduino, Raspberry PI w przemyśle

dondu 12 Sep 2020 20:38 14508 188
SterControl
  • #91
    khoam
    Level 41  
    Radzio M. wrote:
    Uważam, że Arduino nie zastąpi klasycznego sterownika PLC w maszynach przemysłowych.

    Czyli uważasz, że układy zbudowane w oparciu o mikroprocesory nie zastąpią "klasycznych" sterowników PLC. Masz prawo, ale Arduino to tylko oprogramowanie, a nie konkretne rozwiązanie sprzętowe.
  • SterControl
  • #92
    User removed account
    Level 1  
  • #93
    khoam
    Level 41  
    nightwatch wrote:
    A to sterowniki PLC nie są oparte o mikroprocesory?

    Nie jestem autorem tej opinii.

    Dodano po 16 [minuty]:

    nightwatch wrote:
    w końcu może powstać coś w modelu open source, z rosnącą rzeszą zaangażowanych w to twórców i entuzjastów i nagle się okaże że to już nie takie popierdółki.

    Taki projekt już istnieje: https://www.openplcproject.com/
  • #94
    _lazor_
    Moderator of Designing
    Ogólnie uważam że ktoś nieznający się na programowaniu powinien właśnie użyć PLC. Taka zabawka, gdzie ludzie siedzieli i zrealizowali całe urządzenie by użytkownik nie przewrócił się z swojego rowerka (a przynajmniej, by nie dostał w twarz związanym z problem działania np mikrokontrolera).

    Ostatnio uruchamiałem HC-06 i niestety dużo było materiałów pod arduino. No cóż jeden działający przykład rozlał się po internecie i stał się jakimś typowym examplem jak to należy robić... Przykład strasznie krzywy:
    https://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/
    No ale powiedzmy, przykład nie ma być wydajny, ale poważnie na odczyt i pisanie w pętli i jeszcze ifami?

    Dorzućmy jeszcze do tego nie znaną implementację odczytywania i pisania po serialu. Jeśli to też jest rozwiązane na jakimś poolingu to mamy najbardziej niewydajną implementację jaka jest możliwa.
    Dla przykładu moja implementacja (z wykorzystaniem przerwań oraz DMA) powoduje odczyt danych (nie ważne jak długich) w ciągu około 50 cykli (obsługa przerwania) a wysyłanie 470 cykli (znów nie ważne jak dużo danych i to jeszcze można zmniejszyć bo używam HAL od ST).

    Chodzi mi o to, że to wszystko dobrze wygląda w trywialnych przypadkach, ale te rozwiązania w bardziej złożonych systemach (np PLC) nie sprawdzą się, bo są napisane tak aby działały na wszystkich sprzętach jakie wspiera arduino a nie tak aby jak najlepiej działały i wykorzystywały bajery mające przyśpieszyć pracę programu.
  • SterControl
  • #95
    User removed account
    Level 1  
  • #96
    _lazor_
    Moderator of Designing
    To czy każdy mikrokontroler ma DMA to bym polemizował i to dość mocno.

    Inna sprawa że wysoko wypozycjonowane są przykłady tego typu, ja wiem że to dziadostwo, ale początkujący czy hobbysta?

    Pytanie też czy tak bardziej złożone elementy i tak nie są platform specific i nie są po prostu po za zakresem arduino?
  • #97
    khoam
    Level 41  
    nightwatch wrote:
    Ale to żaden argument, wziąłeś jakiś nieefektywny kod który ktoś tam narzeźbił bez pojęcia i przyjmujesz go jako punkt odniesienia dla całej platformy.

    To jest nagminna praktyka "marketingowa" w odniesieniu do platformy Arduino. Tak, jakby umiejętność projektowania i programowania w C++ i wykorzystywania zasobów sprzętowych danego MCU przez konkretną osobę miała cokolwiek wspólnego z możliwościami platformy software'owej, z której ta osoba korzysta.
  • #98
    _lazor_
    Moderator of Designing
    khoam wrote:
    nightwatch wrote:
    Ale to żaden argument, wziąłeś jakiś nieefektywny kod który ktoś tam narzeźbił bez pojęcia i przyjmujesz go jako punkt odniesienia dla całej platformy.

    To jest nagminna praktyka "marketingowa" w odniesieniu do platformy Arduino. Tak, jakby umiejętność projektowania i programowania w C++ i wykorzystywania zasobów sprzętowych danego MCU przez konkretną osobę miała cokolwiek wspólnego z możliwościami platformy software'owej, z której ta osoba korzysta.


    Z strony arduino:
    "Arduino is an open-source electronics platform based on easy-to-use hardware and software."

    Tak więc traktuję to tak jak piszą czyli software i hardware. Tutaj jest pytanie czy oni sensownie realizują sterowniki do hardware który oficjalnie wspierają?

    To co ja znalazłem było krzywe, ale czy jesteście mi pokazać jak to po "arduinowemu" jest zrealizowane dobrze? Konfiguracja UART tak by odbierał i wysyłał dane po DMA, dla obojętnie jakiego hardware.
  • #99
    User removed account
    Level 1  
  • #100
    Janusz_kk
    Level 34  
    Z avr-ów tylko AtXmegi mają DMA, niestety :(
  • #102
    User removed account
    Level 1  
  • #103
    khoam
    Level 41  
    Wojciech. wrote:
    Cały program wykonuje się na komputerze (runtime).

    Raczej na RPI lub czymś podobnym.
  • #104
    Wojciech.
    Level 35  
    nightwatch wrote:
    Nie znam się na PLC ale z tego co sie domyślam jest tam jakiś uproszczony język programowania na zasadzie składania klocków, więc masz do dyspozycji tylko te klocki co są w pudełku i możesz tylko mieć nadzieję że są to dobre klocki i nadają sie do tego do czego chcesz ich użyć.


    Języki programowania PLC to temat rzeka. Norma IEC 61131 wyróżnia generalnie 5 języków w których można programować PLC. Nie które sterowniki można programować tylko w jednym języku, najmocniejsze we wszystkich + wstawki w C++. Elektroników może zaciekawić język FBD czyli język programowania wykorzystując analogie bramek elektronicznych. Elektrycy znajda znowu język LD czyli drabinka ( odwrócony schemat elektryczny). Bardziej zaawansowani użytkownicy sięgają po tekst strukturalny ST coś jak pascal do zaawansowanych obliczeń matematycznych, sortowania czy własnych algorytmów. Jest też np język/ algorytm SFC coś jak UML. Obiektowość to też normalna sprawa.

    Do tego dochodzą protokoły komunikacyjne, napędy, wizualizacje, safety. Aktualnie IT wnika w automatykę i PLC.

    Dodano po 4 [minuty]:

    khoam wrote:
    Raczej na RPI lub czymś podobnym.


    SoftPLC można odpalić i na windowsie czy na linuksie. Np każdy sterownik Beckhoff ma Windowsa CE, jednak program jest wykonywany poza samym system dlatego jak wykrzaczy się Windows to program dalej jest wykonywany.
  • #105
    kaczodp
    Level 14  
    Wojciech. wrote:
    każdy sterownik Beckhoff ma Windowsa CE, jednak program jest wykonywany poza samym system dlatego jak wykrzaczy się Windows to program dalej jest wykonywany.

    A już się wystraszyłem, że Windows jest używany tam gdzie wymagana jest niezawodność i zaczną go używać do sterowania pojazdami kosmicznymi. Do czego służy Windows w Beckhoff ? Interfejs użytkownika?
  • #106
    Wojciech.
    Level 35  
    kaczodp wrote:
    Do czego służy Windows w Beckhoff ? Interfejs użytkownika?


    O ile dana jednostka ma interfejs wideo to można sobie podłączyć ekran( wizualizacja) czy nawet postawić bazę danych. Dość popularny jest komputer przemysłowy z dotykowym panelem do interakcji z operatorem, tworzeniem wizualizacji SCADA itd. Równocześnie steruje procesem.
  • #107
    elektryku5
    Level 39  
    Co do PLC, był kiedyś taki projekt na AVR i PIC https://cq.cx/ladder.pl

    Z tym Arduino jako PLC, to ma to szanse w jakiś tanich projektach, w konkretnej automatyce PLC (sam CPU) to jest akurat jeden z tańszych komponentów i większe znaczenie niż jego cena ma cały ekosystem, rozproszone IO, serwa, falowniki, HMI i sieć która to spina.

    No i co do języka, w takich aplikacjach mimo wszystko LAD ma swoje plusy, przy maszynie diagnostyka takiego kodu jest dosyć szybka o ile ktoś go napisał z głową, na podglądzie widać co się świeci i na tej podstawie da się coś wywnioskować.
  • #109
    User removed account
    Level 1  
  • #111
    User removed account
    Level 1  
  • #112
    Wojciech.
    Level 35  
    nightwatch wrote:
    no ale Linux, na Raspberry Pi to taki powolny pecet, on w ogóle daje jakieś gwarantowane czasy reakcji na GPIO?


    Ale to się nikt nie bawi z GPIO tylko podpina się wyspę I/O dedykowaną do PLC np po Ethernet TCP/IP czy EtherCAT. A czas reakcji to zależy co potrzebujemy tak na prawdę.
  • #113
    User removed account
    Level 1  
  • #114
    Wojciech.
    Level 35  
    @nightwatch W przemyśle szybko zmienne procesy praktycznie nie występują, to jest margines. Program i tak jest wykonywany poza systemem (runtime plc). Największym problemem jest czas cyklu programu w słabszych PLC a nie magistrala. EtherCAT może osiągąc czasy poniżej 1 us do pozycjonowanie czy synchronizacji osi.
  • #115
    User removed account
    Level 1  
  • #116
    _lazor_
    Moderator of Designing
    Wojciech. wrote:
    EtherCAT może osiągąc czasy poniżej 1 us do pozycjonowanie czy synchronizacji osi.


    Jeśli brałeś wiedzę z tego artykułu:
    https://automatykab2b.pl/prezentacje/41131-ethercat-przyszlosc-sieci-przemyslowych

    Nie do końca tutaj chodzi o pozycjonowanie czy synchronizację osi (w sumie to jakiej osi?) Nadal jednak wysyłanie protokołu trochę trwa i niestety 1us to na pewno nie czas reakcji na sterowanie poprzez taki protokół.
  • #117
    Wojciech.
    Level 35  
    Czas cyklu nie zależy od tego co jest na wejściu czy są jakieś krańcówki, czy enkoder, to załatwia specjalny moduł itd. Czas cyklu zależy przed wszystkim od tego jaki duży jest program, jak jest napisany oraz jak został zdeterminowany przez programistę.

    Nie wiem ile wynosi w takim raspberry pi bo nigdy nie testowałem, ale na pewno schodzi poniżej 1ms. Wystarcza praktycznie do 99% projektów.
  • #118
    elektryku5
    Level 39  
    nightwatch wrote:
    no ale Linux, na Raspberry Pi to taki powolny pecet, on w ogóle daje jakieś gwarantowane czasy reakcji na GPIO?


    Normalne PLC mają czas cyklu rzędu kilku ms jak program już jest rozbudowany w stosunku do możliwości sterownika i czas ten też nie musi być stały.
    Do liczenia impulsów czy generowaniu PWM są specjalne moduły lub kompaktowe PLC z wbudowanymi szybkimi licznikami, co nie zmienia faktu, że czas cyklu nadal liczy się w ms.
  • #119
    atom1477
    Level 43  
    _lazor_ wrote:
    Nie do końca tutaj chodzi o pozycjonowanie czy synchronizację osi (w sumie to jakiej osi?)

    Osi maszyny.
    Np. gdy posuw jest realizowany dwoma napędami po dwóch stronach.
    Oba muszą iść równo żeby nie przekosić.
    Jak jeden się zablokuje to trzeba szybko zatrzymywać drugi.
  • #120
    Janusz_kk
    Level 34  
    Ale tego i tak plc nie robi w sposób bezpośredni, robią to np:
    1.synchronizator i 2 falowniki albo
    2.Specjalny falownik na 2 silniki albo
    3.Specjalne napędy z wejściem synchronizacji.

    PLC zadaje tylko prędkość i kierunek a sprzężenie silnika z enkoderem jest na falowniku/napędzie.