Zbieranie danych pomiar. dla każdej iteracji pętli osobno

[dam100]

Cześć wszystkim.
Napotkałem pewien problem.
Od pewnego czasu usilnie próbuję napisać program, który będzie umożliwiał automatyczne wykonanie serii kilku pomiarów z jednoczesnym wyświetlaniem ich na wykresie (w czasie trwania tego pomiaru). Może przedstawię pokrótce o co chodzi:

Program przede wszystkim ma umożliwiać użytkownikowi określenie dowolnej ilości punktów, dla których realizowany będzie pomiar. Wprowadzone punkty pomiarowe mierzone są kolejno po sobie w czasie trwania pętli głównej programu. Pętla ta wykonuje się tyle raz aż osiągnięty zostanie pełny kąt 360 stopni. Wykresy dla każdego punktu powinny być kreślone na bieżąco w czasie trwania pomiaru. Dodatkowo użytkownik powinien mieć możliwość wybrania, który wykres chce oglądać w danej chwili.
Pierwszy program jaki napisałem umożliwiał wybranie max 4 takich punktów. Okazało się, że jest to nie wystarczające, zbyt "sztywne" rozwiązanie. Używam w nim struktury flat sequence. Nie jest to może zbyt fachowe podejście do problemu, a już na pewno mało optymalne. Program jest to tylko symulacja, powstała na potrzeby realizacji oraz testowania tego pomysłu. Jest dość intuicyjny i myślę, że będzie wiadomo o co chodzi. Załącznik: Program1.rar
Jest tam użyty SubVi, którego wywołuję do wprowadzeni danych pomiarowych.

Szybko zrezygnowałem z tego pomysłu na rzecz bardziej elastycznego rozwiązania. Zamiast flat zequence wykorzystałem pętlę for, która wykonuje się tyle razy ile użytkownik zadał punktów pomiarowych. Następnie tworze macierz, której kolumnami są kolejno wprowadzone pkt, a wiersze to kąt obrotu. Chcąc wyświetlić charakterystykę dla danej wartości używam bloczka Delete From Array Function. Usuwana kolumna jest wyświetlana na wykresie. Tak jak w pierwszym programie, klikając w listbox, użytkownik może wybrać odpowiedni wykres. Załącznik: wybór f_pętla FOR.vi

W tym miejscu mam do Was pytanie (na razie tylko jedno ):
1. Wybór dowolnego wykresu możliwy jest tylko w czasie wykonywania pomiaru (pętla while). Chciałbym dodać jeszcze taką funkcjonalność, aby wybór ten możliwy był także po zakończeniu pomiaru (poza pętlą while). Tu ma problem, ponieważ nie wiem jak to rozwiązać.
Wszelkie sugestie i porady mile widziane, nawet krytyka. Zdaje obie sprawę, że kod może nie być zbyt optymalny ;)

Pozdrawiam,

[elsys1]

Zastosuj maszynę stanów, do przechodzienia pomiędzy kolejnymi etapami wykonywania aplikacji

Inicjalizacja
|
Idle<--
| |
Pomiar--
|
Koniec


http://www.ni.com/white-paper/7595/en/

[dam100]

Hmm... Kolego, a mógłbyś to jakoś rozwinąć. Jak działa taki automat/maszyna stanów rozumiem, ale nie widzę zastosowania tego w moim programie. Nie występują tu różne kombinacje wykonania pomiaru. Przynajmniej na razie tego nie widzę.
Dodam jeszcze, że ten program, nad którym teraz pracuje, to jest jakby tylko część dużej aplikacji pomiarowej. Będę w niej dokonywał pomiaru także innych parametrów, dlatego wprowadzanych danych na początku będzie dużo więcej. Dlatego będę je chciał wprowadzać w osobnym SubVi i potem przekazywać do programu głównego.
Problem jest w samym etapie wykonywania tego pomiaru. Właśnie nie wiem czy da się jakoś "wyciągnąć" wykresy poza pętlę pomiaru, tak aby funkcjonalność wyboru wykresu do wyświetlenia dalej była aktywna.

