Polskie Centrum LabVIEW

Cześć
Problem przedstawia się następująco: Do karty pomiarowej NI USB 6009 podpinam różnicowo (symetrycznie) detektor światła, ściślej fotodiodę. Trywialne jest przedstawienie zmian napięcia fotodiody w funkcji czasu. Bardziej interesujące jest dla mnie spowodowanie aby sczytać wartość napięcia w interesującym mnie momencie, kiedy warunki świetlne są już ustabilizowane. Chodzi o to, że będę obracał pewnym elementem optycznym polaryzacyjnym, który będzie zmieniał natężenie przechodzącej przezeń wiązkę i padającą na powierzchnię aperturową detektora. Gdy obrócę o pewien kąt element optyczny, będę chciał kliknąć i przekazać aktualną wartość napięcia (lub średnią wartość) do tablicy. Zatem zamiast wykresu zależności napięcia w czasie, chcę wyrysowywać na bieżąco zależność napięcia w funkcji kąta obrotu tego elementu optycznego. Z góry dziękuje za wskazówki, szczególnie czy da się to zrobić za pomocą struktury case – nie wiem jak zrobić, by nic ona nie zwracała (struktura ta zwraca u mnie zera), gdy przycisk nie jest wciśnięty.

1. Select jest niepotrzebny w przypadku struktury case - dublujesz tą samą funkcjonalność, wystarczy poprowadzić drut bezpośrednio do wejścia : struktura case jest domyślnie dostosowane do obsługi przycisków czyli zmiennych typu Boolean
2. Jesli to LabVIEW 2009 albo wyższa wersja skorzystaj ze skrótu klawiszowego Ctrl+U
3. Klaster błędu jeśli jest wykorzystywany (a owszem, powinien być ;) ) to dla wszystkich funkcji.
4. Proponuję zacząć od poćwiczenia na architekturze ze strukturą event.

Tak, ta jedna ze struktur select rzeczywiście nie miała sensu. Ta na dole ma działać jak rejestr przesuwny, do sterowania zmianą kąta co 0,5 stopnia (dla elementu optycznego). Labview mam w wersji 2010 - skrót klawiszowy działa, dziękuję nie znałem go. Klaster błędu nie był podpięty z lenistwa.. Z tego co pamiętam w strukturze event konrola wykonania czynności z wnętrza sterowana jest czasowo.. A jesze mam pytanie - jeśli można, jak w strukturze case zwrócić "nic" zamiast zera..

Domyślną wartością dla DBL jest właśnie zero: skoro 'nic', to wartość domyślna, jeśli kod nie zwraca wartości to NaN (Not a Number)
Tak, event to obsługa przycisków i reakcje na działania użytkownika.
Po przećwiczeniu eventu będziesz mógł podzielić kod na część obsługującą interfejs (GUI) i część sprzętową, czyli wykorzystać szablon
(File >> New... >> Producer/Consument Design Pattern (events)): osobno interfejs i interakcja z użytkownikiem, osobno wątek komunikacji ze sprzętem.

Witam,
udało mi się w końcu napisać program, który działa tak jak chciałem. Teraz, w miarę jak znajdę czas będę chciał go zoptymalizować zgodnie z sugestią "Mikrobi". To co widzę już teraz, to to, że struktura case , może być zastapiona w całości strukturą event. Tak przynajmniej mi się wydaję, okaże się w trakcie pisania. Proszę o dodatkowe sufestie.
Pozdrawiam, Konrad. Komponent DAQ Asistance został tutaj zastapiony generatorem liczb losowych (dlatego na pierwszym wykresie nic nie zobaczymy).

Jest już lepiej.
Popatrz teraz na szablon
File>> New...>>Create New>>VI >> From Template>>Frameworks>> Design Patterns >>Producer/Consumer Design Patterns (Events)

A teraz wróćmy do ostatniego pokazanego przez ciebie kodu.

To co realizuje ostatnim pokazany VI to obsługa zdarzenia naciśnięcia przycisku równolegle do obługi struktury case.
Popatrz na początek co się stanie jeśli taki kod umieścisz wewnątrz struktury event, tam gdzie obsługujesz zmianę wartości przycisku.
Będziesz miał w tej sytuacji pętlę while zawierającą tylko strukturę event , obsługiwał będziesz dwa zdarzenia od przycisków:
1. "stop: Value Change" : naciśnięcie tego przycisku to wystawienie do warunku zatrzymania pętli stałej logicznej TRUE, w pinnych stanach na to wyjście ze struktury event podajesz stałę FALSE lub zostawiasz wartość domyślną - stuktura event sama ustawia tunel wyjściowy w trybie "Use Default If Unwired"
2. "wykonaj pomiar: Value Change": tutaj realizuje się kod który teraz jest w strukturze case: TRUE

