Opcje wyszukiwania (Strona 1 z 3)

Rejestry przesuwne to mechanizm, który umożliwia przekazywanie wartości z końca jednej iteracji na początek kolejnej. Bardzo dobrze ilustruje to poniższy film:

Poniżej przykładowe programy, wykorzystujące ten mechanizm.

Na poniższym filmie przedstawiona jest ciekawa technika, dzięki której wykorzystując zdarzenie Timeout oraz kontrolkę First Call? możemy sprawić, aby wybrane zdarzenie zostało wywołane samoczynnie przy starcie aplikacji.

Ograniczeniem tej techniki jest to, że zdarzenie Timeout może być obsługiwane tylko przez jeden subdiagram struktury Event. Możemy w ten sposób uruchomić więc tylko jedno wybrane zdarzenie.

Polecam poniższe ustawienia konfiguracyjne:

Dołączam zdarzeniową wersję programu przeliczającego temperaturę i skale.

Sposób tworzenia podprogramów w LabVIEW dobrze ilustruje poniższy film:

Uwagi do powyższego filmu i tematu tworzenia podprogramów:

- Nazwy kontrolek podprogramu powinny więcej mówić o tym, co dana kontrolka oznacza, czyli zamiast Numeric powinno być Temperature (C)

- Zgodnie z ogólną zasadą programowania, mówiącą, że funkcja powinna wykonywać tylko jedną czynność, przekazywanie w tym przypadku argumentu boolowskiego należy raczej uznać za złą praktykę (a na pewno nie powinien on nazywać się Boolean). Taki argument powoduje, że podprogram wykonuje dwie czynności - przelicza wartość albo nie przelicza. Tę funkcjonalność należało by potraktować tutaj jedynie jako przykład szkoleniowy, a docelowo wyprowadzić na zewnątrz (patrz zmodyfikowany program poniżej).

- W projekcie warto utworzyć sobie osobny wirtualny folder na podprogramy. W przypadku prostych aplikacji wystarczy jeden (np. SubVI), w przypadku bardziej złożonych dobrze pogrupować je według realizowanych funkcji (np. Akwizycja Danych, Obliczenia itp.).

Rysunek 1 Wirtualny folder w projekcie

- W nowszych wersjach LabVIEW nie ma już potrzeby przełączania się pomiędzy ikoną a terminalami, są one pokazane obok siebie w oknie Front Panel.

- Zalecany schemat połączeń dla podprogramów to 4-2-2-4. Jest to też schemat domyślnie ustawiany zawsze podczas tworzenia podprogramu. W przypadku bardzo prostych operacji jak powyższa, dobrym rozwiązaniem jest również najprostsze 1-1.

Rysunek 2 Panel frontowy podprogramu, własna ikona i domyślny schemat połączeń

Poniżej załączam również zmodyfikowany program.

Rysunek 3 Zmodyfikowana wersja programu

Jeżeli chcemy "pokolorować" obraz w skali szarości, musimy opracować sobie przekształcenie, w którym każdej wartości ze skali szarości odpowiada zestaw trzech składowych barwnych R, G i B.

Do tego celu możemy skorzystać z programu typu Paint.

Na przykład jeżeli chcemy zrobić przejście od koloru żółtego do czerwonego to możemy sprawdzić, że kolor żółty ma składowe:

[255, 255, 0]

Kolor czerwony natomiast [255, 0, 0]

Gradient od żółtego do czerwonego będzie więc wyglądał tak:

[255, 255, 0]
[255, 254, 0]
...
[255, 0, 0]

Następnie zamieniając jasności poszczególnych pikseli na zestaw RGB i zapisując obraz jako PPM, uzyskamy efekt nałożenia na obraz mapy kolorów:

Aby przejście obejmowało więcej kolorów należy dodać więcej punktów pośrednich, zmieniając w sposób liniowy poszczególne wartości pomiędzy nimi.

Z wyciekiem pamięci (ang. memory leak), mamy do czynienia w sytuacji, gdy nie zwalniamy zaalokowanego wcześniej obszaru pamięci, a tracimy do niego dostęp.

Wycieki pamięci mogą pozostawać niezauważone, jednak są szczególnie groźne w sytuacji gdy nasze programy pracują przez dłuższy czas w sposób ciągły.

