Zdarzenia w programach VI (zdarzenia rejestrowane dynamicznie)

Konstrukcja obsługi zdarzeń Terminal czasu przeterminowania służy do określenia czasu oczekiwania konstrukcji na zdarzenie. Jest definiowany w milisekundach: Wartość –1 oznacza nieograniczone oczekiwanie na zdarzenie. Wartość >0 aktywizuje kontrolę przeterminowania i wtedy jeśli nie wystąpi żadne zdarzenie w zadeklarowanym okresie oczekiwania ,wówczas jest realizowana ramka przeterminowania.

Problematyczne konstrukcje programowe

Źródła zdarzeń

Źródła zdarzeń (cd.) Przykład: UsingSplitterBars.vi

Tryby rejestracji zdarzeń Aplikacja wymaga pewnego ograniczonego zestawu zdarzeń. Zdarzenia inne niż wymagane nie powinny być generowane. Rejestracja odpowiada za aktywizację wybranych zdarzeń. Rejestracja statyczna obowiązuje przez cały czas działania programu VI i nie można jej modyfikować podczas działania programu. Jest ustalana na etapie konstrukcji diagramu VI oraz konfigurowania jego konstrukcji zdarzeniowych. Dotyczy wyłącznie źródeł zdarzeń związanych bezpośrednio z wykonywanym programem VI. Wykonuje się automatycznie w momencie startu programu VI zawierającego konstrukcje obsługi zdarzeń. Rejestracja dynamiczna zdarzeń omija ograniczenia rejestracji statycznej. Umożliwia modyfikację listy udostępnionych zdarzeń w czasie działania programu. Pozwala także rejestrować i obsługiwać zdarzenia pochodzące z innego VI.

Rejestracja statyczna Zdarzenia wymienione w liście ramek są rejestrowane automatycznie w chwili uruchomienia programu i pozostają aktywne przez cały czas działania programu zawierającego przedstawioną konstrukcję. Zdarzenia te mogą dotyczyć Aplikacji LabView, programu VI i obiektów jego panelu czołowego. Przykład: Static_Events.vi (zastosowanie węzła własności do obiektu określonego referencją; pobranie etykiety i wartości)

Rejestracja dynamiczna Celem rejestracji dynamicznej jest uaktywnienie wybranych zdarzeń na pewien okres podczas działania programu. Rejestracja dynamiczna dotyczy tych samych zdarzeń co rejestracja statyczna. Program, aby zarejestrować zdarzenie musi dysponować określeniem jego źródła oraz rodzaju zdarzenia. Odpowiada za to węzeł rejestracji zdarzeń (Register For Events), który: na podstawie referencji do wybranego źródła zdarzeń otwiera listę dostępnych zdarzeń dla tego źródła a pole z wybranym zdarzeniem zostaje zarejestrowane (uaktywnione). Referencje pozwalają określić źródło zdarzeń należące również do innych programów VI a także programów uruchomionych na innych maszynach.

Rejestracja dynamiczna - realizacja Ctl Refnum – wejście subVI dostarczające referencję do obiektu kontrolnego programu wywołującego ten podprogram (zdarzenie od zewnętrznego obiektu). OK. Button – referencja do własnego obiektu kontrolnego. Referencje do obiektów oraz programów VI pozwalają określić źródło zdarzeń a funkcja rejestracji aktywizuje wybrany rodzaj zdarzenia dla danego źródła. Zarejestrowane zdarzenia są dostarczane konstrukcji obsługującej zdarzenia poprzez wejściowy terminal zdarzeń dynamicznych. Teraz dopiero okno edycji zdarzeń ramki struktury zdarzeniowej dysponuje listą źródeł zdarzeń rozszerzoną o zdefiniowane zdarzenia dynamiczne.

Blokada panelu czołowego po wystąpieniu zdarzenia Zdarzenia filtrowane zawsze wykorzystują blokadę ( nie ma opcji wyłączenia). Dla zdarzeń powiadamiających jest aktywna opcja wł./wył. blokady. Zdarzenia dynamiczne zawsze pracują bez blokady.

Rejestracja dynamiczna – określanie źródeł zdarzeń Referencje do źródeł zdarzeń typu <Application> oraz <This VI> w odniesieniu do lokalnej i zdalnej maszyny.

Rejestracja dynamiczna – określanie źródeł zdarzeń (cd.) Sposób uzyskania referencji do obiektów innego programu VI. Sposób uzyskania referencji do własnych obiektów programu VI.

Funkcja dynamicznej rejestracji zdarzeń

