Nastawnik/Pulpit do komputera - Wskazówki i gotowe projekty.

[Gajosowy]

Obecnie mój pulpit od 2 lat stoi i czeka na lepsze czasy. Ostatnio się zabrałem za nowy koncept do niego. Początkowe założenie polegało na głównym kontrolerze na arduino MEGA, a kontroler hebli (EN57) miał być na Arduino nano, natomiast komunikacje między Arduinami ubzdurałem sobie na UART. Działało to nawet spoko. Jednak były sytuacje, że jedno arduino chwyciło jakiegoś laga i odpaliło się za późno i drugie się wysypywało bo nie było komunikacji. Pewnie dało by się to oskryptować jakoś.

Na razie zmieniłem koncepcje i robię prawie tak jak mówisz tylko zamiast arduino jako slave będę korzystał z MCP23017. Planuje zrobić magistrale I2C i podpinać do niej pozostały sprzęt przez podobne moduły lub inne arduina

[Hirek]

I2C ma tą zalete ze zawsze pierwszy bajt danych jest pierwszym w wysylanej ramce. Po UART to jak zgubi jeden to lubią się przesunąć. Magistrala daje u mnie radę, 20Hz odświeżanie pulpitu (0.05 sekundy), przy inicjalizacji kontrolera machnąłem sprawdzanie czy pozostałe są dostępne, jeśli nie to poprostu w pętli ich nie interpretuje. Dodatkowo dzisiaj doszły kombinacje przycisków na pulpicie, do wymuszenia resetu (bez zaglądania pod pulpit), tryb kalibracji mierników NN i WN oraz tryb testowy (ktory miga wszystkimi lampkami i pracuje wskaznikami po calym zakresie). Dziala to fajnie, bo nikt nie wcisnie kombinacji przypadkiem (np wlaczony hebel rezerwy, jakis odblok i przekaznik jenoczesnie) i tylko osoby z dokumentacją będą wiedziały o takiej funkcjonalności. W razie gdyby jakis kontroler mial sie zawiesic to w loopie program nie oczekuje na na przykład 3 bajty danych z innego kontrolera tylko najzwyczajniej sprawdza czy sa 3 i jesli nie to poprostu pomija odczyt i czysci bufor na wypadek gdyby kolejny odczyt mialbyc pomyslny i zeby danych nie pomieszac. No ogólnie ja jestem zadowolony z tego jak to działa, problemem tam jest jedynie nastawnik oraz wytarte krzywki ktore raz stykaja a raz nie przez co czasem niektóre pozycje wypadają. Pulpit męczony maszyną przez 5h nie zerwał komunikacji z testerem.

[Gajosowy]

"Dodatkowo dzisiaj doszły kombinacje przycisków na pulpicie, do wymuszenia resetu" - Techniki podpatrzone u pewnego producenta z nad Dunajca ;)

A tak na poważnie, to dzięki na wsparcie pomysłu jaki obrałem. Skoro u ciebie się sprawdza, to tym bardziej w to idę.

Swoją drogą, może ktoś ma lub może "zorganizować" nastawnik jazdy z EN57, jedyna rzecz której mi brakuje...

[Maciej_ZG]

Ja mam pulpit zbudowany na bazie 1xRaspberry PI + 6xArduino Nano. Raspberry komunikuje się z PC po UART, a z Arduinami po I2C. Jest osobny wątek do komunikacji z PC i do komunikacji z Arduinami. Jak na razie to rozwiązanie się sprawdza.
Soft na Raspberry leży na Githubie : https://github.com/maciejszymanskizg/custom_desktop_control/tree/main

Wsady do Arduino też mogę udostępnić w tym repo jakby ktoś był zainteresowany.

[Hirek]

A tak na poważnie, to dzięki na wsparcie pomysłu jaki obrałem. Skoro u ciebie się sprawdza, to tym bardziej w to idę.