[elsys1]

To, ze jest częścią wiekszej aplikacji nie ma znaczenia.
Jeśli to jest subVi to dane do niego mogą być przekazywane przez shift register poprzedniej iteracji.
Umiesc te dane w klastrze. Używając jakiejkolwiek architektury, można po wykonaniu pomiaru przejść do stanu w którym program będzie oczekiwał na akcje użytkownika.

[dam100]

Nie wiem czy akurat to miałeś na myśli, ale podsunęło mi to pewien pomysł. Robię jakby to samo ale poza pętlą pomiaru. Przez Property Node odwołuje się do odpowiednich kontrolek na panelu. Różnica jest w tym, że usuwając dana kolumnę tablicy, rysuje teraz cały wykres, a nie kolejne punkty.
Funkcjonalność została spełniona, jednak zastanawia mnie sam kod programu, czy takie działanie jest poprawne.

[elsys1]

Pod względem wydajności odwoływanie się do wartości kontrolek przez property node jest najmniej wydajne.
Lepsze są local variables.

Ale jak działa - to działa.

[dam100]

Pozwolę sobie kontynuować ten wątek, ponieważ problem dotyczy tego samego programu.
Otóż aplikacja pomiarowa jest gotowa. Wszytko działa jak powinno, ale tylko na laptopie, na którym pisałem program. Problem jest w momencie uruchomienia go na innym komputerze. W programie wprowadzam liczby dziesiętne z kropką, bo inaczej nie działa blok konwersji stringu na liczbę (Fract/Exp String To Number Function). Takie rozwiązanie mi pasuje, zapisu liczb z kropką.
Na innym komputerze jest odwrotnie. Nie mogę wprowadzić kropki w front panelu. Natomiast konwersja string na liczbę działa tylko z przecinkiem. Tak jakby kropki w stringu nie rozpoznaje i uzyskuję liczbę tylko do tej kropki. Przez co w programie wychodzą głupoty.
Próbowałem uruchamiać program na komputerze bez zainstalowanego LabView (przygotowany plik instalacyjny), a potem bezpośrednio plik VI, z zainstalowanym na komputerze LabView (ta sama wersja 2011). W obu przypadkach nie działa. Działa tylko na laptopie, na którym pisałem program.

Czy ktoś wie o co chodzi, dlaczego to tak działa, na każdym komputerze inaczej? Dla mnie to jest w ogóle duże zdziwienie, nie spodziewałem się takiego czegoś. Proszę o pomoc

[TMa]

Sprawa jest prosta. Zwróć uwagę na dwie rzeczy:
1. Ustawienia regionalne maszyn, na których uruchamiasz aplikację. Uruchom Control Panel-> Region and Language ->Format->Additional settings...->Numbers-> Decimal Point. Tutaj definiujesz ustawienia systemowe do obsługi liczb "z przecinkiem" w różnych aplikacjach. Wydajesz aplikacje na maszynie, która ma ustawiony decimal point na kropkę. A inni mają przecinek.

2. Używasz w kodzie VI które działają na ustawieniach systemowych ( w twoim przypadku Fract/Exp String To Number.vi ma terminal "use system decimal point (T)" ustawiany domyślnie na True).

[dam100]

Dziękuje kolego. Dokładnie to co opisujesz było przyczyną problemu. Zmieniłem ustawienia systemowe i teraz wszytko działa jak należy.
Będę musiał to jeszcze jakoś uwzględnić w programie, aby użytkownik nie zastanawiał się, czy musi coś zmieniać w ustawieniach systemowych.

[PawelR]

Cześć!

Ja sobie z czytaniem różnych separatorów dziesiętnych poradziłem, zamieniając w stringu kropki na przecinki, a przecinki - na separator systemu. To, jaki separator jest używany, sprawdzam dzieląc 11 przez 10; wynik zamieniam na string i usuwam jedynki. Proste, a nie trzeba wymuszać zmiany ustawienia systemowego. No i możesz użyć też np. Scan From String lub Spreadsheet String to Array, które już nie mają terminala "use system decimal point", o którym pisze TMa.

