Arduino, Raspberry PI w przemyśle

Radzio M. napisał:

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.

khoam napisał:

Czyli uważasz, że układy zbudowane w oparciu o mikroprocesory nie zastąpią "klasycznych" sterowników PLC

A to sterowniki PLC nie są oparte o mikroprocesory? Nic nie wiem na ten temat, ale zawsze myślałem że jest to po prostu komputer dedykowany do sterowania.

Trudno oczekiwać żeby popularne mikrokontrolery tak znienacka wyeliminowały z rynku ugruntowane na nim firmy i technologie, samo to się chyba nie stanie. Ale jeśli jedyną 'przewagą' producentów PLC jest ich własne oprogramowanie to się bardzo mogą zdziwić - 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. Jeszcze parę lat temu np sterowniki do maszyn CNC były technologią którą należało kupić od odpowiedniego producenta (najlepiej wraz z całą maszyną) - teraz można sobie przebierać w darmowym, otwartym oprogramowaniu i hardware.

nightwatch napisał:

A to sterowniki PLC nie są oparte o mikroprocesory?

Nie jestem autorem tej opinii.

Dodano po 16 [minuty]:

nightwatch napisał:

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/

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.

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. Przecież każdy mikrokontroler obsługuje przerwania czy DMA, Arduino rownież, więc nic nie stało na przeszkodzie żeby zrobić to lepiej, a na pewno przeszkodą nie było oprogramowanie Arduino bo te funkcje są częścią standardowych API.

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?

nightwatch napisał:

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.

khoam napisał:

nightwatch napisał:

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.

Temat dyskusji to PLC vs kodowanie na mikrokontroler więc w ogóle nie wiem czy powinniśmy rozmawiać o wyciskaniu wszystkiego co sprzęt daje i liczeniu cykli procesora. 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ć.
A co do Arduino - to też swojego rodzaju HAL, tylko taki co trochę się rozrasta w niekontrolowany sposób bo już np zaczyna obsługiwać procesory do których w ogóle nie był przeznaczony. No ale zawsze masz możliwość pominięcia HALa i pisania prosto do rejestrów czy co tam akurat producent przewidział. Ale sam fakt że jakiś producent podejmuje decyzję zeby oprócz swojej własnej platformy zrobić support dla Arduino, nawet kosztem wydajności czy rezygnacji z niektórych bajerów, sugeruje że może nie są idiotami i ma to jakiś sens.. Chociażby dla tych co im się nie chce zgłębiać opasłych manuali, HALi itp

PS _lazor_ masz rację, Arduino (te na AVR) nie mają DMA

Z avr-ów tylko AtXmegi mają DMA, niestety

@khoam

khoam napisał:

Taki projekt już istnieje: https://www.openplcproject.com/

Tylko że arduino pełni tam jedynie rolę karty I/O po modbusie. Cały program wykonuje się na komputerze (runtime).

też się zdziwiłem że tak naprawdę potrzebują komputera PC żeby zrobić na nim PLC. Lekka przesada chyba

Wojciech. napisał:

Cały program wykonuje się na komputerze (runtime).

Raczej na RPI lub czymś podobnym.

nightwatch napisał:

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 napisał:

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.

Wojciech. napisał:

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?

kaczodp napisał:

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.

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ć.

elektryku5 napisał:

Co do PLC, był kiedyś taki projekt na AVR i PIC https://cq.cx/ladder.pl

Zdarzało mi się z tego korzystać, ale najbardziej kuluje tutaj cały interfejs użytkownika. Zaletą jest, że prawie nic nie waży

elektryku5 napisał:

Co do PLC, był kiedyś taki projekt na AVR i PIC https://cq.cx/ladder.pl

I to podejście wydaje się mieć o wiele większy sens niż wrzucanie raspberry pi z linuxem

nightwatch napisał:

I to podejście wydaje się mieć o wiele większy sens niż wrzucanie raspberry pi z linuxem

Tylko że na takim codesys są większe możliwości, dużo większe.

no ale Linux, na Raspberry Pi to taki powolny pecet, on w ogóle daje jakieś gwarantowane czasy reakcji na GPIO?

nightwatch napisał:

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ę.

no tak, razem z siecią to będzie czas reakcji rzedu paru milisekund, więc nada się tylko do wolno zmiennych procesów. Jak chcesz reagować szybciej to musisz postawić tam drugi PLC, tylko już bez linuxa.

@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.

No ja się na tym nie znam. Współpracownicy co robią maszyny używają PLC do sterowania tymi maszynami, zwykle proste rzeczy typu obsługa czujników krańcowych, zliczanie obrotów czy innych impulsów, sterowanie silnikami, siłownikami, zaworami itp, czasem jakiś prosty wyświetlacz alfanumeryczny. No i tam trzeba mieć krótki i stały czas reakcji bo od tego zależy dokładność maszyny - jak byś miał milisekundę czy dwie poślizgu co jakiś czas to była by to bardzo kiepska maszyna.

Wojciech. napisał:

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ół.

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.

nightwatch napisał:

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.

_lazor_ napisał:

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.

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.