Arduino, Raspberry PI w przemyśle

khoam wrote:

Co to za konkretnie "skomplikowane procedury" w Arduino, "które zajmują sporo zasobów procesora"?

A to tu wymieniać? Wszystkie podstawowe są bardziej skomplikowane niż mogły by być, ze względu na ich uniwersalność:
https://www.arduino.cc/reference/en/

khoam wrote:

atom1477 wrote:

Równie dobrze można napisać że Arduino nie pozwala zająć się na problemami, bo ma własne rozwiązania na problemy, a jednocześnie utrudnia samodzielne budowanie rozwiązywań.

Tezę kolega już postawił, a teraz poproszę o dowód.

To nie jest coś co się dowodzi, bo ja pisałem o tendencji. Czyli czymś co występuje najczęściej, ale niekoniecznie zawsze. Innymi słowy można by podać 1 przypadek gdzie "moja" teza się nie sprawdzi, a Ty byś tego użył do obalenia "mojej" tezy. Tyle że ja wcale takiej tezy nie stawiałem. Ja nie mówię że nie ma wyjątków. Mówię tylko że najczęściej występuje inny sposób postępowania, ale oczywiście czasami i pojawiają się te "wyjątki".
Ale do rzeczy. Chodzi mi o uniwersalność i mnogość przykładów z użycia tych uniwersalnych i gotowych procedur. Bo przecież o to właśnie chodzi w Arduino. Bez tego zostało by tylko czyste C (czy tam C++) + skonfigurowany kompilator.
Można mówić że język/platforma/środowisko Arduino nie ma tej wady. Może i nie, ale Arduino to coś więcej. To strona/reklama/marketing. Na stronie i w oficjalnych materiałach używane są uniwersalne zunifikowane rozwiązania. I właśnie to jest to co utrudnia. Może i da się zrobić niskopoziomowy dostęp, ale takie podejście nie jest promowane/reklamowane. I to jest właśnie to utrudnianie o którym pisałem.

khoam wrote:

W Arduino nie występują żadne ograniczenia dostępu do zasobów sprzętowych, wręcz przeciwnie.

Na pewno nie występuje żadne powiększenie dostępności, co tu chyba sugerujesz. Fizycznie może nie występować nic, albo może występować jedynie zmniejszenie. Arduino jako unifikator, siłą rzeczy może wprowadzać jedynie zmniejszenie dostępności.
Ewentualnie pewne rzeczy może symulować (np. wyjścia PWM czy wyjścia do serwomechanizmów) i wtedy to wygląda jako powiększenie dostępności. Tyle że takie coś odbędzie się znacznym zwiększeniem zużycia zasobów procesora. Więc to "powiększenie dostępności" nie dzieje się za darmo, nie jest to więc żadna cudowna cecha Arduino. Takie coś było np. już w BASCOMie, i używanie tego było raczej odradzane przez bardziej zaawansowanych programistów.

khoam wrote:

atom1477 wrote:

Użycie Arduino w takim wypadku ogranicza się tylko do użycia środowiska oraz szablonu projektu (czy jak to tam zwał).

Nic podobnego. Kolejny mit.

Na to już odpowiedziałem wcześniej: pisałem o konkretnych przypadkach użycia, a nie o wszystkich możliwościach używania Arduino. Wiadomo że jakiś spec/nerd wyciśnie z Arduino więcej, ale nie takie przypadki tam opisywałem.

Wojciech. wrote:

atom1477 wrote:

lecz o "aurze" jakie ono nad sobą roztacza.

Zgadzam się bo zazwyczaj arduino dedykowane jest dla ludzi którzy nie mają dużo wspólnego z elektroniką. To że zawodowcy wykorzystują w 100% peryferia arduino to inna sprawa.

Właśnie.
Sam kiedyś używałem BASCOMa. Ale praktycznie nie używałem jego funkcji, tylko wszystko konfigurowałem na rejestrach i dawałem dużo wstawek assemblerowych. Czy to miało sens to inna sprawa. Ważne że tak robiłem i jak to inni ludzie określali (albo jak ja sam to określałem). A określałem to jednoznacznie: "Ja wcale nie używam BASCOMa, używam tylko kompilatora BASCOM do kompilowania kodu w assemblerze".
Tak samo można zrobić w Arduino. I może nawet to jest oficjalna ścieżka uznawana przez twórców Arduino za poprawną.
Ale jednak nie promują takiej ścieżki, a na pewno nie promują i nie używają jej zwykli użytkownicy Arduino. Gdyby taki kod wstawić na forum Arduino, to by powiedzieli że w ogóle nie jest tam użyte Arduino. Albo że jest użyte, ale nie tak jak trzeba, i po co było go używać jak kod jest po prostu napisany tak jakby był w czystym C.

