Witam,
postanowiłem nauczyć się QMH, zacząłem od przykładowego zadania CLD z bankomatem.
Czy ktoś mógłby rzucić okiem i ocenić?
Generalnie założyłem, żeby przy tej próbie nie korzystać z wbudowanego szablonu a zrobić wszystko od zera.
W programie brakuje kilku rzeczy, o których wiem:
- nie ma obsługi błędów,
- nie ma zamknięcia kolejki i zdarzenia dynamicznego,
- operacja dodania/odjęcia pieniędzy na koncie powinna być zabezpieczona np. przez realizację za pomocą zmiennej funkcjonalnej.
W razie czego wrzuciłem też PDFa z treścią zadania.
Dzięki za pomoc
Pozdrawiam
Zuk
QMH pierwsza próba
QMH pierwsza próba
- Załączniki
-
- ATM in QMH.zip
- (449.14 KiB) Pobrany 422 razy
- Pitol
- Moderator
- Posty: 984
- Rejestracja: 19 lip 2007 00:00
- Wersja środowiska: LabVIEW 2019
- Lokalizacja: Kraków
Re: QMH pierwsza próba
Rzuciłem okiem... no i pewnie byś zdał CLD. Tylko dopieścić program trochę.
Dodać to co napisałeś. Poza tym w kilku VI olałeś sprawę z błędami (Chack Pin, Read Accounts).
Referencje do kontrolek zbij w tablicę przed pętlą. Po co ma to się robić za każdym razem.
Staraj się lepiej opisywać nazwy kontrolek i trzymać jednego języka.
A poza tym to
Dodać to co napisałeś. Poza tym w kilku VI olałeś sprawę z błędami (Chack Pin, Read Accounts).
Referencje do kontrolek zbij w tablicę przed pętlą. Po co ma to się robić za każdym razem.
Staraj się lepiej opisywać nazwy kontrolek i trzymać jednego języka.
A poza tym to
Re: QMH pierwsza próba
Dzięki
Re: QMH pierwsza próba
Zastanawia mnie jeszcze jedno.
Generalnie QMH jest integracją podstawowych struktur:
maszyna stanów i producent konsument, gdzie pętla wykonująca
zadanie jest to pętla konsumenta zbudowana w strukturze maszyny stanów, do której przychodzą także
(albo przede wszystkim) rozkazy wykonania konkretnego stanu z zewnątrz - pętli producenta,
dodatkowo, kiedy jest to potrzebne, przechodzą dowolne dane przez typ variant.
Pisząc kod maszyny stanów stany zapisuje się w definicji typu kontrolki enum, która przechowuje wszystkie stany
a definicja typu ułatwia zarządzanie stanami w kontrolce (dopisywanie/usuwanie).
W strukturze QMH jako element przenoszący rozkaz używa się raczej typu String.
W pierwszym przypadku (enum) rozwiązanie jest wygodniejsze ale każda kolejka musi mieć swoje subVI obsługujące.
W drugim przypadku (string) wszystkie kolejki można tworzyć jednym (powielonym dla każdej kolejki subvi) i liczba plików
obsługujących kolejki jest mniejsza ale kosztem tego, że do selektora struktury case obsługującej stany trzeba podać dokładnie takie same nazwy
zapisane w stringach czyli łatwiej zrobić błąd - najprostsza literówka.
Które rozwiązanie preferujecie i dlaczego?
Kolejka przenosząca dedykowanego enuma i varianta (jak ja to zrobiłem wyżej)
czy kolejka przenosząca stringa i varianta (tak jest chyba we wszystkich filmach na YT jak również w szablonie LabVIEW - Create... --> New Project),
a może jest jeszcze jakieś trzecie rozwiązanie?
Pytam, bo chciałbym od razu nauczyć się dobrego nawyku do pracy w tej strukturze.
Pozdrawiam
Zuk
Generalnie QMH jest integracją podstawowych struktur:
maszyna stanów i producent konsument, gdzie pętla wykonująca
zadanie jest to pętla konsumenta zbudowana w strukturze maszyny stanów, do której przychodzą także
(albo przede wszystkim) rozkazy wykonania konkretnego stanu z zewnątrz - pętli producenta,
dodatkowo, kiedy jest to potrzebne, przechodzą dowolne dane przez typ variant.
Pisząc kod maszyny stanów stany zapisuje się w definicji typu kontrolki enum, która przechowuje wszystkie stany
a definicja typu ułatwia zarządzanie stanami w kontrolce (dopisywanie/usuwanie).
W strukturze QMH jako element przenoszący rozkaz używa się raczej typu String.
W pierwszym przypadku (enum) rozwiązanie jest wygodniejsze ale każda kolejka musi mieć swoje subVI obsługujące.
W drugim przypadku (string) wszystkie kolejki można tworzyć jednym (powielonym dla każdej kolejki subvi) i liczba plików
obsługujących kolejki jest mniejsza ale kosztem tego, że do selektora struktury case obsługującej stany trzeba podać dokładnie takie same nazwy
zapisane w stringach czyli łatwiej zrobić błąd - najprostsza literówka.
Które rozwiązanie preferujecie i dlaczego?
Kolejka przenosząca dedykowanego enuma i varianta (jak ja to zrobiłem wyżej)
czy kolejka przenosząca stringa i varianta (tak jest chyba we wszystkich filmach na YT jak również w szablonie LabVIEW - Create... --> New Project),
a może jest jeszcze jakieś trzecie rozwiązanie?
Pytam, bo chciałbym od razu nauczyć się dobrego nawyku do pracy w tej strukturze.
Pozdrawiam
Zuk
- Pitol
- Moderator
- Posty: 984
- Rejestracja: 19 lip 2007 00:00
- Wersja środowiska: LabVIEW 2019
- Lokalizacja: Kraków
Re: QMH pierwsza próba
Ja osobiście preferuję Enum, bo trudniej jest popełnić błąd.
Przy stringu jest elastyczność, ale każda literówka może zaboleć (choć jak sobie literówki obsłużysz w odpowiednim case to w sumie nie będzie tak źle).
W każdym razie ja nie korzystam z żadnej z powyższych metod.
Chyba, że robię jakiś super mały programik w "5 minut".
W swoich programach korzystam z wzorca projektowego "Command Pattern" (do poczytania w sieci).
W skrócie - tworzysz klasę "Command", po której dziedziczą Ci konkretne "zadania".
Czyli zamiast klastra z enumem/stringiem + variant masz obiekt konkretnej klasy. Jeśli chcesz, to w załączniku masz mój template.
Nie jest idealny, bo nie mam czasu go dopracować ale do zrozumienia idei Command Pattern się w pełni nadaje.
W moim przykładzie mam dwa "wzorce". Jeden do obsługi komend w maszynie stanów (CommandManager) a drugi do obsługi zdarzeń użytkownika (EventMngr).
W tym szablonie zaimplementowanych jest od razu kilka funkcji:
AppInit - wszystko co ma się wydarzyć przed uruchomieniem FP
ReadConfig - odczyt pliku *.xml z ustawieniami
Save Config - zapis ustawień do pliku *.xml
RefreshFP - metoda do odświeżania elementów na panelu (wyłącza odświeżanie FP, zmienia wartości kontrolek, włącza odświeżanie FP)
ErrorHandler - obsługa błędu
Quit - zamknięcie programu.
Część z nich to tylko szablony, do wypełnienia w zależności od funkcjonalności.
Nowe komendy dodajesz poprzez stworzenie klasy, która będzie dziedziczyć po klasie CommandManager.
Korzystając z tego rozwiązania masz największy "narzut" na przygotowanie, ale jak już masz taki template to można zdecydowanie przyspieszyć prace.
Ja w tym momencie staram się przyzwyczaić do Actor Framework, ale póki to mi się nie uda korzystam z mojego szablonu.
Pobaw się i daj znać czy się spodobało.
Jak coś to pisz.
Przy stringu jest elastyczność, ale każda literówka może zaboleć (choć jak sobie literówki obsłużysz w odpowiednim case to w sumie nie będzie tak źle).
W każdym razie ja nie korzystam z żadnej z powyższych metod.
Chyba, że robię jakiś super mały programik w "5 minut".
W swoich programach korzystam z wzorca projektowego "Command Pattern" (do poczytania w sieci).
W skrócie - tworzysz klasę "Command", po której dziedziczą Ci konkretne "zadania".
Czyli zamiast klastra z enumem/stringiem + variant masz obiekt konkretnej klasy. Jeśli chcesz, to w załączniku masz mój template.
Nie jest idealny, bo nie mam czasu go dopracować ale do zrozumienia idei Command Pattern się w pełni nadaje.
W moim przykładzie mam dwa "wzorce". Jeden do obsługi komend w maszynie stanów (CommandManager) a drugi do obsługi zdarzeń użytkownika (EventMngr).
W tym szablonie zaimplementowanych jest od razu kilka funkcji:
AppInit - wszystko co ma się wydarzyć przed uruchomieniem FP
ReadConfig - odczyt pliku *.xml z ustawieniami
Save Config - zapis ustawień do pliku *.xml
RefreshFP - metoda do odświeżania elementów na panelu (wyłącza odświeżanie FP, zmienia wartości kontrolek, włącza odświeżanie FP)
ErrorHandler - obsługa błędu
Quit - zamknięcie programu.
Część z nich to tylko szablony, do wypełnienia w zależności od funkcjonalności.
Nowe komendy dodajesz poprzez stworzenie klasy, która będzie dziedziczyć po klasie CommandManager.
Korzystając z tego rozwiązania masz największy "narzut" na przygotowanie, ale jak już masz taki template to można zdecydowanie przyspieszyć prace.
Ja w tym momencie staram się przyzwyczaić do Actor Framework, ale póki to mi się nie uda korzystam z mojego szablonu.
Pobaw się i daj znać czy się spodobało.
Jak coś to pisz.
- Załączniki
-
- Template.zip
- (310.71 KiB) Pobrany 446 razy
Re: QMH pierwsza próba
Dzięki.
Wzorzec bazuje na programowaniu obiektowym, którego jeszcze nie ogarniam.
Powoli zaczynam dopiero cokolwiek próbować robić w miarę wolnego czasu.
Jest to następny poziom do opanowania ;)
jak widać coraz powszechniejszy jeżeli chodzi o programowanie w LabVIEW.
Ale z tym enumem trafiłem przynajmniej jeżeli chodzi o "aplikacje robione w 5 minut" ;)
Pozdrawiam
Zuk
Wzorzec bazuje na programowaniu obiektowym, którego jeszcze nie ogarniam.
Powoli zaczynam dopiero cokolwiek próbować robić w miarę wolnego czasu.
Jest to następny poziom do opanowania ;)
jak widać coraz powszechniejszy jeżeli chodzi o programowanie w LabVIEW.
Ale z tym enumem trafiłem przynajmniej jeżeli chodzi o "aplikacje robione w 5 minut" ;)
Pozdrawiam
Zuk