Konstrukcja obsługi zdarzeń dynamicznych

Modyfikacja dynamicznej rejestracji zdarzeń Terminale zdarzeń dynamicznych pracują podobnie do rejestru przesuwnego konstrukcji pętli. Wyrejestrowanie zdarzenia Mouse Enter (dołączenie do wejścia referencji stałej nie będącej numerem referencyjnym). Ponowne zarejestrowanie zdarzenia Mouse Enter (dołączenie do wejścia referencji referencji do elementu kontrolnego LED). Przykład: Dynamic_Events.vi

Zdarzenia programowe LabView udostępnia zdarzenia programowe; czyli mechanizm pozwalający programowi VI w pewnych szczególnych sytuacjach generować zdarzenia. Zdarzenia tego typu służą głównie do asynchronicznego przekazywania danych pomiędzy różnymi fragmentami programu (z pominięciem dróg przepływu danych). Niezbędne elementy programowe : Definicja zdarzenia, Rejestracja zdarzenia, Generacja zdarzenia programowego. Destrukcja zdarzenia.

Zdarzenia programowe – definicja zdarzenia Zdefiniowanie zdarzenia wykonuje funkcja Create User Event: Nazwa danej (etykieta) określa nazwę definiowanego zdarzenia. Typ tej danej określa typ danej przenoszonej przez zdarzenie.

Zdarzenia programowe – rejestracja zdarzenia

Zdarzenia programowe – generacja zdarzenia Generację zdarzenia wykonuje funkcja Generate User Event. Dana przekazana funkcji jest daną zdarzenia, przenoszoną do miejsca obsługi zdarzenia. Tutaj generowanie zdarzeń następuje w iteracjach pętli będących wielokrotnością 100. Przenoszona dana jest numerem iteracji pętli, w której jest generowane zdarzenie. Przykład: User_Events.vi

Zdarzenia programowe – destrukcja zdarzeń Jeśli obsługa zdarzeń zarejestrowanych dynamicznie nie jest już potrzebna, należy je wyrejestrować za pomocą funkcji 'Unregister For Events' . Jej wykonanie powoduje odrejestrowanie wszystkich zdarzeń określonych przez doprowadzoną referencję oraz zlikwidowanie kolejki zdarzeń związanej z tą referencją. Brak wykonania tej operacji powoduje nieskończony rozrost kolejki zdarzeń. Pętla obsługi zdarzeń skończyła swoje działanie ale zdarzenia mogą być dalej generowane i wstawiane do kolejki zdarzeń oczekujących na obsłużenie. Teraz nie są obsługiwane i usuwane z kolejki.

Model aplikacji – producent/konsument

Producent/konsument Aplikacja zawiera równoległe pętle należące do dwóch kategorii: producentów danych i ich konsumentów. Komunikacja pomiędzy nimi jest realizowana za pomocą kolejki danych. Na wstępie kolejka jest inicjowana (Obtain Queue). Producent wstawia dane do kolejki (Enqueue Element) a konsument wyciąga dane z kolejki (Dequeue Element). Kolejka funkcjonuje jako FIFO (first-in/first-out), zatem konsument odbierze wszystkie dane wprowadzone przez producenta i analizuje je w kolejności ich wstawienia do kolejki.

Producent/konsument - przykład Przykład: Move-Window.vi Pętla producenta gromadzi w kolejce wszystkie zlecenia przesunięć okna aplikacji. Pętla konsumenta realizuje przesunięcia okna wyciągając zlecenia przesunięć z kolejki.

Producent/konsument - problemy Kolejki są ograniczone do przenoszenia określonych typów danych. Jeśli producent dostarcza różne typy danych to muszą one używać odrębnych kolejek. Tworzenie odrębnych kolejek stanowi poważny problem projektowy. Rozwiązanie: Kolejki akceptują tablice oraz klastry. Jeśli producent dostarcza różne typy danych to należy je umieścić w klastrze. W ten sposób zamaskuje się różnorodność przekazywanych danych.

Producent/konsument – problemy (cd. ) Model producent/konsument nie stosuje synchronizacji. Może to stanowić problem, jeśli jedna pętla zbyt wcześnie rozpocznie pracę. Rozwiązanie: Należy zastosować generację wydarzeń ( węzły occurrence ): Set Occurrence Wszystkie węzły które oczekują na wydarzenie wychodzą ze stanu oczekiwania (kończą oczekiwanie). Generate Occurrence Wait on Occurrence Przykład: Continuously Generate Occurrences.vi