atom1477 wrote:

Ale jakoś przed Arduino na innych platformach te wady nie wychodziły, a tu nagle wychodzą.
Nie przeanalizowałeś tego zjawiska merytorycznie, ale to mi zarzucasz brak metaforyczności.
Może i nie podałem merytorycznych argumentów na temat środowiska, ale i nie o tym był mój wpis. Ja nie pisałem o środowisku, lecz o "aurze" jakie ono nad sobą roztacza. Więc tylko w tej sprawie mogę podawać argumenty.

Programowałem i programuję na wielu, różnych platformach. W wypadku Arduino jedno mogę z całą pewnością stwierdzić - aura niemerytorycznego "hejtu" jaka otacza Arduino jest bardzo duża, czego dowodzi ten wątek. Chyba już wiem, dlaczego.

Dodano po 58 [sekundy]:

Wojciech. wrote:

Zgadzam się bo zazwyczaj arduino dedykowane jest dla ludzi którzy nie mają dużo wspólnego z elektroniką.

Tak, ta platforma jest dedykowana przede wszystkim dla wędkarzy

Zapewniam że to się nie wzięło z niczego.
Wchodzimy na oficjalną stronę Arduino, i widzimy uniwersalne funkcje/biblioteki.
Może i są inne, dedykowane pod konkretne procesory i przez to optymalniejsze. Ale na stronie widzimy te uniwersalne.
Hejt na użytkowników nie powstał sam. On jest dopiero wtórny, i powstał właśnie z pierwotnego podejścia Arduino do programowania (że ma być uniwersalnie).

khoam. wrote:

Tak, ta platforma jest dedykowana przede wszystkim dla wędkarzy

Sam jesteś bardziej zaawansowanym programistą więc tego nie widzisz. Ale tak, właśnie ta platforma jest dedykowana dla wszystkich tylko nie dla elektroników. Może nie przede wszystkim dla wędkarzy, ale na pewno można powiedzieć że "przede wszystkim dla wędkarzy i innych grup innych niż elektronicy".
Dopiero ta wersja z tego wątku, czyli ta przemysłowa, ma już jakieś zadatki na profesjonalny sprzęt.

atom1477 wrote:

właśnie ta platforma jest dedykowana dla wszystkich tylko nie dla elektroników. Może nie przede wszystkim dla wędkarzy, ale na pewno można powiedzieć że "przede wszystkim dla wędkarzy i innych grup innych niż elektronicy".
Dopiero ta wersja z tego wątku, czyli ta przemysłowa, ma już jakieś zadatki na profesjonalny sprzęt.

khoam wrote:

I to jest zasadnicza wada tematu tego wątku i pierwszego postu. Nierozróżnianie platformy programistycznej od sprzętowej.

Możemy tak się kręcić w kółko przez następne 500+ postów

Jeśli chodzi o urządzenia amatorskie w warunkach przemysłowych to byście się koledzy zdziwili, co czasem w przemyśle pracuje.






Takie coś na praktykach zawodowych naprawiałem.

Jakiś uC i płytka uniwersalna z kabelkami.


Chodziło to latami bez większych problemów, mimo braku ochrony przed czymkolwiek.
Tylko styki testowe trzeba było wymieniać i podregulować docisk.

Jeszcze kaseta z automatyki.



Od drugiej strony.



Na bank była kryta kalafonią rozpuszczoną w denaturacie.
Przy lutowaniu charakterystyczny zapach i też bardzo ładnie się lutowało.

Normalna spora fabryka (kilkaset osób) sprzętu elektrycznego i elektronicznego.
To na co dzień obsługiwało produkcję.

Jakieś tanie mikrokomputery pamiętam, że obsługiwały system wizyjny kontroli jakości. Suwnica sobie jeździła nad płytkami z kamerą i szukała braków.

khoam wrote:

W samym Arduino Core są tylko takie możliwości ustawienia pinu, jakie są dostępne również dla innych platform sprzętowych, nie tylko dla STM32. Chodzi o zachowanie możliwości przenoszenia kodu źródłowego pomiędzy platformami sprzętowymi - taki jest jeden z głównych imperatywów Arduino.

I dokładnie to jest zaleta a jednocześnie wada arduino. Biblioteki arduino z definicji nie wykorzystują w pełni możliwości hardware. To jest wystarczający powód by wiele projektów nawet nie startować na arduino.