Tak naprawdę to má to na celu tylko reinicjalizacje kontrolera przed rozpoczęciem symulacji coby nagle nie stwierdził że bajty się nie zgadzają. Na samym początku pętli jest wywołanie funkcji diag() która sprawdza ifami czy jakakolwiek kombinacja została wcisnieta (wywołanie funkcji wstawione w każde miejsce gdzie kod może się blokować w oczekiwaniu na dane itp). Reset oparty jest o uruchamianie watchdog timera i zaraz za nim zrobienie nieskończonej pętli - kontroler sam sobie robi wtedy reset i zaraz na samym starcie setupa się wyłącza.

[Pitek]

Ja ciągle proszę o naprawienie sterowania kranami dla Pokeysa... może jestem już jedyny, który jeszcze na nim ma zbudowany pulpit, ale skoro nadal jest obslugiwany, to fajnie gdyby działało w pełni.

[Hirek]

A co tam nie działa? Zerknę w kod i najwyżej na mm się zgadamy w celu testów ewentualnego rozwiązania.

[Joozeph]

Widzę, że coraz więcej osób stosuje rozwiązania zwiększające modułowość pulpitów. Ja również obecnie testuję podłączenie mikrokontrolerów po i2c, co przy zabudowie całej kabiny jest sporym uproszczeniem w projektowaniu instalacji. U mnie funkcjonuje mega 2560 jako master, na panele z przełącznikami zastosowałem ekspandery. Nastawnik i radio podłączone na osobnych megaśkach. Po testach wstępnych stwierdzam, że baudrate 115200 daje radę i nie obserwuję żadnych przesunięć czy zgubionych części ramki. Generalnie śmiga to dobrze. Z małym zastrzeżeniem:
Urządzenia które wymagają więcej operacji w kodzie, tym samym zajmują więcej pamięci, a są nimi na przykład silniki krokowe - najlepiej podpinać do mastera a nie po i2c. Chyba że zastosować rozwiązanie, które odciąży magistralę które zaproponował @Hirek.

[Pitek]

A co tam nie działa? Zerknę w kod i najwyżej na mm się zgadamy w celu testów ewentualnego rozwiązania.

Mój wpis z 29.07.2023 na Bugtrackerze: "Kran hamulca fv4a nie reaguje podczas użytkowania Pokeysa. Po przestawieniu na pulpicie fizycznie dźwigni kranu fV4a, nie dzieje się w MaSzynie nic poza delikatnym syczeniem powietrza (czyli jakaś informacja o przestawieniu kranu hamulca jest przez symulator odbierana). Przy wersji 21.04 kran jeszcze działa, potem z każdą nowszą wersją kran przestaje współpracować. Próbowałem różnych wpisów kalibracyjnych, różnych wersji exe, nie ma rozwiązania na problem.
W programie Pokeys widać zmiany napięcia podczas ruchu kranem, więc po stronie “kabelkowej” jest wszystko ok, sygnał przez kontroler jest odbierany."

[Hirek]

Urządzenia które wymagają więcej operacji w kodzie, tym samym zajmują więcej pamięci, a są nimi na przykład silniki krokowe - najlepiej podpinać do mastera a nie po i2c.

Sterowniki DRV8834, które wykorzystałem przy budowie pulpitu w Jabłonowie są sterowane dwoma sygnałami - STEP i DIR. Dla świętego spokoju są one podłączone do slavea na i2c (megaśka sterująca manometrami i miernikami WN/NN). Mimo, że masz tam 3 kontrolery + wkrótce 4 będzie jeszcze falownik do prędkościomierza to 20Hz odswiezanie pulpitu przy 115200b/s daje rade. Z takimi ustawieniami udało się przejechać całe wrzosy od Wolicy do Sandomierza :)

[Joozeph]