Porządnie napisany program nie powinien wykazywać żadnych wycieków pamięci!

Najczęstsze błędy, które prowadzą do wycieku to:

- zwyczajnie niezwolnienie zaalokowanej pamięci poprzez pominięcie wywołania funkcji free
- przypisanie do wskaźnika nowo zaalokowanej pamięci bez zwolnienia pamięci, na którą wskazywał on wcześniej (przy założeniu, że jest to jedyny wskaźnik na ten obszar pamięci, i dane w tym obszarze nie są już potrzebne)
- zachowanie użytkownika różne od oczekiwań i przyzwyczajeń autora programu, powodujące sekwencję czynności prowadzącą do tego, że program się kończy przed operacją zwalniającą pamięć (bo np. zwolnienie pamięci jest jako osobna opcja w menu, a użytkownik wybrał od razu opcję wyjścia z programu)

Aby uniknąć wycieku pamięci należy kierować się prostą zasadą:

Funkcja free powinna zostać wywołana w programie dokładnie tyle samo razy, co funkcja malloc (lub calloc).

Przydatnym narzędziem do wykrycia, czy w naszym programie w Visual Studio pojawiają się wycieki pamięci jest Visual Leak Detector.

Instrukcja użycia:

1. Pobieramy i instalujemy VLD

2. Uruchamiamy Visual Studio, otwieramy nasz projekt lub tworzymy nowy, a następnie wybieramy z menu View opcję Property Manager.

Rozwijamy Visual Leak Detector -> Debug | Win32 i klikamy dwukrotnie Microsoft.Cpp.Win32.user.

W oknie w zakładce VC++ Directories dla opcji "Include Directories" oraz "Library Directories" dodajemy ścieżki do odpowiednich folderów w miejscach, gdzie zainstalował się VLD:

- dla Include Directories może to być na przykład C:\Program Files\Visual Leak Detector\include
- dla Library Directories będzie to na przykład C:\Program Files\Visual Leak Detector\lib\Win32

(Jeżeli piszemy aplikacje 64 bitowe, to to samo robimy dla Microsoft.Cpp.Win64.user, tylko w bibliotekach wskazujemy folder Win64).

3. Na etapie opracowywania programu, dołączamy do niego plik nagłówkowy <vld.h> po <stdlib.h>
Dołączenie tego pliku spowoduje, że po każdym uruchomieniu programu VLD poinformuje nas o ewentualnych wyciekach.

Po zakończeniu pracy nad programem i upewnieniu się, że nie ma żadnych wycieków, usuwamy dołączanie pliku <vld.h>

Przykład

Prosty program z wyciekiem pamięci:

#include <stdlib.h>
#include <vld.h>

void main() {
    int* tab;
    tab = (int*) malloc(100 * sizeof(int));
}

Efekt jego uruchomienia:

Jeżeli chcemy sprawdzić co pozostało nie zwolnione, w oknie Output odszukujemy sekcję Call Stack. Klikając dwukrotnie na linijkę dotyczącą naszego programu, zostaniemy przeniesieni do fragmentu kodu, w którym nastąpiła alokacja pamięci:

Program naprawiony poprzez dodanie wywołania funkcji free():

#include <stdlib.h>
#include <vld.h>

void main() {
    int* tab;
    tab = (int*) malloc(100 * sizeof(int));

    free(tab);
}

Tego typu błąd może pojawić się podczas uruchomienia programu w trybie debugowania (F5 - Start Debugging).

Oznacza on, że próbujemy dostać się (odczytać / zapisać) do obszaru pamięci, do którego dostęp jest zabroniony.

Należy wówczas przyjrzeć się dokładnie kodowi, a najczęstsze powody takiego błędu to na przykład:

- do funkcji typu scanf przekazaliśmy wartość zmiennej, a nie jej adres

- zadeklarowaliśmy tylko wskaźnik na dynamiczny obszar pamięci, ale zapomnieliśmy o zaalokowaniu tego obszaru,

- przechodząc po elementach tablicy wychodzimy zbyt daleko w pamięć (bo np. w pętli for mamy <=, a powinno być <), lub jeżeli odejmujemy jakieś wartości od indeksów tablicy, pojawiają się indeksy ujemne

- pomyliliśmy wysokość tablicy dwuwymiarowej z jej szerokością, zamieniając indeksy lub warunki stopu pętli for miejscami

