Arduino, Raspberry PI w przemyśle

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.

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/

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.

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

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.

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

@khoam

khoam wrote:

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

Wojciech. wrote:

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

Raczej na RPI lub czymś podobnym.

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.

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?

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.

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 wrote:

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

nightwatch wrote:

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.

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

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

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

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

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

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.