Cześć, mam problem z komunikacją po UART. Otóż:
Załączam program i bezpośrednio po tym - komunikacja odbywa się płynnie. Zaś po chwili zaczyna stopniowo zwalniać.
Po wznowieniu komunikacji (czyt. Resecie Arduino) - sytuacja się powtarza.
Teraz kilka spraw technicznych:
1. Używam Arduino Mega Pro (ch340)
2. Zmiana prędkości i częstotliwości nie przyniosła żadnych zmian. Czy baudrate 9600, czy 115200 - bez znaczenia.
3. Zauważyłem, że opóźnienie występuje zawsze w taki sam sposób. Czyli: Odpalam MaSzynę, czas reakcji MaSzyny na pulpit fizyczny jest normalny. Wraz z upływem czasu - jest coraz wolniejszy. Po około minucie działania programu, opóźnienia w komunikacji wynoszą około 5-6 sekund.
4. Programami Arduino odchudziłem możliwie jak najbardziej. Wywaliłem obsługę Haslera, zakomentowałem zbędne biblioteki. Bez rezultatu.
5. Komputer nie jest tosterem. Mocna jednostka, radzi sobie doskonale z MaSzyną.
6. Bardzo podobny pulpit chodził wcześniej na zwykłej wersji Mega 2560. Problem który opisuję również wtedy występował, kiedy nie miałem podłączonego falownika. Wystarczyło wywalić sterowanie falownikiem z kodu głównego lub po prostu podłączyć rzeczony falownik i problem znikał. Teraz - nie mam już co odłączać i wywalać. Nawet ciężkie dla kodu krokowce zakonwntowałem żeby zobaczyć czy to przyniesie skutek. Nic…
7. Na tym samym kodzie działał poprzedni pulpit - nie miałem takiego problemu, za wyjątkiem odpiętego Haslera. Opis wyżej.

Pomóżcie proszę bo mi już ręce opadły. Próbowałem chyba wszystkich znanych mi rozwiązań.

[Hirek]

Konwertery CH340 mają to do siebie właśnie, że lubią gubić komunikację (powodować po pewnym czasie bad sync). Przerabiałem to u siebie - wymieniłem kontrolery na takie z konwerterem opartym o ATmege16u2, który radzi sobie z komunikacją bez problemu (baudrate 115200 i odswiezanie 50ms nie wysypalo sie przez 3 godziny ani razu). Podobno z CH340 tez jest to kwestia poszukania odpowiednich sterowników, ale to bardziej taka legenda moim zdaniem. Jeśli masz juz mege jaką masz, to spróbuj się wyposażyć w jakiś konwerter  nawet oparty o FTDI (są znacznie tańsze niż oryginalne megaśki, a zarazem powinny rozwiązać twój problem i działać stabilnie). Konwerter wystarczy jeden na pulpit przy kontrolerze "matce", który bezpośrednio odpowiada za komunikację z PC, wpięty na piny TX0 i RX0 (które są przypisane do "Serial" w frameworku arduino.

tldr: kazde ch340 jest inne - jedne dziala lepiej, drugie gorzej, ale kazde sie nie nadaje do utrzymywania stabilnej komunikacji przez dłuższy czas

[Anonim17PL]

Przepraszam z góry że (znowu) napiszę na forum, ale winne jest temu nie wytrzymanie moje.

Zacznę od końca:

Urządzenia które wymagają więcej operacji w kodzie, tym samym zajmują więcej pamięci, a są nimi na przykład silniki krokowe - najlepiej podpinać do mastera a nie po i2c.

Nie potrafię sobie wyobrazić, jak bardzo musi być zaśmiecony kod sterowania silnikami krokowymi, żeby zapchać pamięć takiego uC jak ATMega 2560 (8kB).

Ja mam pulpit zbudowany na bazie 1xRaspberry PI + 6xArduino Nano. Raspberry komunikuje się z PC po UART, a z Arduinami po I2C.

Zbyt przewymiarowany. Malinę widziałbym w znacznie bardziej wymagających scenariuszach, jak symulacja samego pulpitu, czy komunikacja przez LAN.
Ale jak działa i zbytnio się nie grzeje, to pół biedy.

Na razie zmieniłem koncepcje i robię prawie tak jak mówisz tylko zamiast arduino jako slave będę korzystał z MCP23017.

Pora nauczyć się czegoś innego już parchate 8-bitowe ATMega.
Ja nie piszę że się nie nada, ale nakładka w postaci Arduino nie nadaje się do czegokolwiek innego niż proste mruganie diodą czy sterowanie silnikiem krokowym. W szczególności brak dostepu do timerów, przerwań.
Z kolei za czyste AVR C trzeba od firmy-dziad nazywającej się "Microchip" zapłacić. I jeszcze dostanie się kompilator na bazie GCC, nie wspominając że optymalizacje też są płatne...

Mogę polecić uC od STMicroelectronics, do wyboru do koloru. Może i płytki dev są droższe (niż tłuczone masowo u Chińczyka klony Arduino), ale możliwości to niebo a ziemia. Ceny za chipy w hurcie porównywalne.

"Dodatkowo dzisiaj doszły kombinacje przycisków na pulpicie, do wymuszenia resetu"

Watchdog powinnen rowiązać problem, ale to niestety też nie ma tego Arduino... Czysty AVR ma, ale nie pamiętam już jak biedny jest on.

Techniki podpatrzone u pewnego producenta z nad Dunajca ;)