To na początek. I od razu informacja: to tylko tryb ćwiczebny 8), taka postać kodu nie jest prawidłowa.
Dlaczego?
Event to obsługa zdarzeń między użytkownikiem a programem: tutaj to reakcja na zdarzenia zmiany wartości przycisków.
Taka postać powinna obsługiwać interfejs użytkownika ale nie sprzęt - tutaj właśnie pojawia się rozwiązanie takie jak szablon Producer/Consumer Design Patterns (Events)

Kiedy rozpracujesz na tym szablonie obsługę przycisku "wykonaj pomiar" wtedy zauważysz że możesz dołożyć przycisk "Zapisz wyniki".


...a potem bedzie już z górki

Witam,
zmieniłem trochę program. Zauważyłem jednak jedno niedopatrzenie zarówno w tym jak i poprzednim programie. Mianowicie graf podpięty zaraz za DAQ Asistance nie przedstawia aktualnych przbiegów (nie działa cały czas). Nie dziwi mnie to, zastanawiam się jednak jak to zrobić, dopóki nie korzystam z zaproponowanego szblonu (Producer/Consumer Design Patterns (Events). Próbowałem oddzielną pętlę while, lub pętlę w pętli, lub tak jak poniżej - nie działa.
Pozdrawiam,
Konrad.

Uwaga jedna: stop jest źle obsłuzony.
Sterowanie programu jest juz wewnątrz pętli kiedy nastepuje zmiana stanu przycisku - środowisko raczje to go nie zauważy, chociaż pewnie pominąłem jakiś detal
Tak jak wspominałem - ładowanie wątku pomiarowego do pętli z eventem jest rozwiązaniem złym
na jedno zdarzenie przypada jeden obrót pętli while+event
- owszem, pętla może się kręcić w trybie Timeout: definuje się czas w ms w lewym górnym rogu struktury event i jeśli nie nastepują inne zadeklarowane zdarzenia przez określony czas pętla przechodzi do tego stanu.
Jednak takie rozwiązanie jest gorsze: event jest obsługą wątku GUI nie zaś wątki sprzetowego.
Znajdz chwilę i sprawdz szablony Master - Slave i Producer - Consument, warto

Po wyjątkowo długim i burzliwym konsylium zapytam wprost:

jak uruchamiasz program? Run czy Run Continuously?

A ja zwrócę uwagę na jedną rzecz: konrad89 - czy Ty korzystasz z przycisku Run Continously? Bo na to wygląda. Korzystanie z tego narzędzia nie jest zalecane. Należy korzystać z przycisku Run a program przygotować tak, aby sam się kręcił (np. pętla While).

Z tego co przeczytałem do tej pory to chcesz osiągnąć pojedynczy pomiar w momencie naciśnięcia przycisku a następnie zapisanie tego pomiaru do tablicy.
Mikrobi ma rację pisząc, że wrzucanie wątku pomiarowego do struktury Event jest złe, ale w Twoim przypadku można na to przymknąć oko. Jeśli chciałbyś mieć ciągłą akwizycję to trzeba by już się pobawić w dwie pętle równoległe.

Ale wracając do problemu: wystarczy jedna pętla While ze strukturą Event. Do tego dwa przyciski: Measure i Stop. Measure wywołuje pomiar, Stop zatrzymuje pętle. Rejestr przesuwny do gromadzenia danych i jakiś wykres jak chcesz...

Coś takiego mniej więcej:

Hej, nie no jasne że używam Run. Nie po to jest petla while, żebym odpalał Run Continously. Ostatni przykład nie jest za szczęśliwy. Zedytowałem diagram w poprzednim poście/.
Pozdrawiam,
Konrad.

Witam, po dłuuugim czasie. Nadal nie rozwiązałem paru problemów (w tym implementacji w gotowym szablonie Producer/Consumer Design Patterns), ale program działa (choć programistycznie nie wszystko jest ok, jak sugerowaliście). Zamieściłem diagram programu do zczytywani i zapisywania danych z pomiaru. Nigdzie nie znalazłem książek gdzie tłumaczyliby kolejkowanie i rozdział panelu użytkownika od wnętrza programu - ten gotowy niewiele mi mówi na dziś. Może macie link do jakichś przystepnych materiałów, żeby to "złapać".

Nigdzie nie znalazłem książek gdzie tłumaczyliby kolejkowanie i rozdział panelu użytkownika od wnętrza programu

Hej. Też szukałem informacji na ten temat, najlepsze co udało się znaleźć to:
http://expressionflow.com/2007/10/01/la ... hitecture/