sterowanie kontrolkami, a maszyna stanów

[ky3orr]

Czołem!

piszę sofcik opierający się o prostą maszynę stanów (case objęty pętlą while, przekazywanie kolejnych stanów enum poprzez shift register).
w kolejnych stanach steruję właściwościami visible oraz wpisuję true/false do przycisku poprzez local variable.

problem polega na tym, że wszystko działa o ile kod danego stanu został wykonany tylko jeden raz. gdy ma się to stać ponownie nic się nie dzieje.

czy w jakiś magiczny sposób trzeba jakoś poinformowac labview, że ma zaktyalizować jakieś zmienne czy co?

pozdrawiam

[jogurt_owocowy]

Diagram, diagram...

[ky3orr]

więc ku memu zdziwieniu sofciik pomocniczy dziala.....

maszyna rozpoczyna od stanu LED poczym nastepuje zmiana wartosci dla indykatora, czekanie 1s i wybor kolejnego stanu. jesli wcisnieto STOP to koniec programu, jesli nie to ponownie stan LED.

troche sie zdziwilem - musze popatrzec w ten prawdziwy kod i znalezc usterke.

bynajmniej mam pytanie czy tak zaprogramowany MIGACZ jest wykonany dobrze?

pozdrawiam

[student83]

Możesz stworzyć jeden stan który odczytuje wartości kontrolek i uaktualnia je.
Służy do tego struktura event structure.

[jogurt_owocowy]

Chyba trochę za duży ten kod jak na migacz. Jak rozumiem, maszyna stanów w przyszłości rozstanie rozbudowana, ale wtedy może się okazać, że diodka przestanie migać tak jak powinna.
Jeśli mruganie diodkami ma być jakimś ważnym elementem programu, informować o czymś, to chyba lepiej nawet zrobić osobny "mrugający" wątek.

[ky3orr]

postanowilem wkleic to co udalo mi sie juz wygenerowac, abyscie mogli rzucic okiem na to o co mi chodzi.

otoz po wlaczeniu programu nastepuje inicjalizacja kontrolek i nastepuje oczekiwanie na wybranie numerow portow dla dwoch RS-ow. gdy sa jednakie to nie da sie przesunac przelacznikiem uruchamiajacym dalsze funkcje synchronizacji do okreslonych czesci minuty i dalej wysylania odpowiedniego stringa w port - tez w koreslonych momentach minuty.

poki co czesc dotyczasa jednego z portow nie zostala zaimplementowana, ale sygnaly VISA zostaly przedrutowane i chyba sa ok.

na poczatku wszystko dziala tak jak powinno - czyli dziala zabezpieczenie przecie wybraniu jednakowych portow i daje sie zalaczyc dalsza czesc diagramu. cyklicznie w dobrych momentach wysylany jest string na port RS. gdy przesune przelacznik spowrotem to rs zostaje (chyba) zwolniony, dane nie sa juz wysylane, kontrolki do wyboru numerow portow staja sie aktywne i... tyle.

dalsze przelaczenie suwaka nic nie zmienia, a powinno bo wydaje mi sie, ze wpadam w stan "konfiguracja_polaczen".
nie dziala juz zabezpieczenie przeciw jednakowemu wyborowi numerow portow. wlasciwie jedyna reakcja jaka da sie zaobserwowac to to iz gdy wcisne przycisk STOP (do tej pory jeszcze nie klikany) program przeskoczy do stanu STOP i stamtąd do KONIEC_PROGRAMU, ktory faktycznie sie konczy.
cos jest nie tak z odczytem zmiennych, albo VISA cos miesza.

jesli ktos zechcialby zagladnac w kod - serdecznie dziekuje.

pozdrawiam

[Mikrobi]

Proponuję następujące działania:
Włącz żarówkę: okno diagramu, piąty piaty przycisk licząc od strzałki uruchamiającej program (o nazwie "Highlight Execution")
Prześledź dzialanie programu.

Uporządkuj diagram - kod powinien mieścić się na jednym ekranie.

[ky3orr]

dzieki mikrobi za porade.

postaram sie pozamykac coniektore elementy w subVI.

sprobuje przesledzic dzialanie softu i opisze moje wrazenia

pozdrawiam

[ky3orr]

poprawiam ten diagram, ale w miedzyczasie przesymulowalem go i nasunely mi sie 2 pytania:

1. czy w czasie analizy dzialania kodu mozna wpisywac watrosci dla danych zamiast czekac na pojawienie sie poprawnie wygenerowanych przez program?

2. podczas korzystania z maszyny stanow gdy zamykam elementy VISA, a wykorzystuje shift register-y do przekazywania danych VISA, to w przypadku case w ktorym zamknalem VISA co mam przypiac do tunelu? czy nalezy dac jakies konkretne wartosci czy ustawic "use default if unwired"?

moj diagram wysypal sie wlasnie (zatrzymal, ale nie zakonczyl) w miejscu gdzie mial nastapic skok do kolejnego stanu, nastepnego po zamknieciu portow poprzez VISA close. dla tunelow VISA resource name i error ustawiona byla opcja use default if unwired...

a moze jest tak, ze powinno sie zajmowac zasoby jeszcze przed wejsciem do maszyny, a zwalniac je po jej opuszczeniu?...

[Mikrobi]

1. do kontrolek tak, do stałych oczywiście nie
2. tuaj wystarczy "Use def...", nie korzystasz dalej z tej informacji, ewentualnie podstawiasz ją od nowa, możesz ew. wstawić jakis komentarz, ale nie jest to tutaj konieczne
3. zasadniczo należało y otworzyć wątek VISA przed wejściem do maszyny jesli MStanów ma dzialac w taki sposó jak to wykonałeś, z zastrzeżeniem, że nie zmieniasz konfiguracji portu szeregowego.
Nie ma tutaj potrzeby ponownego inicjalizowania zasobów. Podobnie z zamknięciem VISA.

[ky3orr]

zaczalem sprzatac diagram i testowac program dalej i odkrylem dla czego wyskakiwaly mi bledy.

okazuje sie, ze podczas pracy nad rozbudowa maszyny stanow, gdy dodawalem i usowalem kolejne stany zapomnialem/przeo3lem wyedytowac jednego enuma co powodowalo ostateczne wywalanie programu, gdyz wartosc numeryczna odpowiadajaca tekstowej nie byla taka jakiej potrzebowalem do poprawnej pracy softu.

i tu nasowa sie pytanie w jaki sposob dobrze zarzadzac zmiennymi typu enum?

dodatkowo wprowadzilem klastrowanie danych podawanych na jeden rejestr przesowny zamiast kilku rejestrow co nie tylko ulatwia drutowanie, ale i poprawia czytelnosc kodu (bundle+unbundle by name).

poza problemem maszyny stanow mam takie pytanie: jesli zmieniam cos w Sub VI (np opis wyprowadzen) to w jaki sposob spowodowac by zmiany te byly widoczne w diagramie korzystajacym z tego Sub VI?

[Mikrobi]

Każdy enum powinien być kopiią jednej utworzonej przez ciebie kontrolki,
czyli typedef'em, elementem definiowanym przez programiste.
Tutaj Ben opisuje metode jej wykonania.