Zdrowaś Maryjo dla tego producenta. No ale, rynek makiet nie lepszy...

Po UART to jak zgubi jeden to lubią się przesunąć.

Ramka danych. Jeżeli zaczyna się jakąś sekwencją danych, to do "synchronizacji" wystarczy odpowiednie parsowanie.

co budowniczowie uważają o korzystaniu z kilku kontrolerów arduino zamiast ekspanderów?

Jak jest zrobione zgodnie ze sztuką, to nie ma przeciwskazań.

wprowadza swego rodzaju wielowątkowość pulpitu

realizuje niezależnie od odświeżania danych na serial porcie.

Przerwania. Słyszał Pan o czymś takim? Na bibliotece Arduino to nie możliwe, ale na czystym AVR C jak najbardziej.

Jeśli ktoś poszukuje rozwiązania do sterowania haslerem to załączam tutaj link do falownika.

Układ fajny, ale ja już ci pisałem że za drogo i że nieco przewymiarowany.
Ale zdjęcie okropne, cała płytka w kalafonii i opryskane nią obudowy tranzystorów.

A teraz coś od siebie:

Przede wszystkim róbcie z głową. Nie używajcie sleep(), delay(), broń boże od tego. Prędkość transmisji 115200 bps nie ma znaczącego wpływu na dzisiejsze uC, a mniejsza prędkość to wolniej otrzymuje dane.
No i porzućcie 30-letni parch AVR. Jest tyle lepszych współczesnych mikrokontrolerów, trzeba nadążać z duchem czasu. Rodzina STM32, ESP, NXP. A jak ktoś się odważy to może wyklepie coś z FPGA ;)

W poście zawarłem wskazówki, które wytłuściłem.

Powodzenia.

[Hirek]

Dobra, lecimy:

Watchdog powinnen rowiązać problem, ale to niestety też nie ma tego Arduino...

Arduino obsluguje watchdogi (stosuje u siebie w pulpicie celem wymuszania resetu za pomocą kombinacji)

Kod: [Zaznacz]

#include <avr/wdt.h>

void setup()
{
  wdt_disable(); // Disable the watchdog after reset
}

void resetMain()
{
    // reset
    // Reset the Arduino using the watchdog timer
    wdt_enable(WDTO_15MS); // Wlacza WDT
    while (1); // triggeruje WDT
  }
}
Pamiętajmy, że Arduino to framework do pracy na kontrolerach. W arduino IDE bez problemu możemy uzyskać dostęp do libek avr, które mamy na wyciągnięcie ręki w np microchip studio.

brak dostepu do timerów, przerwań.

