Polskie Centrum LabVIEW

paczu, próbuj, jeżeli coś nie będzie szło, wrzuć kod, postaramy się pomóc. Jeżeli twoje 'podprogramy' mają jakieś takie spójne funkcjonalności, postaraj się je wsadzić w subVIje. Będzie Ci wtedy dużo prościej obudować je odpowiednią architekturą a i przejrzystość kodu na tym zyska.

Garreth, maszyna stanu (taka goła jak tutaj, nie jako część jakiejś większej architektury) ma jednak pewne wady (np. blokowanie interfejsu na czas wykonywania obliczeń, albo dość uciążliwe zaimplementowanie asynchronicznej komunikacji z jakimś urządzeniem). Sensownego zastosowania obiektów na takim (czyli raczej niedużym) poziomie skomplikowania funkcjonalności aplikacji to raczej nie widzę. Narzut czasowy na napisanie architektury obiektowej nie zwróciłby się w tym przypadku zupełnie. Za to jeżeli chciało by się podskoczyć o jeszcze jedno oczko w "ładności" aplikacji można z powodzeniem zastosować architekturę producent-konsument z komunikacją na kolejkach. Interfejs robimy wtedy w oddzielnej pętli, więc nie zblokujemy go sobie podczas obliczeń, w pętli konsumenta chodzi sobie mniej więcej taka zwykła maszyna stanu i wykonuje zakolejkowane polecenia. Jak potrzebujemy dodać komunikację asynchroniczną to myk, dwie kolejne pętle na odbieranie i wysyłanie i wszystko sobie hula współbieżnie.

may ja to wszystko wiem;) Nawet najprostsze programiki robiłem używając producer-consumer wraz z maszyną stanu, więc gdyby ktoś potrzebował to jakiś snippet mogę podrzucić. Ostatnio zresztą zakończyłem projekt na cRIO, gdzie miałem producer-consumer i na host application i na cRIO, które się jeszcze komunikowały ze sobą streamem ethernetowym. Bajka, gdyby nie to, że cRIO miał tylko 128mb RAM i trzeba było walczyć z optymalizacją. Ale już nie offtopuję;)
O obiektach miałem na myśli właśnie w bardziej rozbudowanym programie, w którym można by w pełni wykorzystać walory dziedziczenia. Trudno mi teraz wymyślić przykład, ale mam na myśli coś w stylu ściągnięcia wspólnych części programu do jednej klasy, utworzyć metody w stylu "wczytaj/zapisz plik", i dorzucić obliczenia. Jasne, przy 5 podprogramach narzut czasu na zabawę z czymś takim i potencjalna ilość problemów spowodowanych nauką, byłyby nieopłacalne i program byłby trudniejszy do rozwoju przez innych ludzi, gdyż nie każdy obiekty zna. Myślę jednak, że obiektów warto się nauczyć na pewnym etapie, żeby wiedzieć "z czym to się je" i do czego może się przydać.

Skomentuję krótko: Ba!

Panowie działaaaaaaaa!!!!! normalnie sam jestem pod wrażeniem. wszystko wsadziłem do jednej maszyny i śmiga zarąbiście.
W dalszym ciągu nie wiem jak maszynę stanu zrobić od zera ale to nic, wystarczył szablon z demka. Rozbudowałem go o kolejne stany, upakowałem wszystko gdzie trzeba według szablonu iiii ta daaam!
may, jeszcze raz wielkie dzięki za pomysł, pomoc, demko i wytrwałość w przekonywaniu do maszyny stanu ;)
Jeszcze muszę popracować nad kosmetyką co by przyjemniejsze dla oka było ;) a co do działania to już nie ma zastrzeżeń.
Dzięki!

Kliknij w "Pochwal" may'owi;)
Swoją drogą od zera myślę, że byś dał radę to zrobić już teraz. Strukturę znasz, kwestia tylko utworzenia zmiennej typu enum, którą potem należy przekształcić Type Def (prawy klawisz Make Type Def), zapisać w osobnym pliku i stosować tak jak w tym szablonie.

Jeżeli chodzi o kosmetykę, zerknij na slajdy z ostatniego dnia programisty LV ( http://ftp.ni.com/pub/branches/ee/2012/ ... 012_pl.zip ), jedna prezentacja dotyczyła właśnie wyglądu aplikacji - dołączone do niej są też linki do youtube z wideotutorialami.