Nierzadko miejsca powodujące te błędy możemy wytropić dokładnie czytając i eliminując do zera wszystkie ostrzeżenia, jakie zgłasza nam kompilator!

Don't Repeat Yourself

Jeżeli w programie zauważamy, że jakieś czynności się powtarzają, to jest to pierwsza przesłanka do tego, żeby pomyśleć nad utworzeniem z nich osobnej funkcji.

Funkcja powinna robić dobrze jedną rzecz

Jeżeli deklarujemy, że funkcja coś oblicza, to powinna obliczać, a nie jeszcze dodatkowo dopytywać się o coś użytkownika (to powinna robić inna funkcja).
Jeżeli deklarujemy, że funkcja dodaje do siebie dwie tablice, to powinna dodawać, a nie jeszcze zapisywać do pliku (to powinna robić osobna funkcja).

Nie mieszamy w jednej funkcji czynności związanych z interakcją z użytkownikiem z czynnościami związanymi z przetwarzaniem danych, pracą z systemem plików, to wszystko powinno zostać podzielone na osobne funkcje.

Pomocne w tym jest stosowanie się do wytycznych w zakresie nazewnictwa. Jeżeli nazywamy funkcje według szablonu zrób_coś() pomaga nam to w zapewnieniu, że funkcja robi tylko to.

Funkcja powinna być najkrótsza jak się da

Stosowanie tej zasady wymusza na nas podział programu na jak największą liczbę jak najkrótszych funkcji, co przy okazji sprawia, że eliminujemy powtórzenia i tworzymy funkcje, które rzeczywiście robią jedną rzecz. Ortodoksyjne podejście zakłada maksymalną długość funkcji jako około 5 linijek, co może nie być na początku łatwe, ale jest to pewien ideał, do którego warto dążyć.

Funkcja powinna dawać możliwość ponownego użycia
Staramy się tak pisać funkcje, aby maksymalizować ich uniwersalność i możliwość ich ponownego użycia.

Techniką, która pomaga osiągnąć jak największą uniwersalność kodu jest wydzielanie z funkcji mniejszych funkcji tak długo, aż stwierdzimy, że nic więcej nie da się wydzielić. Efektem jest program z dużą liczbą niewielkich funkcji, z których każda wykonuje jedną, precyzyjnie określoną operację.

Redukujemy sprzężenia czasowe pomiędzy funkcjami
Staramy się pisać program tak, aby poprawne działanie funkcji nie było uzależnione od wcześniejszego wywołania innej.

Wskazówka

Jeżeli widzimy w programie blok kodu, który jest opatrzony komentarzem, to jest to dobra kandydat na wydzielenie funkcji i usunięcie komentarza.

Przykład 1

#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>

double obliczPoleKwadratu() {
    double dlugoscBoku;
    printf("Podaj dlugosc boku: ");
    scanf("%lf", &dlugoscBoku);
    return dlugoscBoku * dlugoscBoku;
}

void main() {
    double pole;
    pole = obliczPoleKwadratu();
}

Funkcja obliczPoleKwadratu robi dwie rzeczy - dopytuje się użytkownika o długość boku i oblicza pole.

Wersja poprawiona:

#define _CRT_SECURE_NO_WARNINGS
#include <stdio.h>

double obliczPoleKwadratu(double dlugoscBoku) {
    return dlugoscBoku * dlugoscBoku;
}

void main() {
    double dlugoscBoku;
    double pole;
    printf("Podaj dlugosc boku: ");
    scanf("%lf", &dlugoscBoku);
    pole = obliczPoleKwadratu(dlugoscBoku);
}

Zwracam uwagę, że Visual Studio kompiluje tylko te pliki, które zostały dodane do projektu i są widoczne w folderze Source Files okna Solution Explorer.

Dlatego jeżeli napiszemy program na laboratorium, a następnie sam plik z kodem źródłowym prześlemy sobie i otworzymy w domu w Visual Studio, może okazać się, że nie będzie w ogóle opcji kompilacji lub kompilował i uruchamiał się będzie jakiś stary program.

Dlatego należy taki plik skopiować do folderu z projektem, a następnie dodać do Source Files (przez Add -> Existing Item), albo też jego zawartość skopiować do już istniejącego i dodanego do projektu pliku z kodem źródłowym.

