Polskie Centrum LabVIEW

Cały mój program musi się wykonywać w pętli while, ze względu na wymaganą ciągłość wielu zdarzeń np sygnał dźwiękowy
Program jest wykonywany...(nie wysypuje się).
Chcę zrealizować zapis do pliku txt (mam to zrealizowane)

Zapis ma się wykonywać po zapaleniu lampki(boolean)

Problem jest taki, że w utworzonym pliku uzyskuję szereg powtarzających się wiadomości tekstowych typu string:
"zagrożenie"
"zagrożenie"
"zagrożenie"
itd
(co po namyśle wydaje się logiczne, ze względu na pętle while właśnie)

jak spowodować by zapis był wykonany jednokrotnie?
"zagrożenie"


Próbowałem to przegryźć na wiele sposobów: event, case czy też wyciągnąć to z pętli(tu brak reakcji....), ale następuje wtedy zawieszenie programu...

Co z Event'em Ci nie działało? Albo co działało nie tak jakbyś chciał? Możesz dodać sobie osobny wątek ze strukturą Event właśnie, która zareaguje na zmianę wartości tej kontrolki boolean, ale zapis wykona tylko wtedy, gdy New Value == True.

Ewentualnie (aby nie zmieniać struktury Twojego programu) dodaj sobie Shift Register i przy każdej iteracji wpisuj do niego wartość kontrolki boolean. Zapisu do pliku dokonuj tylko wtedy, gdy w aktualnej iteracji kontolka ma wartość TRUE, a poprzedniej (odczytana z Shift Register) było FALSE (czyli zmiana z 0 -> 1). W ten sposób unikniesz wielokrotnego dopisywania (czyli w stycuacji 1 -> 1).

Dzięki za odpowiedź.

Z Event'em problem był właśnie taki, że reagował na zmianę kontrolki, ale także wtedy gdy zmiana była na False(W przypadku naciśnięcia przycisku dzięki któremu zapala się lampka) lub wwcale nie zapisało gdy odnosiłem się do kontrolki.
Spróbuje pokombinować z tym Shift Register

Dzięki wielkie człowieku zapis śmiga...
Mam takie pytanie kwestii formalnej czy dobrym pomysłem jest użycie eventa w case (na takiej zasadzie ze mam kilka kontrolek w zależności od tego która się zapali wyświetlam inny komunikat np kontrolka 1 zagrozenie 1, kontrolka 2 to zagrozenie 3 ) w event zadawany byłby tylko string

Z tym eventem mam największy problem...


Ok chwilowo realizuje to dla kazdej kontrolki z osobna z uwagi na rejestr przesuwny

popop001 pisze: czy dobrym pomysłem jest użycie eventa w case

Event wewnątrz Case? Zdecydowanie nie jest to dobry pomysł ;)

Z Event'em problem był właśnie taki, że reagował na zmianę kontrolki, ale także wtedy gdy zmiana była na False

O tym napisałem Ci w poprzednim poście... Event zareaguje Ci na zmianę wartości wybranej kontrolki, ale zapisu dokonasz tylko wtedy, gdy nową wartością jest 1 (TRUE). Przypadek FALSE pozostaje pusty, dzięki czemy przy zmianie 1 -> 0 nic się nie dzieje. No i nie masz wielokrotnego zapisu bo zmiana 1 -> 1 to nie zmiana, czyli nie Event w ogóle nie zaskoczy.

mam kilka kontrolek w zależności od tego która się zapali wyświetlam inny komunikat

Do tego zadania możesz zrobić sobie oddzielny przypadek w strukturze Event, lub też jeden wspólny dla wszystkich kontrolek, a potem rozróżniać je po ich nazwie. Poniżej przykładowy VI.

Event wewnątrz Case? Zdecydowanie nie jest to dobry pomysł

TUTAJ lektura omawiająca szerzej temat tego, co robić, a czego nie robić z eventami.

Event zareaguje Ci na zmianę wartości wybranej kontrolki, ale zapisu dokonasz tylko wtedy, gdy nową wartością jest 1 (TRUE).

Można obejść się bez Case'a ustawiając akcję mechaniczną przycisku na Latch When Pressed albo Latch When Pressed. Lewa strona obrazka poniżej pokazuje jak to zrobić.



Pozdrawiam

ok, spróbowałem tak jak w przykładzie i zawiesił mi się program...

jeśli mam tylko kontrolka wejście główne to program wykonuje się...

Wewnątrz pętli While użyłem przepisania do value(sgnl)

Skoro coś nie działa, to jednak nie do końca zrobiłeś tak jak w przykładzie. Wrzuć swój kod, bo obrazek średnio się debuguje.