Tak jak wyżej, w arduino IDE bez problemu masz dostęp do libek avr (kod pisany w arduino ide poprostu ma na początku dodawane #include <Arduino.h>, które idzie pozniej przez ten sam kompilator z jakiego korzysta przykładowo Microchip Studio

Przerwania. Słyszał Pan o czymś takim? Na bibliotece Arduino to nie możliwe, ale na czystym AVR C jak najbardziej.

Słyszał, ale nie chce obciążać głównego kontrolera wszystkim czym sie tylko da, szczególnie, że z woltomierzami i amperomierzami potrafiły być cyrki w postaci spadków napięć (stąd decyzja o przeniesieniu mierników na osobny kontroler). Nastawnik to ze względu na liczbę wykorzystywanych pinów jest na osobnym kontrolerze.

No i porzućcie 30-letni parch AVR.

Mamy platformy STM, ESP czy inne, jednak na razie moim zdaniem arduino jest na tyle udokumentowane i znane wszystkim, że bazowanie na platformie AVR to po prostu ułatwienie sobie pracy. Jak ktoś będzie odważny, to zrobi sobie swój projekt na innej platformie.

Układ fajny, ale ja już ci pisałem że za drogo i że nieco przewymiarowany.

Nie ja ustalałem cene.

Ogólnie to tak:
kazdy pulpit bedzie korzystal z innych rozwiazan. Wydaje mi sie ze ten wątek powinien służyć dzieleniu się wiedzą, a nie krytyką, że "hurr durr uzywasz starego avr". Kazdy wybiera to co uwaza za stosowne i spełniające oczekiwania.

[Anonim17PL]

Arduino obsluguje watchdogi

W arduino IDE bez problemu możemy uzyskać dostęp do libek avr

Oczywiście że się da, tylko jakim kosztem? Dosyć dużym bałaganem, bo wiele rejestrów jest też używanych przez framework.

Tak jak wyżej, w arduino IDE bez problemu masz dostęp do libek avr

To ja tak rzucę; na dzień dobry jeden Timer używany przez millis(), no i zabrane przerwania.
Albo Arduino i bujanie się z tym co ma, albo czysty C i ustawianie rejestrów.

Słyszał, ale nie chce obciążać głównego kontrolera wszystkim czym sie tylko da,

Nie twierdzę że trzeba wszystko stawiać na jednym mikrokontrolerze, ale takie problemy są spowodowane funkcjami blokującymi.

Mamy platformy STM, ESP czy inne, jednak na razie moim zdaniem arduino jest na tyle udokumentowane i znane wszystkim, że bazowanie na platformie AVR to po prostu ułatwienie sobie pracy.

Naprawdę? Dokumentacja STM32 dla jednego modelu liczy łącznie strony w tysiącach. Datasheet ma kilkaset, ale Reference Manual potrafi mieć grubo ponad tysiąc.
Jeżeli jednak chodzi o dobre poradniki, to nawet w języku polskim jest ich trochę.

Nie ja ustalałem cene.

Rozumiem.

Wydaje mi sie ze ten wątek powinien służyć dzieleniu się wiedzą, a nie krytyką, że "hurr durr uzywasz starego avr".

Ja podzieliłem się wiedzą, że nie warto męczyć starca. I jestem w stanie dzielić się nią dalej, w tym ws. implementacji na inne platformy niż AVR.

[Hirek]

Oczywiście że się da, tylko jakim kosztem? Dosyć dużym bałaganem, bo wiele rejestrów jest też używanych przez framework.

Na rejestry jakie sa wykorzystywane zawsze sobie mozesz zerknac, jednak takie rzeczy jak wlasnie watchdog dzialaja na arduino bez problemu :)

[jakubg1]

Każdy robi tak jak lubi. Jak działa to "nie ruszaj k....". Jak tak bardzo nienawidzisz Arduino to sobie zrób pulpit z STM32, i wtedy zapraszamy do podzielenia się swoimi doświadczeniami.

Ludzie robią to w wolnym czasie i nikt im za to nie płaci. To nie jest konkurs na najpiękniejszą implementację czy kod. Wiele osób ma mniejsze obeznanie w mikrokontrolerach i pisaniu kodu i należy im się szacun, że w ogóle umieją doprowadzić pulpity do działania.