_lazor_ wrote:

Biblioteki arduino z definicji nie wykorzystują w pełni możliwości hardware.

Biblioteki Arduino, które są zaprojektowane dla konkretnej platformy sprzętowej, wykorzystują jak najbardziej możliwości hardware. Koronnym przykładem są np. biblioteki do obsługi WiFi czy BLE dla ESP32. One też są "arduinowe". Mylisz Arduino Core (warstwa abstrakcyjna, niezależna od użytego MCU) z bibliotekami wykorzystującymi Arduino HAL. Arduino w żaden sposób nie narzuca, ani też nie ogranicza możliwości wykorzystania zasobów sprzętowych danego hardware, ale zwykle zasoby te są obsługiwane przez dedykowane biblioteki dla tego hardware. Dla niektórych bibliotek np. do obsługi WiFi, rekomendowane jest określone API (podstawowe klasy i metody klas), ale nie oznacza to, że konkretna implementacja takiej biblioteki nie może zostać poszerzona w celu optymalnego wykorzystania danego hardware.

_lazor_ wrote:

To jest wystarczający powód by wiele projektów nawet nie startować na arduino.

To właśnie dedykowane arduinowe biblioteki dla konkretnego sprzętu w znaczący sposób ułatwiają "start" na danej platformie sprzętowej. Dla tych, co nie chcą z nich korzystać zawsze jest opcja pisania wszystkiego od zera.

khoam wrote:

Tak, ta platforma jest dedykowana przede wszystkim dla wędkarzy

Zapewne tak bo społeczność arduino zazwyczaj dużo z wykształceniem elektronicznych nie ma wspólnego

"Moi drodzy, po co kłótnie, po co wasze swary głupie. Wnet i tak zginiemy w zupie!" - Jan Brzechwa "Na straganie"

Pisał ktoś z Was w B4X? Można w tym pisać na iOS, Android, PC w JAVA czyli PC i Raspberry PI i na Arduino...
Z nowymi B4XPages mogę napisać jedną aplikację na platformy PC, RPi, Android lub iOS i bezproblemowo od razu uruchomić je na reszcie tych platform. Na prawie niezmienionym kodzie. Zmiany są minimalne.
Inną sprawą jest B4R dla Arduino.
Tu zasoby są ograniczone jeśli chodzi o płytki AVR, ale otwiera się mnóstwo możliwości jeśli chodzi o ESPxx.

B4R (czyli BasicForArduino) polega na Arduino. Słabo wypada oprogramowywanie AVR poprzez taki język, ale oprogramowanie ESP w tym języku to poezja i przyjemność.

Można więc znając lepiej jeden język oprogramować sobie ESP32 i do tego napisać apki na PC, RPi, Andoid i iOS za jednym zamachem....i mieć gotowy system do jego obsługi..lub obsługi prymitywnego urządzenia wykonawczego.
Do oprogramowania AVR wolę Bascom bo to też Basic, a mogę wykorzystać uC jak chcę.

Co do jakości IDE Arduino ... Zainstalowałem Arduino Plugin w AtmelStudio7 i nie mogę się go nachwalić To o niebo lepsze IDE/rozwiązanie.

Inna sprawą jest hardware i moje zdanie jest następujące:
Na powszechnych klonach można sobie napisać soft i testować oprogramowanie, dlatego nazywają się "płytki prototypowe", ale do końcowego urządzenia, jeśli chcemy tam wstawić Arduino na dedykowanych pinach, to jakoś z głową. Nie te najtańsze z zimnymi lutami...

Uważam, że po zakończeniu prototypowania powinno się zaprojektować "uczciwą" płytkę.

Podsumowując -> Arduino (pod wzgledem oprogramowania) dla ośmiobitowców to niepotrzebne obciążenie uC natomiast sprawdza się w maszynach mających większe zasoby.
Pod względem hardware`owym...to są płytki z minimalnym setup`em. Potrzebują reszty zabezpieczeń dla długotrwałego bezawaryjnego działania.

Z innych rozwiązań PLC wykorzystujących framework Arduino:
https://www.controllino.biz/downloads/#datasheets
Całość oprogramowania dedykowanego dla tych sterowników jest OpenSource.
https://github.com/CONTROLLINO-PLC/CONTROLLINO_Library




Ciekawym rozwiązaniem są sterowniki PLC z obsługą przez WiFi oraz BT (dzięki zastosowanym układom ESP32), na bazie oprogramowania wykorzystującego framework Arduino:
https://www.industrialshields.com/industrial-plc-wifi-based-on-arduino-automation-solutions