Aha, jak możesz to przycinaj obrazki zanim je wrzucisz (ponad połowa to białe tło...).

ok, zapamiętam na przyszłość...
Program w załączniku...

Nie bardzo wiem od czego zacząć... ;) Podsuwając Ci rozwiązanie z Shift Register nie wiedziałem, że aż tyle przycisków jest do obsłużenia... Aż się prosi o wykorzystanie o tego struktury Event! Tylko że poprawne wykorzystanie...

Tak samo jak kiepskim pomysłem jest pakowanie Event'a do Case'a, tak samo kiepsko sprawdza się pakowanie Event'a do pętli While wraz ośmioma Case'ami obok (zwłaszcza gdy te Case'y mają się wykonywać w kółko). Nie wiem, w którym momencie program Ci się 'wiesza', ale podejrzewam, że powodem tego jest tak umieszczony Event - pętla w każdej iteracji musi wykonać "całą swoją zawartość". Event czeka na jakieś zdefiniowane zdarzenie, a pętla While czeka razem z nim.

Najlepiej będzie, jeśli trochę (w sumie dość mocno...) zmienisz strukturę swojego programu. Zapoznaj się ze strukturą producent - konsument. Znacznie poprawi ona czytelność Twojego kodu dzięki podzieleniu go na wątki (jak dla mnie powinien on się zmieścić na jednym ekranie, a nie prawie dwudziestu...).

W celach edukacyjnych zamieszczam też przykładowy kod. Masz tam 3 wątki - jeden odpowiedzialny za rejestrację zdarzeń (przyciski...), drugi za ich obsługę, a trzeci wykonuje jakieś "ciągłe" zadanie (tu miganie diodą, u Ciebie będzie to odtwarzanie dźwięku).

ok biorę się za zmiany...
Dzięki za wskazówki, dopiero poznaje Labview więc są bardzo cenne.

Piszę z podziękowaniem za radę w rozwiązaniu problemu...

Mam tylko jeszcze jedno pytanie które mnie nurtuje, a mianowicie czy w strukturze klient-producent można zapewnić wykonywanie programu po podaniu hasła (np ciąg znaków bądź cyfr jeśli tak to w jakim miejscu)

Jeżeli chcesz podawać hasło na samym początku uruchomienia programu, to polecam odpowiedni fragment kodu umieścić jeszcze przed utworzeniem kolejki (Obtain Queue), czyli przed pętlami Producent/Konsument - tam robi się wszelkie wstępne ustawienia inicjalizacyjne.
Dane inicjalizayjne można tez przekazać w pierwszym kroku wykonania pętli Producenta (to on obsłuży wtedy hasło i przekaże odpowiedni kod konsumentowi)
Ogólnie Konsument zawsze dostanie to co wyprodukuje Producent i właściwie czeka na dane, które są przekazane kolejką (albo notyfikatorem) przez Producenta .

ok, a co w przypadku gdy istnieje potrzeba ciągłości wystąpienia informacji ze jest podane dobre haslo...??(4-tq pętla??)

Koncepcja jest taka:
-użytkownik podaje hasło bedace ciągiem znakow np 12345
-jesli haslo prawidłowe to otrzymujemy informacje o tym w postaci zapalonej diody
-jesli dioda zapalona to przy wcisnieciu przycisku wejscie 1 zapala sie lampka o tym informujaca co prowadzi do wygenerowania dzwieku
-chcac wylaczyc dzwiek wpisujemy znow haslo

Realizacje sprawdzania poprawnosci hasla i inne kroki mam... chodzi tylko o wkomponowanie tego'hasla' w program

Nie wiem czy dobrze zrozumiałem, ale z tego co łapię Kolega chce mieć hasła za każdym razem przy wejściu i wyjściu z procedury "generacja dźwięku" (czy też zapalenie lampki)

Można to zrobić w ten sposób, że Producent uruchamia np "okienko PopUp" z hasłem. Obsługując po wpisaniu hasła "event"( naciśnięcie guzika OK) przekazuje hasło kolejką do Klienta, który sprawdza czy jest poprawne i wykonuje np. generację dzwięku, po zakończeniu której uruchamia swojego "PopUp'a". Znowu woisujemy hasło i znowu Producent obsługując event naciśnięcia guzika OK przekazuje hasło Klientowi ... itd.

Myślę, że to jest w miarę prosty do implementacji pomysł ... chyba, że ktoś z Kolegów ma ciekawszy ...

Dzięki wielkie za radę. Problem zostal rozwiązany poprzez 4 pętle.