Wówczas Visual Studio skompiluje ten kod, nie kompiluje ono kodu plików, które zostały w nim tylko otwarte, bez powiązania z jakimkolwiek projektem.

Załóżmy, że mamy program, w którym dokonujemy akwizycji danych, ich przetwarzania oraz zapisu wyników do pliku. Każda z tych operacji charakteryzuje się określonym czasem trwania. Dla lepszego zobrazowania symulujemy poszczególne operacje przy pomocy podprogramów przedstawionych poniżej.

Rysunek 1 Akwizycja danych, czas trwania 20ms

Rysunek 2 Przetwarzanie danych, czas trwania 50ms

Rysunek 3 Logowanie wyników, czas trwania 20ms

Jeżeli umieścimy poszczególne operacje w jednej pętli while tak, aby były wykonywane sekwencyjnie, całkowity czas wykonania pojedynczej iteracji pętli będzie określony przez sumę czasów wykonania poszczególnych podprogramów, wyniesie więc 90ms.

Rysunek 4 Podprogramy wykonywane sekwencyjnie, pomiar czasu wykonania pojedynczej iteracji pętli

Rysunek 5 Panel frontowy programu, wynik pomiaru czasu wykonania

Taka sytuacja może być dla nas bardzo niepożądana, jeżeli zależy nam na tym, aby akwizycja danych wykonywana była przy najmniejszym możliwym cyklu czasowym. Przy powyższym rozwiązaniu, cykl ten jest ponad 4-krotnie dłuższy.
Rozwiązaniem tego problemu jest zrównoleglenie wykonania poszczególnych operacji poprzez umieszczenie każdego z podprogramów w osobnej, działającej równolegle pętli while.

W tym celu tworzymy na diagramie blokowym dwie dodatkowe pętle while, jako warunek stopu do każdej z nich podpinamy zmienną lokalną dla przycisku Stop Button.

Rysunek 6 Równoległe pętle while

Poszczególne podprogramy nie mogą działać jednak zupełnie niezależnie od siebie, gdyż są ściśle powiązane przepływem danych. W celu przekazania danych do poszczególnych podprogramów, wykorzystamy mechanizm kolejki FIFO (first in first out). Pętla dokonująca akwizycji danych umieszcza pozyskaną w podprogramie Acquire Data tablicę danych w kolejce, z której będą one pobierane w pętli przetwarzającej. Z kolei przetworzone dane są umieszczane w drugiej kolejce, z której następnie pobiera je pętla logująca do pliku.

Rysunek 7 Pętle z kolejkami

W celu oprogramowania tego mechanizmu, przenosimy poszczególne podprogramy do osobnych pętli, a następnie wstawiamy na diagram blokowy dwa bloczki Obtain Queue, odpowiedzialne za utworzenie kolejek. Pierwszej kolejce nadajemy nazwę Acquired Data, drugiej Processed Data. Jako typ danych dla pierwszej kolejki podłączamy tablicę liczb typu double, natomiast w przypadku drugiej kolejki – pojedynczą liczbę typu double.

W pierwszej pętli (Acquisition) umieszczamy bloczek Enqueue Element, odpowiedzialny za dodanie elementu do kolejki. Na jego wejścia podpinamy kolejkę oraz tablicę wyjściową z podprogramu Acquire Data.

Elementy dodane do pierwszej kolejki, pobierane są w drugiej pętli (Processing). W tym celu umieszczamy w niej bloczek Dequeue Element, realizujący pobranie pierwszego elementu z kolejki. Element ten następnie podajemy na wejście podprogramu przetwarzającego, a wynik przetwarzania dodajemy do drugiej kolejki wykorzystując ponownie bloczek Enqueue Element.

Wyniki przetwarzania są pobierane z kolejki w pętli Logging w analogiczny sposób przy pomocy bloczka Dequeue Element.
Dodatkowo w każdej z pętli umieszczone zostały bloczki Tick Count, służące do pomiaru czasu iteracji pętli.
Po uruchomieniu programu możemy zauważyć, że poszczególne pętle pracują z najkrótszym możliwym cyklem czasowym.

Rysunek 8 Czasy cyklu każdej z pętli równoległych

