Polskie Centrum LabVIEW

Witam, po przeczytaniu wielu wątków forum i spędzeniu wielu godzin przy tworzeniu mojej aplikacji doszedłem do wniosku ze model oparty o jedną petle while kiedy mamy do czynienia z interfejsem i częścią przetwarzająca dane nie jest najlepszym rozwiązaniem ;)
Uproszczony model aplikacji wygląda tak: Do tego nalezy dodać standardową maszynę stanów realizująca funkcjonalność 3 przycisków które zmieniają aktualnie wyświetlane dane. .
Potrzebuje pomocy z zdefiniowaniem jak powinna wyglądać prawidłowa sktruktura programu/ jak połączyc maszyne stanow z petla przetwarzajaca dane z elementu visa. Wydaje mi się ze optymalnym wyborem jest struktura producent/konsument ale nie wiem gdzie co powinno sie znajdować. Czy w takim przypadku element visa powinien znajdować sie wraz z obsługa przyciskow w petli producenta a pozostała funkcjonalność "bardzo skomplikowanych obliczen" wraz z wykresami w petli konsumenta? Prosze o pomoc i wyjasnienie.

nikt?

http://forums.ni.com/t5/LabVIEW/Produce ... d-p/817203 rozwiazanie jak by ktos szukał

To, że się nikt nie odezwał, nie znaczy, że Cie olewamy. Nie każdy może w tym temacie się wypowiadać, bo to nie jest coś trywialnego. Sam chciałem Ci napisać, ale nie miałem czasu na to. Cieszę się, że sam znalazłeś rozwiązanie.

A pisanie trzech postów pod rząd jest niezgodne z regulaminem. Następnym razem będę usuwał posty bez ostrzeżenia.

Proszę o wybaczenie za zdublowane posty, wydawało mi się ze nie jest to jakieś trudne zagadnienie.
Niestety nie udało mi się osiągnąć pożądanego rezultatu. W załączniku uproszczony problem na przykładzie zegarka. Nie wiem jak ustawić na wyświetlaczu stałej wartości min lub godziny tak aby ona nie znikała.(nie wchodzi w gre usunięcie timeoutu)

Po drobnej modyfikacji:

Poprawiłbym obsługę naciśnięcia przycisku STOP poprzez dodanie pakietu zamykającego pętle konsumenta.

Teraz po obsłudze przycisku STOP następuje zamknięcie kolejki co z kolei generuje błąd przy pobieraniu elementu w pętli konsumenta. I wystąpienie błędu jest powodem zakończenia aplikacji.

...i to jest prawidłowy sposób zamykania takiej pętli.

a jak dołozyć do tego stan aby domyślnie na początku wysyłane były godziny?

sendrill pisze:a jak dołozyć do tego stan aby domyślnie na początku wysyłane były godziny?

dołóż zakolejkowanie pakietu inicjującego konsumenta przed wejściem w petle producenta

Mikrobi pisze:...i to jest prawidłowy sposób zamykania takiej pętli.

Celowe wywołania błędu w aplikacji jest sposobem na zakończenie jej pracy? Mało w tym elegancji...

okazało ze jednak rozwiązanie nie spełnia wymogów ponieważ na wyświetlaczu nie jest pokazywana aktualna godzina tylko ta w momencie wykonania się eventu. Jak w takim razie wykonać strukturę która pokazuje aktualna godzinę/min w zależnosci od wybranego przycisku. (umknęło mi to przy pisaniu posta)
Edit: wystaczy dodac dodatkowo case i zmienne lokalne

TMa pisze:

sendrill pisze:a jak dołozyć do tego stan aby domyślnie na początku wysyłane były godziny?

dołóż zakolejkowanie pakietu inicjującego konsumenta przed wejściem w petle producenta

Mikrobi pisze:...i to jest prawidłowy sposób zamykania takiej pętli.

Celowe wywołania błędu w aplikacji jest sposobem na zakończenie jej pracy? Mało w tym elegancji...

W tym wzorcu aplikacji ten akurat rodzaj błędu wystąpi tylko w jednej określonej sytuacji: jeśli przestanie pracować pętla producenta. Jeśli nie pracuje to znaczy że zakończyła pracę, zatem nie ma na co czekać - nie ma już referencji do kolejki. Błąd jest tą właśnie informacją.
Oczywiście można raz jeszcze poszukiwać idealnego kształtu dla koła...
;)

Może i Kolega ma rację, że było by troszkę bardziej elegancko ... ale teraz jest metodycznie - mało zmieniło się w kodzie właściciela, a zauważa on dodatkową funkcjonalność

Czas jednak odpowiedzieć na pytanie Sendrill'a ... bo zmienne lokalne też nie są eleganckie Właściwie stosując zmienne lokalne nie musimy budować struktury producent/konsument, a jednak to robimy.
Sposobów na rozwiązanie Twojego problemu wyświetlania aktualnej daty jest wiele. Mnie przyszedł do głowy poniższy (znowu delikatnie zmodyfikowałem Twój kod ... czyli na bank można fajniej )

w tym programie na pewno nie są potrzebne, pisałem to w kontekscie bardziej złożonego programu.

Zmienne lokalne z zasady nigdy nie są potrzebne ... ale często są prostsze, szybsze w użyciu...
Jak chcesz używać zmiennych i ma być elegancko to zastosuj FGV.