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 18 Sep 2020 10:17 14502 188
SterControl
  • SterControl
  • #122
    pawel1148
    Level 23  
    Mam czasem wrażenie, że arduino na elektrodzie jest dla części tym, czym jest dla części katolików ideologia LGBT/Gender/diabeł.
    Nie widzę sensu nad rozważaniem arduino przy programowaniu urządzeń produkowanych seryjnie. Podobnie nie widze sensu rozważania zastępstwa urządzeń o cenie 200x wyzszej od arduino płytką arduino, bo często jest to fizycznie niemożliwe.

    Czasem są jednak proste układy sterowania, które nie wymagają zbyt dużo od sterownika i na dobrą sprawę dało by się je zastąpić paroma innymi elementami automatyki. Zabezpieczenia układów najczęściej i tak odbywają się poza władzą sterownika. Np. Miałem kilka zleceń na czasowe załączanie silników wentylatorów wyciągowych. Zrobiłem to na Logo! Aczkolwiek myśle, że spokojnie, gdyby potrzebna byłaby pilna podmiana logo, arduino dobrze sprawdziło by się w tym miejscu, na czas dostawy sterownika. Co prawda mam i Logo na podmianę, ale czasem różne rzeczy sie psują w maszynach i czasem taka dorazna naprawa w prosty sposób jest na wage złota.

    Płytki Arduino nie są raczej trwałym rozwiązaniem, aczkolwiek czasem można coś na szybko zmontować. W zasadzie to raz użyłem arduino(nie w przemyśle, a bardziej w formie zabawki). Nie bardzo było sie czego uczyć. Bo jak ktoś cokolwiek programował w c/c++ to ogarnie to po zobaczeniu kodu wyszukanego w necie. Urządzenie miało być proste do złożenia przez nieelektronika i miało działac kilka minut kręcąc na żądanie servomechanizmem...

    Co do Raspberry to też raz użyłem, do wyświetlania webserwerów z Siemens Logo! w sterowni. Okazało się, że nie było to najbardziej wydajne rozwiązanie, ale było tanio i nie było zwykłym komputerem.

    A jak tak chcecie promować korzystanie z C, to przydałoby mi się, byście polecili jakąś literature dla elektronika(bez pokazywani którą nóżkę diody podpiąć do masy) związaną z programowaniem ESP32. Jedną książke mam, ale opiera się na Arduino IDE w 90% i na korzystaniu z gotowych rozwiązań.
  • #123
    User removed account
    Level 1  
  • #124
    atom1477
    Level 43  
    Tu mówimy o zastosowaniach w przemyśle, a nie tylko o PLC.
    Jeżeli sterowanie synchronizacją osi nie robi się na PLC, to nic nie szkodzi.
    W przemyśle stosuje się nie tylko PLC, ale i układy wykonawcze jak siłowniki, falowniki, czy też czujniki.
    RPi (czy Arduino, czy zwykły uC) nie musi wiec od razu zastępować PLC.
    Może zastąpić sterownik silnika (falownik, driver BLDC), albo jakiś czujnik (jeżeli czujnik jest bardziej skomplikowany, i ma wysyłać dane po RS485 albo Ethernecie).
    I w takim wypadku jego szybkość reakcji ma znaczenie.
    Sam robiłem różne czujniki oraz sterowniki, i zawsze potem słyszałem pytanie dlaczego nie użyłem PLC.
    No i teraz już wiem. Bo ja wcale nie robiłem czegoś co zastępowało PLC. Robiłem te synchronizatory osi, czujniki, itp.

    Takie układy jest sens robić. Np. na RPi można zrobić jakiś system wykrywania obrazu. To nie będzie zamiast PLC. To będzie czujnik.
    Który dopiero potem można połączyć do PLC (choć raczej ktoś zaimplementuje odpowiednik PLC już w tym samym RPi).
  • #125
    Janusz_kk
    Level 34  
    atom1477 wrote:
    Jak by nie było ta synchronizację trzeba gdzieś podać.
    Idzie ona kablem po jakimś interfejsie np. Ethernet, i o ten kabel i interfejs mi chodziło.

    Po co? synchronizacja jest tylko potrzebna falownikom i synchronizatorowi jeśli jest żeby kroki pomiędzy silnikami się nie gubiły, i nigdzie więcej.
  • SterControl
  • #127
    Wojciech.
    Level 35  
    _lazor_ wrote:
    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ół.


    Synchronizacje osi w obrabiarkach wieloosiowych czy w całych liniach produkcyjnych. Takie rzeczy odbywają się chociaż w PLC. Czas reakcji zależy przede wszystkim od wielkości ramki i ilości urządzęń.
    Przykład.
    https://www.youtube.com/watch?v=Z4OJqI4gels

    https://www.motioncontroltips.com/is-ethercat-on-the-rise-for-motion-applications/

    "In terms of real numbers, an EtherCAT network can process roughly 1,000 I/Os in about 30 µsec, or approximately 100 axes in 125 µsec."

    Dodano po 3 [minuty]:

    Janusz_kk wrote:
    Po co? synchronizacja jest tylko potrzebna falownikom i synchronizatorowi jeśli jest żeby kroki pomiędzy silnikami się nie gubiły, i nigdzie więcej.


    A skąd dwa falowniki niepodłączone do wspólnej sieci mają to wiedzieć?
  • #128
    Janusz_kk
    Level 34  
    Wojciech. wrote:

    A skąd dwa falowniki niepodłączone do wspólnej sieci mają to wiedzieć?


    Bo to chodzi o synchronizację takich osi

    atom1477 wrote:
    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.
  • #129
    atom1477
    Level 43  
    Mi chodziło o przesył danych z enkoderów.
    Nawet jak to nie idzie do PLC, to gdzieś idzie.
    Do falowników właśnie. Albo jednego dwusilnikowego, jeżeli taki falownik ma taką opcję (sam fakt że jest na dwa silniki od razu od tym nie świadczy).
    O ile ktoś akurat używa falowników i siników ACIM, a nie serw.
    Ale mniejsza o rodzaj silnika. Ważne ze sygnał z enkoderów musi dojść do sterownika (którym nie będzie PLC, ale coś nim jednak będzie).
    Interfejs enkoderów to może być właśnie Ethernet.
    W takim zastosowaniu enkodery muszą być absolutne. Indeksowane się nie nadają, bo nie da się wyzerować wskazań po pierwszym uruchomieniu (nie będzie wiadomo jak jechać oboma silnikami, skoro po starcie pozycja enkoderów będzie niewyzerowana). Więc klasyczne wejścia enkoderowe AB/Z odpadają.
    To musi być interfejs danych. Są różne. RS485, SPI (przesyłany raczej jako LDVS po skrętce) albo właśnie Ethernet.
    W każdym jednak przypadku ważne jest małe opóźnienie przesyłu (oraz stałość tego opóźnienia).
    Odbiornik/sterownik musi więc mieć szybki czas reakcji.
    Można tego nie nazywać "PLC", ale coś tam jednak jest. I ma działać szybko.

    Tu chyba wszyscy stosują duże uproszczenie że jedyne co się robi w przemyśle to programuje sterowniki PLC.
    A tak nie jest.
    Sam robię wiele rzeczy, i logika sterująca (odpowiednik modułu "PLC") to tylko wisienka na torcie.
    Cała reszta to własne czujniki i sterowniki wykonawcze.
    Własne czujniki: np. enkodery właśnie.
    Np. magnetyczne przelotowe. Nietypowe, trudne do kupienia. Więc opłaca się robić.
    Linkowe. Też nietypowe.
    Optyczne o dużej długości (kilka m).
    Optyczne zczytujące położenie wałów, na których nie można nic umieszczać (odczyt podobny do działania myszki optycznej).

    Albo układy wykonawcze:
    Sterowanie silnikami hydraulicznymi.
    Sterowanie położeniem kątowym przy pomocy serwomechanizmów modelarskich.

    Takie wszystkie rzeczy które trudno kupić, albo nie da się kupić wcale.
    I to wszystko do przemysłu, a nie dla siebie dla zabawy.
    Więc się opłaca robić, i robi się na uC. Bo raczej żaden PLC nie ma wejścia kamery, albo nie zmieści się w całości w łożyskowaniu wału.
  • #130
    Janusz_kk
    Level 34  
    No plc to nie jest bo nie ma do tego najczęściej dostępu ( w sensie programu), jest stały program do obsługi enkoderów i silników i koniec, więc jest to specjalizowany sterownik ale nie typu PLC. Co do serw to spotkałem się ze specjalnym sterownikiem którym sterowało PLC a który robił sterowanie do napędów silników i miał opcje bazowania dla wyrównania osi.
  • #131
    aut0matyk

    Level 16  
    Postanowiłem i ja wrzucić kamyczek do ogródka.

    Jest sterownik, na który można pisać programy w C, assemblerze, Basic-u oraz w Arduino:
    https://www.e-tronix.eu/3,sterownik-plc-programowalny-su-1-5.html

    Ale można ten sam sterownik (pod względem sprzętowym) oprogramować w jednym z języków znanych ze sterowników PLC, w środowisku CPDev:
    https://www.e-tronix.eu/14,pakiet-cpdev-i-codesys.html

    Jedno jest pewne, czasy się zmieniają...
  • #132
    elektryku5
    Level 39  
    Na plus wyświetlacz, ale w tej cenie można mieć podstawowy PLC Siemensa, już nawet nie mówiąc o wynalazkach typu Fatek.
  • #133
    elektrro3
    Level 5  
    Czy to prawda, że CPU w Raspberry Pi startuje za pomocą systemu ThreadX należącego do Microsoftu?
  • #134
    tzok
    Moderator of Cars
    Co to znaczy, że "CPU startuje za pomocą systemu"? ThreadX to RTOS, czyli system operacyjny dedykowany do zastosowań, gdzie krytyczny jest czas wykonywania programów.

    https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=255314&p=1558243&hilit=ThreadX

    Czyli i tak i nie - ThreadX jako takiego dla RPI nie ma, ale jego zamknięta wersja jest zaszyta w GPU używanym w RPI.
  • #135
    _lazor_
    Moderator of Designing
    Rasberry pj ma 3 etapy startupu:
    1. Startuje gpu. To on budzi do życia rdzenie arm
    2 i 3 startupy już na prockach arm, tutaj raczej standardowe rzeczy się dzieję (konfiguracja niektórych peryferium itp.)

    Potem się już odpala program np linuks. Co tam robi linuks to już nie wiem, nie lubuję się w systemach operacyjnych.
  • #136
    User removed account
    Level 1  
  • #137
    khoam
    Level 41  
    agent.007 wrote:
    Nie jest problemem sam ThreadX ale to, że ten produkt zależy od zamkniętego binarnego kodu (binary blob), który do konca nie wiadomo co robi.

    Kod źródłowy jest otwarty: Link
  • #138
    User removed account
    Level 1  
  • #139
    gaskoin
    Level 38  
    Wszystko ma swoje miejsce. Taki RΠ może nie jest jakimś super wyborem jeśli chodzi o sterowanie procesami, ale jeśli wymagana jest bardziej skomplikowana interakcja z człowiekiem to jest to prościej zrobić na malinie. Obsługa monitora dotykowego, drukarki, audio, wszystko masz wbudowane w system operacyjny.

    Nie wiem czy można powiedzieć, że to przemysł, ale jakiś czas temu stawialiśmy firmę zajmującą się czymś w rodzaju outsourcingu dla restauracji. Zakres pracy obejmował wszystko - konfigurację nowych klientów, menu, rabatów, obsługę kuchni, logistykę itd. Użyliśmy malinę do wyświetlania zamówień w kuchni. Każdy widział na monitorku co ma przygotować - kucharz co ma gotować i czy już gotowe, pakowacz co ma zapakować, pod jaką firmę, z jakim paragonem i gdzie to wysłać. Nie wyobrażam sobie tego pisać embedded ze względu na bardzo skomplikowany interfejs użytkownika. Takie rozwiązanie też jest bardzo tanie, wliczając koszt specjalnej obudowy itd. Jak padnie malina - kosz i następna. Jak padnie Ci urządzenie szyte na miarę a akurat nie masz zapasów no to trzeba kogoś wysłać i na miejscu niech bada, a biznes stoi :)
  • #140
    User removed account
    Level 1  
  • #141
    gaskoin
    Level 38  
    Czepiasz się :) Dobrze wiesz o co mi chodzi
  • #142
    User removed account
    Level 1  
  • #143
    Marek_Skalski
    VIP Meritorious for electroda.pl
    Pakiet występujący dawniej pod nazwą ThreadX nazywa się teraz Azure RTOS ThreadX i jest już port na niektóre STM32.
    Pierwszy pakiet zostanie udostępniony dla STM32H7 w 21Q1. Kolejne będą L4 i F4 (21Q2), F7, G4, L5 (21Q3), G0, WB i WL (21Q4). Pozostałe linie nie będą wspierane, ponieważ nie są w żaden sposób rozwijane.

    Po uzupełnieniu o dodatkowe moduły jest to jeden z podstawowych pakietów dla CubeMX i zastępuje dotychczas używanego Free RTOS i kilka innych pakietów warstw pośrednich, np. USB (z szerszą ofertą dla Device i Host), LwIP, FatFs. Udostępnia też bezpieczne połączenia z chmurą Microsoftu.
    W pakiecie Azure RTOS (z przyjazną, bezpłatną licencją, również do zastosowań komercyjnych) znajdują się:
    - Azure RTOS Thread X (zastępuje Free RTOS)
    - Azure RTOS FileX (zastępuje FatFs)
    - Azure RTOS NetX/NetX Duo (zastępuje LwIP)
    - Azure RTOS USBX (zastępuje pakiet USB)
    Pakiet GUIX nie jest dostępny w CubeMX, ponieważ jest postrzegany jako mniej funkcjonalny wobec TouchGFX, ale użytkownik może sam zainstalować GUIX i korzystać z niego w oparciu o bezpłatną licencję.

    Dotychczas używany Free RTOS będzie jeszcze dostępny jako osobny moduł, ale nie będzie już rozwijany, podobnie jak pakiety USB, LwIP, FatFs, itp. Jeżeli ktoś planuje nowy projekt, to warto się zastanowić nad tym co będzie dla niego lepsze.
  • #144
    User removed account
    Level 1  
  • #145
    Marek_Skalski
    VIP Meritorious for electroda.pl
    ST-Link V3 został zaprojektowany z myślą o pracy z systemami operacyjnymi, więc debugger powinien umożliwić grzebanie w systemie. Z drugiej strony mocno rozwijają też Monitor, aby podglądać stan aplikacji real-time, bez zatrzymywania programu, czyli na wypadek kiedy debugger nie zadziała.
    Integracja, z tego zrozumiałem i widziałem, jest na nieco głębszym poziomie. Obecni na spotkaniu ludzie z innych firm stwierdzili, że to będzie kosztowna zmiana. Z jednej strony system jest łatwiejszy w użyciu (konfiguracja, drivery sprzętowe), ale z drugiej strony warstwa pośrednia (middleware) oraz nadrzędna wymagają przebudowy. Reakcje były raczej sceptyczne, ponieważ STM32H7 to nadal (standalone) embedded, a nie IoT, który musi się ciągle łączyć z chmurą.
    Na plus odebrano wymianę pakietów oprogramowania dotyczących obsługi USB.
  • #146
    User removed account
    Level 1  
  • #147
    farmazon3000
    Level 15  
    dondu wrote:
    Nadal oczywiście uważam, że studenci informatyki i elektroniki powinni programować mikrokontrolery bez wykorzystania uproszczonych środowisk, ale już mechatronik i im podobni, mogą


    A to niby czemu? Co to mechatronicy upośledzeni czy co?
  • #149
    pawelr98
    Level 39  
    dondu wrote:
    farmazon3000 wrote:
    A to niby czemu? Co to mechatronicy upośledzeni czy co?

    Każdy lekarz jest lekarzem, ale żaden lekarz nie jest specjalistą w każdej specjalizacji.
    Dlatego też powstały np. sterowniki PLC.


    Do tego kto zagwarantuje, że urządzenie będzie działało niezawodnie ?

    Im bardziej rozbudowane są urządzenia i większe są potrzeby do oprogramowania to trzeba by się znać na zbyt dużej liczbie rzeczy. "Przeciętny" programista może temu nie podołać.
  • #150
    dondu
    Moderator on vacation ...
    pawelr98 wrote:
    Do tego kto zagwarantuje, że urządzenie będzie działało niezawodnie ?

    Im bardziej rozbudowane są urządzenia i większe są potrzeby do oprogramowania to trzeba by się znać na zbyt dużej liczbie rzeczy. "Przeciętny" programista może temu nie podołać.

    Tak jak wśród lekarzy, także wśród mechatroników i programistów są wyjątki.