Pytanie o strukturę komunikacyjną dla różnych interfejsów
Pytanie o strukturę komunikacyjną dla różnych interfejsów
Witam.
Mam pytanie jaką polecalibyście strukturę programu
który musi komunikować się z różnymi urządzeniami (magistrala GPIB, ethernet, USB-1-wire)
Tak, aby urządzenia GPIB oraz ethernetowe pracowały synchronicznie Czujniki na 1-wire zbierają tylko parametry środowiskowe więc pracują tylko 2-10 razy w ciągu całego cyklu pomiarowego.
W chwili obecnej pracuję nad strukturą producent-konsument
w której urządzenia GPIB odsyłają wyniki pomiarów jeżeli w klastrze danych jest opcja Read.
Synchronizacja wewnątrz magistrali GPIB odbywa się w następujący sposób (sam proces pomiaru, pomijam konfigurację przyrządów):
- wyślij rozkaz trigger (Write - bez odpowiedzi do programu głównego),
- odczytaj wartości z kolejnych mierników (Read - po skończeniu gromadzenia danych odeślij do programu głównego).
Chciałbym już na tym etapie prac mieć na tyle uniwersalną strukturę, żebym nie musiał jej zmieniać dokładając komunikację z pozostałymi urządzeniami.
Częstotliwość pomiarów nie jest duża - pomiar co ok 10s (najczęściej) ale zależy mi, żeby osiągnąć możliwie najmniejsze przesunięcie pomiarów w trakcje jednej akwizycji.
Zastanawiałem się nad dwoma strukturami (pętle while połączone kolejkami lub powiadomieniami):
1: GUI / sterowanie / komunikacja GPIB / komunikacja ethernet / komunikacja 1-wire / archiwizacja do pliku TDMS
2: GUI / sterowanie / komunikacja GPIB / komunikacja ethernet / komunikacja 1-wire / zebranie danych / archiwizacja do pliku TDMS.
Aby uzyskać synchroniczny punkt startu można chyba wykorzystać kolejkę z klastrem zawierającym rozkazy dla wszystkich urządzeń, ale
czy pierwszy węzeł dequeue nie usunie danych z kolejki? czy jedno enqueue wyśle równolegle dane do trzech węzłów dequeue znajdujących się w trzech pętlach (właśnie to sprawdzam)?
Ewentualnie czy przy tak zawrotnej prędkości akwizycji danych nie wystarczą powiadomienia?
W takim przypadku pętla "zbieranie danych" (ver 2) może czekać na dane ze wszystkich trzech lub czterech pętli zanim przystąpi do przetwarzania danych w jednego sampla.
Pozdrawiam
Zuk
Mam pytanie jaką polecalibyście strukturę programu
który musi komunikować się z różnymi urządzeniami (magistrala GPIB, ethernet, USB-1-wire)
Tak, aby urządzenia GPIB oraz ethernetowe pracowały synchronicznie Czujniki na 1-wire zbierają tylko parametry środowiskowe więc pracują tylko 2-10 razy w ciągu całego cyklu pomiarowego.
W chwili obecnej pracuję nad strukturą producent-konsument
w której urządzenia GPIB odsyłają wyniki pomiarów jeżeli w klastrze danych jest opcja Read.
Synchronizacja wewnątrz magistrali GPIB odbywa się w następujący sposób (sam proces pomiaru, pomijam konfigurację przyrządów):
- wyślij rozkaz trigger (Write - bez odpowiedzi do programu głównego),
- odczytaj wartości z kolejnych mierników (Read - po skończeniu gromadzenia danych odeślij do programu głównego).
Chciałbym już na tym etapie prac mieć na tyle uniwersalną strukturę, żebym nie musiał jej zmieniać dokładając komunikację z pozostałymi urządzeniami.
Częstotliwość pomiarów nie jest duża - pomiar co ok 10s (najczęściej) ale zależy mi, żeby osiągnąć możliwie najmniejsze przesunięcie pomiarów w trakcje jednej akwizycji.
Zastanawiałem się nad dwoma strukturami (pętle while połączone kolejkami lub powiadomieniami):
1: GUI / sterowanie / komunikacja GPIB / komunikacja ethernet / komunikacja 1-wire / archiwizacja do pliku TDMS
2: GUI / sterowanie / komunikacja GPIB / komunikacja ethernet / komunikacja 1-wire / zebranie danych / archiwizacja do pliku TDMS.
Aby uzyskać synchroniczny punkt startu można chyba wykorzystać kolejkę z klastrem zawierającym rozkazy dla wszystkich urządzeń, ale
czy pierwszy węzeł dequeue nie usunie danych z kolejki? czy jedno enqueue wyśle równolegle dane do trzech węzłów dequeue znajdujących się w trzech pętlach (właśnie to sprawdzam)?
Ewentualnie czy przy tak zawrotnej prędkości akwizycji danych nie wystarczą powiadomienia?
W takim przypadku pętla "zbieranie danych" (ver 2) może czekać na dane ze wszystkich trzech lub czterech pętli zanim przystąpi do przetwarzania danych w jednego sampla.
Pozdrawiam
Zuk
Pytanie o strukturę komunikacyjną dla różnych interfejsów
Nie wchodząc w szczegóły - do komunikacji 1:N polecam implementację User Event. Każda z Event Structure będzie czekała na zadeklarowane zdarzenia. Gdy ono nastąpi zostanie wykonany równolegle kod dla każdego równoległego wątku, czyli w twoim przypadku urządzenia. Może to być np. "Stop" albo "Self Test", po którym każdy zgłosi status do wątku głównego.
Kolejki służą do przysyłania z wielu źródeł w jedno miejsce (N:1). A więc jeden kod obsługuje dane nadchodzące z wielu miejsc.
Kolejki służą do przysyłania z wielu źródeł w jedno miejsce (N:1). A więc jeden kod obsługuje dane nadchodzące z wielu miejsc.
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Dzięki za odpowiedź.
Nie bawiłem się jeszcze zdarzeniami poza obsługą GUI.
Jakoś mało jest wtedy dla mnie zrozumiały kod.
Ale Ty proponujesz niezależne pętle wile ze strukturami event
wywołanie pomiaru wiąże się z programowym wygenerowaniem zdarzenia za pomocą
property node właściwość value (signaling). Dobrze rozumię?
Czy wtedy da się np zrobić tak, żeby po przyjściu rozkazu "pomiar" wartość tunelu wejściowego timeout
z -1 zmieniła się na jakąś inną (np 10000) i struktury event same dbałyby o cykliczne wykonanie pomiaru (np 10s)?
Czy lepiej, żeby to pętla główna bała o synchronizację działania pętli komunikacyjnych?
Pozdrawiam
Zuk
Nie bawiłem się jeszcze zdarzeniami poza obsługą GUI.
Jakoś mało jest wtedy dla mnie zrozumiały kod.
Ale Ty proponujesz niezależne pętle wile ze strukturami event
wywołanie pomiaru wiąże się z programowym wygenerowaniem zdarzenia za pomocą
property node właściwość value (signaling). Dobrze rozumię?
Czy wtedy da się np zrobić tak, żeby po przyjściu rozkazu "pomiar" wartość tunelu wejściowego timeout
z -1 zmieniła się na jakąś inną (np 10000) i struktury event same dbałyby o cykliczne wykonanie pomiaru (np 10s)?
Czy lepiej, żeby to pętla główna bała o synchronizację działania pętli komunikacyjnych?
Pozdrawiam
Zuk
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Nie do końca miałem to na myśli. Chodzi mi o programowe generowanie zdarzeń wewnątrz aplikacji. Bez sprzężenia z GUI. Poczytaj ostatni pkt tutajMK_Zuk pisze:wywołanie pomiaru wiąże się z programowym wygenerowaniem zdarzenia za pomocą
property node właściwość value (signaling). Dobrze rozumię?
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Czyli muszę to zrobić za pomocą zdarzeń rejestrowanych dynamicznie ponieważ wtedy
nie potrzebuję kontrolek GUI.
W międzyczasie dotarłem do tej samej strony, która zalinkowałeś. Dzięki.
Pozdrawiam
Zuk
nie potrzebuję kontrolek GUI.
W międzyczasie dotarłem do tej samej strony, która zalinkowałeś. Dzięki.
Pozdrawiam
Zuk
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Jeśli nie chcesz używać wielu Event Structure, proponuje zrobić coś na zasadzie załączonego kodu. Dane do Slaveów wysyłasz za pomocą kolejek (ew. notifierów), a odbierasz za pomocą dynamicznych zdarzeń.
P.S. Wie ktoś dlaczego po zrobieniu snippeta kasuje mi zdefiniowane eventy?- Załączniki
-
- multithread.vi
- v2010
- (10.63 KiB) Pobrany 369 razy
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Dzięki za zainteresowanie i podpowiedzi.
Wygląda na to, że skorzystam dzięki sugestii Kolegi TMa.
Uproszczona (testowa) wersja rozwiązania jest w załączniku.
W moim przykładzie niekiedy zdarzenie konfiguracja nie jest wykonywane przez "urządzenie 1"
z czego może to wynikać? Mniej więcej raz na 3-4 razy jest "ignorowane".
Ze zdarzeniem pomiar nie zauważyłem takiego buga.
Pozdrawiam
Zuk
Wygląda na to, że skorzystam dzięki sugestii Kolegi TMa.
Uproszczona (testowa) wersja rozwiązania jest w załączniku.
W moim przykładzie niekiedy zdarzenie konfiguracja nie jest wykonywane przez "urządzenie 1"
z czego może to wynikać? Mniej więcej raz na 3-4 razy jest "ignorowane".
Ze zdarzeniem pomiar nie zauważyłem takiego buga.
Pozdrawiam
Zuk
- Załączniki
-
- events test 2.vi
- (29.77 KiB) Pobrany 388 razy
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
A więc:
1. Wszelkie pobudzenia/akcje pochodzące z GUI obsłuż w Event Structure (dot. także stopu).
2. Stop też może być osobnym zdarzeniem dynamicznym dla wszystkich urządzeń.
3. Pomiary z urządzeń można wrzucać do kolejek. Zazwyczaj pętla przetwarzania danych pomiarowych działa asynchronicznie do akwizycji.
1. Wszelkie pobudzenia/akcje pochodzące z GUI obsłuż w Event Structure (dot. także stopu).
2. Stop też może być osobnym zdarzeniem dynamicznym dla wszystkich urządzeń.
3. Pomiary z urządzeń można wrzucać do kolejek. Zazwyczaj pętla przetwarzania danych pomiarowych działa asynchronicznie do akwizycji.
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
A jaka jest różnica w obsłudze zdarzenia w przypadku zdarzenia statycznego i dynamicznego?TMa pisze:2. Stop też może być osobnym zdarzeniem dynamicznym dla wszystkich urządzeń.
Wewnątrz pętli event raczej różnicy nie będzie.
ciekawy pomysł. Co jednak w przypadku zaniku napięcia? cała seria pomiarowa traci się?TMa pisze:3. Pomiary z urządzeń można wrzucać do kolejek. Zazwyczaj pętla przetwarzania danych pomiarowych działa asynchronicznie do akwizycji.
Mam jeszcze pytanie odnośnie pliku VI który wrzuciłem w poprzednim poście.
W przypadku akcji konfiguracja zdarza się, że niekiedy zdarzenie jest pomijane.
Zdarza się to przy nie wszystkich uruchomieniach programu.
Raz uruchamiam i wszystko jest ok innym razem co 3-4 zdarzenie gubi się,
kilka razy zdarzyło się, że 3 zdarzenia pod rząd zostały pominięte.
Pozdrawiam
Zuk
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Czy ktoś ma podobne spostrzeżenia?
Z moich testów dynamicznych zdarzeń wynika, że est to bardzo zawodny mechanizm.
Zdarzenia często są pomijane.
Chyba jednak wrócę do kolejek.
Pozdrawiam
Zuk
Z moich testów dynamicznych zdarzeń wynika, że est to bardzo zawodny mechanizm.
Zdarzenia często są pomijane.
Chyba jednak wrócę do kolejek.
Pozdrawiam
Zuk
-
- Posty: 641
- Rejestracja: 31 gru 2010 01:36
- Wersja środowiska: LabVIEW 2017
- Lokalizacja: Katowice
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Możesz rozwinąć? W jakiej sytuacji są pomijane?MK_Zuk pisze: Z moich testów dynamicznych zdarzeń wynika, że est to bardzo zawodny mechanizm.
Zdarzenia często są pomijane.
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
No właśnie nie wiem w jakiej sytuacji.
W chwili obecnej mam wrażenie, że losowo.
Przy jednym uruchomieniu programu wszystko działa a po "restarcie" programu
np za pierwszym razem działa później niektóre zdarzenia są pomijane.
Dotyczy to tylko zdarzeń dynamicznych.
Jak będę w domu wieczorem to dorzucę aktualny test.
Kilka postów wyżej wrzuciłem plik testowy w którym także akcja konfiguracja zawsze działa
natomiast akcja pomiar nie.
Pozdrawiam
Zuk
W chwili obecnej mam wrażenie, że losowo.
Przy jednym uruchomieniu programu wszystko działa a po "restarcie" programu
np za pierwszym razem działa później niektóre zdarzenia są pomijane.
Dotyczy to tylko zdarzeń dynamicznych.
Jak będę w domu wieczorem to dorzucę aktualny test.
Kilka postów wyżej wrzuciłem plik testowy w którym także akcja konfiguracja zawsze działa
natomiast akcja pomiar nie.
Pozdrawiam
Zuk
-
- Posty: 641
- Rejestracja: 31 gru 2010 01:36
- Wersja środowiska: LabVIEW 2017
- Lokalizacja: Katowice
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Nieprawidłowo używasz rejestracji zdarzeń. User event trzeba rejestrować oddzielnie dla każdej pętli, inaczej dzieją się takie cuda, o których mówisz: Jako bonus: jaka jest idea kodu, który zaznaczyłem w zielonym kółku?MK_Zuk pisze: Kilka postów wyżej wrzuciłem plik testowy w którym także akcja konfiguracja zawsze działa
natomiast akcja pomiar nie.
Re: Pytanie o strukturę komunikacyjną dla różnych interfejsów
Dzięki PiDi.
Teraz działa jak należy.
A ten "bonus" to moja inwencja, żeby w przypadku uruchomienia programu z wciśniętym
przyciskiem stop trzeba było najpierw go zwolnić.
Pozdrawiam
Zuk
Teraz działa jak należy.
A ten "bonus" to moja inwencja, żeby w przypadku uruchomienia programu z wciśniętym
przyciskiem stop trzeba było najpierw go zwolnić.
Pozdrawiam
Zuk