Powodzenia!
Paweł

[dam100]

Wszystko jasne, akurat z operacjami wykonywanymi na danych już sobie radze. Problem jest z wprowadzaniem tych danych w front panelu. W zależności jaki jest ustawiony separator dziesiętny, to tylko taki znak mogę wprowadzić do kontrolki. Trochę mało praktyczne to jest. W ostateczności dane będę wprowadzał w stringu i konwertował na liczbę.

[PiDi]

Wtrącę trzy grosze. Format znaku dziesiętnego w kontrolce numerycznej jest systemowy z jednego prostego względu - użytkownik systemu sam w ten sposób decyduje, jakiego znaku dziesiętnego chce używać. Wyobrażasz sobie sytuację, gdzie każdy program sam narzuca Ci swój własny format numeryczny, bo akurat programista był Polakiem, Amerykaninem, Niemcem, Szwajcarem, Chińczykiem...? Sprawa byłaby jeszcze prosta, gdyby rozchodziło się tylko o kropkę i przecinek, ale rzecz wcale nie jest taka prosta. Poniżej kilka formatów zapisu liczby w różnych krajach (pożyczone z prezentacji Stephena Mercera z NI):

Stąd rada: nie narzucaj użytkownikowi swojego formatu, bo użytkownik ma swoje przyzwyczajenia i każde takie narzucenie odbierze jako osobisty atak ;)

Inna sprawa to zapis do pliku. Jeśli pliki, których używasz, mają być przenoszone między różnymi komputerami, ale używane tylko w twoim programie, to w miarę łatwo nad tym zapanować. Format Into String umożliwia podanie formatu, a tam można wybrać sobie modyfikator decydujący o znaku dziesiętnym:

Localization Codes
Characters that determine if LabVIEW uses a decimal or comma to separate the whole number from the decimal part of the number. These codes control the decimal separator for numeric output. These codes do not cause any input or output to occur. They change the decimal separator for all further inputs and outputs until they find the next %;.
%,; Comma decimal separator.
%.; Period decimal separator.
%; System default separator. If you do not specify a separator, LabVIEW uses the system default separator.

Poszukaj w pomocy tematu Format Specifier Syntax. Wystarczy, że przy zapisie i odczycie twoich plików narzucisz ten sam znak dziesiętny rzeczonym modyfikatorem i problem znika.

Problem pojawia się, jeśli te pliki są przenoszone między komputerami i mogą być używane w innych programach (np. wczytane do Excela). I tu już nie ma jednego, mądrego rozwiązania, trzeba by dokładnie rozważyć kontekst twojej aplikacji.

[TMa]

Reasumując. Dane numeryczne przetwarzane w aplikacji (exe czy w LV) zawsze działają na separatorze systemowym. Użytkownik decyduje jedynie o postaci separatora w przypadku konwersji na string. Ma to znaczenie podczas zapisu/odczytu do/z pliku, obsłudze urządzeń poprzez ASCII, komunikacji poprzez wiadomości tekstowe czy wprowadzaniu danych numerycznych poprzez kontrolki tekstowe. Tylko wtedy użytkownik musi zwrócić szczególną uwagę na dobierany format.

Spreadsheet String to Array, które już nie mają terminala "use system decimal point",

A terminal "format string"?

[PawelR]

Racja, w ten sposób też można to ustawić - tak, jak pokazał PiDi.

[dam100]

Teraz już wszytko wiem. Rozwialiście moje wszelkie wątpliwości. Jak najbardziej ma to sens i teraz widzę zasadność takiego postępowania. Sprawa o tyle prostsza, że pliki zapisuje i odczytuje tylko w tym jednym programie.
W takim razie zabieram się za modyfikacje kodu, bo tego akurat nie uwzględniłem, a widzę, że jest to dość znaczące jeśli chodzi o możliwość uruchamiania programu na różnych maszynach.
Dziękuje Wam za pomocne uwagi, w razie dalszych problemów na pewno jeszcze się odezwę ;)