Polskie Centrum LabVIEW

teraz przedtsawiam wszystko poukladane, fakt byl w nim troszke balagan bo na szybko z niego wycinalem niepotrzebne rzeczy

No dobra. I co ma się tutaj dziać, a się nie dzieje?

nie moge przechwycic danych z urzadzenia ktore daje mi odpowiedz w drugiej petli bo mi zaraz znikaja, w petli gdzie nastepuje komunikacja jest to latwe ale zeby przekazac dane do drugiej to mi za nic nie wychodzi i przez to nie moge przeprowadzic ich analizy

Czy sprawdzałeś na żarówce w jaki sposób działa program ?

za bardzo nie rozumiem pytania, chodzi o kontrolke enter? teraz nie mam mozliwosci sprawdzenia tej komunikacji a w pracy bede w piatek albo poniedzialek wiec wtedy sprawdze, chociaz prosciej byloby gdybym wiedzial co jest zle (no chyba ze chodzi o brak polaczenia w Case przy false ale to dopiero sprawdze w pracy bo tam tez robie ten program)

włacz żarówkę i sprawdz co w kolejnych krokach wykonuje program, jak reaguje na eventy i jak działa przesyłanie danych miedzy pętlami. Krótko mówiąc czy to co widzisz to działanie jakiego oczekujesz.
...z tradycyjnym "miejcie odwage posługiwać się żarówką!" Wasz Zrzęda

Tak szczerze mówiąc to najlepiej byłoby ten program stworzyć od początku. Lepiej na początku przemyśleć dokładnie strukturę programu niż się potem męczyć. Może w Twoim wypadku dobra byłaby architektura Producent/Konsument (rys.). Pętla górna obsługuje zapis/odczyt danych do/z portu, a pętla dolna służy do przetwarzania danych. Użycie kolejki sprawia, że żadne dane Ci nie "znikną".
Objaśnij najlepiej dokładnie co program ma robić to się coś dobrego wtedy wymyśli.

O kurcze, tylko nie od poczatku, tyle nad tym siedzialem i do tego jeszcze tyle Was meczylem zwlaszcza ze ja dopiero tak naprawde raczkuje w LabView.
Ogolnie moj program ma wysylac wartości m.in napięcia, pradu z kilku pokretel, za pomoca przycisku (wyslij) lub entera do urzadzenia. W chwile potem urzadzenie powinno wyslac odpowiedz zwrotna ktora musze wylapac, przeanalizowac i podjac odpowiednie dzialania (wyswietlic komunikaty o bledach, ponowic wysylke danych itp. itd.) Do tego celu mam uzyc polaczenie ze pomoca rs i usb (w zaleznosci od wyboru uzytkownika). Mam nadzieje ze przy usb nie bede musial duzo zmieniac skoro juz tyle sie mecze z rs'em. Najprosciej byloby to mi wrzucic do jednej petli ale chyba takie rozwiazanie nie byloby dobre.
Czyli od czego powinienem zaczac? a tak juz sie cieszylem ze mi dobrze wychodzilo ...

pozdrawiam wszystkich cierpliwych

Zostawienie programu i zrobienie go od początku to często dobra metoda, zwłaszcza jeśli jest pomysł jak zrobić program efektywniej. Warto poznać rózne metody rozwiązywania jednego problemu zwłaszcza na początku pracy z LabVIEW, kiedy jeszcze nie ma się własnych nawyków ;) Pomysł jogurta jest dobry, pomysł do tego: pętle konsumenta wyposażyć w case: nadawanie - odbiór sterowana przez producenta.

Myślałem raczej nad czymś takim, że pętla producenta odpowiada za wysyłanie i odbiór danych, a pętla konsumenta za przetworzenie danych otrzymanych.
Albo jeszcze inaczej: są trzy pętle, z których jedna odpowiada za obsługę eventów użytkownika, druga za wysyłanie/odbiór np. jako maszyna stanów nie rób nic->wyślij->odbierz->nie rób nic->nie rób nic->..., która jest ze stanu "nie rób nic" pod wpływem pętli sterującej przechodzi w stan "wyślij"-wysyła, następnie przechodzi w stan "odbierz" i nasłuchuje odpowiedzi. Jeśli ta nie zostanie odebrana np. po 10 próbach, wyświetla komunikat, ponawia próbę wysłania danych itp. Po odebraniu odpowiedzi za pomocą kolejki albo notyfikatorów informuje o tym trzecią pętle analizującą odpowiedź, a ta w zależności od tego podejmuje odpowiednie decyzje, steruje pętlą wysyłająco-odbierającą itd.
Dziś niestety nie mam czasu, ale około soboty postaram się o stworzenie jakiegoś viaja przykładowego.

Tymczasem powodzenia i pozdrawiam:)

Ooo to jest całkiem inna metoda, bardziej skomplikowana niż ta co ja próbowałem robić. Jogurt byłbym wdzięczny jakbyś mi pokazał przykładową aplikację do rs (nie za bardzo skomplikowaną) z architekturą Producent/Konsument bo szczerze mowiąc ja nie za bardzo mam pojęcie co gdzie powinno być i może łatwiej bedzie mi przerobić mój program tak aby działal bardziej niezawodnie. Dzięki za pomoc!

Chcialbym ponowic jeszcze raz prosbe do jogurta w zwiazku z tym przykladowym vijem. Zalezy mi na tym, bo ta komunikacja ciagle mi nawala i nie moge przez to dalej ruszyc.
pozdrawiam

Przykłady takich struktur masz do wyboru po uruchomieniu LV, gdzie możesz sobie wybrać gotowe Templatesy, m.in. Producer/Consumer ...

bogdani

Wybacz niedotrzymanie słowa, ale wczasy mi się przedłużyły
A przykładowy vi w załączniku. Pierwsza pętla obsługuje interfejs użytkownika, druga-odpowiada za wysyłanie i odbiór danych. Jeśli jest w stanie "wyślij", to program czeka, aż w kolejce pojawi się coś do wysłania(timeout w Dequeue Element ustawiony na -1). W momencie gdy się "coś" pojawi wysyła to coś, a następnie przechodzi do stanu "odbierz" czekając na odpowiedź urządzenia. Po odebraniu takowej przechodzi ponownie do stanu "wyślij". Oczywiście przejścia pomiędzy stanami mogą być dodatkowo uzależnione od innych czynników(odpowiedź poprawna/niepoprawna, jej brak itp.)-tu jest najprościej jak może być.

Nie wiem czy akurat taka architektura programu jest najlepsza w Twoim wypadku, ale na pewno lepsza, niż "wrzucenie wszystkiego do jednej pętli".

alez nic nie szkodzi

wielkie dzieki )))) moglbym tylko prosic to samo w wersji 7.1 to zaraz sprawdze bo w pracy tylka taka posiadam (8 stacila waznosc:))