khoam wrote:

Ciekawym rozwiązaniem są sterowniki PLC z obsługą przez WiFi oraz BT (dzięki zastosowanym układom ESP32), na bazie oprogramowania wykorzystującego framework Arduino:

Trochę śmieszne że nazywają to PLC jak nawet nie można tego programować w żadnym języku zgodnym z normą IEC-61131.

@Wojciech. Uwagi to jedno, a zbędne i złośliwe komentarze to drugie. Jeszcze jedna uwaga w podobnym tonie i poleci ostrzeżenie.

W tym wątku jest ciekawa dyskusja na temat programowania PLC w C/C++:
https://www.elektroda.pl/rtvforum/topic3426977.html

Do samego pisania sekwencji c/c++ raczej to nie za dobry pomysł jak jest LD, ST czy SFC. Ale tak jak ktoś tam napisał, że do różnego rodzaju połączeń ze światem IT.

Największym pytaniem jest to, czy te produkty arduinopodobne w ogóle są implementowane w przemysł? Czy tylko ktoś sobie to wyprodukował i nikt tego nie używa?

Ja tam nie widzę nic złośliwego. To jest opinia użytkownika, a nawet we wpisach moderacyjnych często widać powoływanie się na punkt regulaminu, że zdanie innych użytkowników należy uszanować.
No to proszę tutaj uszanować tamtą opinię (która nawet (w mojej opinii ) nie jest naznaczona żadną ironią czy złośliwością).

nightwatch wrote:

Co do Arduino - byłem (i jestem nadal) pod wrażeniem łatwości pisania programów pod to, szybkości i łatwości testowania.

Piszesz tak bo jesteś doświadczonym programistą.
Oglądając programy (czy choćby filmiki z działania) do urządzeń z Arduino robione przez pozostałe 99% użytkowników Arduino, odnosi się wrażenie że to w ogóle nie było testowane.

nightwatch wrote:

Nie trzeba studiować opasłych manuali żeby coś zdziałać.

Pytanie jak to rozumieć. Coś czyli uruchomić gotowca, jak rozumiem.
Nie będę negował że tak jest, i że nawet się to sprawdza w przypadku powiedzmy 95% urządzeń (że faktycznie działa (pomijając problemy z brakiem testów), mimo małego wkładu własnego).
Trzeba jednak zauważyć że to wynika z dostępności do łopatologicznych tutorali i filmików na YouTube.
Bo jakby nie było, coś jednak trzeba w tym Arduino zrobić. Znać składnię języka, itp. Ja tych rzeczy nie wiem (nie na pamięć), i musiał bym dopiero szukać czy oglądać. A z tego co pamiętam ogólnie, to wyglądało to po prostu jak C.
Stąd moja opinia, że to nie jest zaleta Arduino, lecz wynik dostępności materiałów na YouTube. Tak samo by było z C jakby był dobry tutorial do C z dostępnymi bibliotekami do różnych rzeczy.
Zresztą w sumie Arduino to właśnie takie C, z bibliotekami (między innymi, bo wiem że nie tylko)

atom1477 wrote:

Zresztą w sumie Arduino to właśnie takie C

Nie, to jest C++ i jak to w wypadku samego C++ jest, ten język dla wielu programistów embedded jest "złem wcielonym".

pawelr98 wrote:

Jeśli chodzi o urządzenia amatorskie w warunkach przemysłowych to byście się koledzy zdziwili, co czasem w przemyśle pracuje.

To właśnie jest prawdziwa mechatronika , czyli wajchy, dźwignie i sprężyny w obudowie z elektroniką.

nightwatch wrote:

Wiesz co mnie urzekło? NIE MA DEBUGGERA.

Chyba będę musiał wyrzucić swoje ESP-Prog oraz J-Link Fakt, że aż tak często z nich nie korzystam, ale co jakiś czas zdarza się, właśnie z programami wykorzystującymi Arduino HAL.
A bardziej poważnie, to co napisałeś jest prawdą, ale tylko w odniesieniu do Arduino IDE (opcjonalne) oraz w odniesieniu do tzw. płytek Arduino z AVR (też opcjonalne ).

Krzysztof Kamienski wrote:

pawelr98 wrote:

Jeśli chodzi o urządzenia amatorskie w warunkach przemysłowych to byście się koledzy zdziwili, co czasem w przemyśle pracuje.

To właśnie jest prawdziwa mechatronika , czyli wajchy, dźwignie i sprężyny w obudowie z elektroniką.

Chodziło mi o elektronikę.

