Pytanie o strukturę komunikacyjną dla różnych interfejsów

[MK_Zuk]

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

[TMa]

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.

[MK_Zuk]

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

[TMa]

wywołanie pomiaru wiąże się z programowym wygenerowaniem zdarzenia za pomocą
property node właściwość value (signaling). Dobrze rozumię?

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 tutaj

[MK_Zuk]

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

[Zyga]

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

multithreads.png (45.41 KiB) Przejrzano 15244 razy

P.S. Wie ktoś dlaczego po zrobieniu snippeta kasuje mi zdefiniowane eventy?

[MK_Zuk]

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

[TMa]

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.

[MK_Zuk]

2. Stop też może być osobnym zdarzeniem dynamicznym dla wszystkich urządzeń.

A jaka jest różnica w obsłudze zdarzenia w przypadku zdarzenia statycznego i dynamicznego?
Wewnątrz pętli event raczej różnicy nie będzie.

3. Pomiary z urządzeń można wrzucać do kolejek. Zazwyczaj pętla przetwarzania danych pomiarowych działa asynchronicznie do akwizycji.

ciekawy pomysł. Co jednak w przypadku zaniku napięcia? cała seria pomiarowa traci się?

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

[MK_Zuk]

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

[PiDi]

Z moich testów dynamicznych zdarzeń wynika, że est to bardzo zawodny mechanizm.
Zdarzenia często są pomijane.

Możesz rozwinąć? W jakiej sytuacji są pomijane?

[MK_Zuk]

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

[PiDi]

Kilka postów wyżej wrzuciłem plik testowy w którym także akcja konfiguracja zawsze działa
natomiast akcja pomiar nie.

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]

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