Powyższe rozwiązanie nie jest jednak całkowicie poprawne, ponieważ naciśnięcie przycisku Stop powoduje natychmiastowe przerwania działania wszystkich pętli. Efektem tego jest brak przetworzenia i zapisu do pliku wszystkich wygenerowanych danych.

W celu zobrazowania tego efektu możemy dodać do każdej z pętli liczniki iteracji i porównać  ich wartości po zakończeniu programu.

Rysunek 9 Pętle równoległe z licznikami iteracji

Rysunek 10 Rezultat działania programu po jego zatrzymaniu

Jeżeli zależy nam na tym, aby wszystkie pozyskane dane zostały przetworzone przed zakończeniem programu, nie możemy zatrzymywać wszystkich pętli w tym samym momencie czasowym.

Aby rozwiązać ten problem, oprócz danych do przetworzenia, do kolejki dodawać będziemy komunikaty, informujące pętle równoległe o czynnościach do wykonania. W sytuacji, gdy tą operacją jest przetworzenie lub zapis danych, do kolejki trafią dane wraz z komunikatem odpowiednio Process lub Log, natomiast w przypadku zakończenia, w kolejce umieszczone zostaną puste dane oraz komunikat Stop. Takie rozwiązanie zapewni nam działanie pętli równoległych do momentu przetworzenia wszystkich danych znajdujących się w kolejkach.

Rysunek 11 Kolejki z komunikatami

W celu oprogramowania tego rozwiązania, zmieniamy typ danych kolejki na klaster złożony ze stałej Enum oraz odpowiednio tablicy i liczby typu double. Do przechowywania wszystkich możliwych komunikatów wykorzystujemy kontrolkę Enum, którą zapisujemy jako definicję typu, a po wykorzystaniu (utworzeniu poszczególnych stałych) usuwamy z diagramu blokowego.

W pętli Acqisition po pozyskaniu danych, pakujemy je w klaster (kontrolka Bundle) razem z komunikatem Process, a następnie tak przygotowany klaster wstawiamy do kolejki. W przypadku naciśnięcia przez użytkownika przycisku Stop Button, do kolejki wstawiamy klaster składający się z komunikatu Stop oraz pustej tablicy oraz zatrzymujemy działanie pętli.

W pętli Processing, pobieramy element z kolejki, a następnie rozpakowujemy klaster (kontrolka Unbundle). W zależności od wartości komunikatu, dokonujemy przetworzenia danych i wstawienia ich do kolejki z komunikatem Log lub zatrzymania pętli i wstawienia do kolejki pojedynczej liczby z komunikatem Stop dla pętli Logging.

W pętli Logging pobieramy w analogiczny sposób dane z kolejki, a w zależności od otrzymanego komunikatu zapisujemy je do pliku lub przerywamy działanie pętli.

Rysunek 12 Reakcja na komunikat Stop

Po uruchomieniu programu i naciśnięciu przycisku Stop możemy zauważyć, że licznik pierwszej pętli zostaje zatrzymany, natomiast pozostałe pętle działają dalej do momentu przetworzenia wszystkich danych z kolejki.

Rysunek 13 Efekt działania programu z komunikatami

Opracowany w ten sposób program możemy dalej ulepszyć, stosując zamiast typu danych specyficznego dla każdej kolejki, typ Variant. Dzięki temu unikniemy konieczności definiowania typu dla każdej kolejki, zastępując go jednym uniwersalnym typem, będącym klastrem złożonym z komunikatu oraz elementu Variant.

W tym celu zmieniamy dane w klastrze na pustą stałą typu Variant, a w poszczególnych pętlach w momencie dodawania danych do kolejki korzystamy z bloczka To Variant. Natomiast pobierając dane z kolejki, przekształcamy typ Variant na pożądany typ danych przy pomocy bloczka Variant To Data.

Rysunek 14 Wykorzystanie typu Variant

Propozycje ćwiczeń i modyfikacji
•    Zmodyfikować pętlę Acquisition tak, aby generowanie danych nie odbywało się w sposób ciągły, a zdarzeniowo z wykorzystaniem struktury Event
•    Dodać do programu paski postępu, informujące użytkownika o aktualnym stanie przetwarzania i logowania danych
•    Zapoznać się z dostępnym w LabVIEW szablonem aplikacji Queued Message Handler