Tą ewidentnie robił jakiś amator.
Że jeszcze ścieżki zakręcające pod kątem prostym użył to już widać, że raczej brak doświadczenia.

Zresztą bardzo ciekawe rozwiązanie, robić generator NE555 gdzie kondensator jest przełączany przekaźnikami.
Tak jakby nie można było użyć CD4051, tranzystorów mosfet albo czegokolwiek innego. Gdybym tam siedział na praktykach dłużej i daliby na materiały to bym zmodernizował tą kasetę, tak żeby już nie trzeba było nic tam wymieniać.

Te przekaźniki trzeba było wymieniać i po wielu naprawach ścieżki się pourywały w niektórych miejscach bo ktoś pożałował podstawek.

@pawelr98 Pare lat temu trafiła mi się do naprawy maszyna - gilotyna do papieru Polar Mohr, w której pamięć wymiaru zrealizowana była na lampach E88CC i E80F, w technice zapisu sygnałów mcz. na taśmie magnetycznej. Szkoda, że fotek nie mam. Niestety ścieżka magnetyczna na listwie optycznej z podziałką była tak wytarta, głowice także, że nawet naprawa tej elektroniki lampowej nie przyniosła by skutku. Widział ktoś z Kolegow lampowe układy w maszynach przemysłowych, tokarkach, frezarkach czy tym podobne ?

nightwatch wrote:

część bibliotek jest gówniana, komunikacja jest zrobiona często na pętlach i delayach, brak obsługi błędów, no ale posuwasz się naprzód bo cały czas masz działający program do którego dokładasz kolejne elementy i na bieżąco weryfikujesz.

Ciężko nazwać to posuwaniem się do przodu, jak w kodzie jest coraz więcej niedoróbek.
W sumie to jedna z głównych zasad dobrego (i w sumie szybkiego) programowania, żeby błędy usuwać u źródła i zaraz po zauważeniu, a nie propagować je dalej bo "póki co jakoś to działa".
Może się udać napisać kod w taki sposób, ale tylko do czasu aż coś go w końcu rozsypie. I wtedy naprawianie będzie bardzo trudne.

nightwatch wrote:

Nie róbmy tu tragedii, masz 2 kilobajty pamięci i program który siłą rzeczy nie może być zbyt skomplikowany bo się po prostu nie zmieści, więc nie powinno być problemów typu 'tyle kodu nakleciłem że nie mam pojęcia co, gdzie i po co jest'.

Raczej jest problem, bo użytkownicy się przyzwyczajają do gotowców (które są przewymiarowane) i się im to nie mieści w tym 2kB.

nightwatch wrote:

Nie róbmy tu tragedii, masz 2 kilobajty pamięci i

atom1477 wrote:

i się im to nie mieści w tym 2kB.

Arduino to nie tylko atmega328p

Arduino lub RPI w przemyśle? Pytanie po co i do czego? Spójrzcie ile jest firm, które produkują urządzenia automatyki przemysłowej (sterowniki, panele, komputery, roboty, przemienniki częstotliwości, napędy itd.) w określonych standardach i normach. Firmy te ciągle rozbudowują swoją ofertę produktową tak aby sterowanie całym procesem było możliwie zrealizowane za pomocą ich komponentów. I co myślicie, że ten potężny rynek firm, które budują maszyny skręci w stronę Arduino? bo ktoś nie nauczy się tak prostych języków programowania jak LD, ST, FBD, SFC?
W praktyce integratorskiej w maszynie, gdzie jest więcej jak 3 producentów urządzeń automatyki przemysłowej (mówię tu o sterownikach, panelach, modułach pomiarowych itd.) zaczyna się robić burdel. Wobec tego najlepszym rozwiązaniem jest stosowanie jak najwięcej elementów od tego samego producenta.
Chińczycy uwielbiają maścić jakieś swoje sterowniki maszyn na prostych mikrokontrolerach. Często musiałem coś przerobić w takich wynalazkach lub integrować je z wdrażanym systemem sterowania. Integracja polegała na "odrąbaniu siekierą" tego co jest w szafie maszynki i wstawieniu sterownika PLC lub modułu wejść/wyjść.
Uważam, że Arduino nie zastąpi klasycznego sterownika PLC w maszynach przemysłowych.

W ciężkim przemyśle nie, ale w zastosowaniach rzemieślniczych, gdzie właściciel sam sobie coś tam "ulepi" - jak najbardziej. Np. okazyjnie kupi maszynę starszej generacji lub z uszkodzonym sterownikiem i zrobi swoje sterowanie.