Polskie Centrum LabVIEW

Witam

Komunikuję się z urządzeniem przy wykorzystaniu protokołu TCP/IP. Do urządzenia wysyłam co np. 100ms komendy-zapytania składające się ze znaków ASCII i odbieram wysyłane przez urządzenie odpowiedzi. To niejako dzieje się cały czas w tle od momentu uruchomienia aplikacji i wciśnięciu przycisku Start. Pod inne przyciski chciałbym podpiąć inne komendy które wysyłane byłyby tylko po wciśnięciu danego przycisku. Nie wiem jak to pożenić. Masakra !

Pozdrawiam

Pokaż diagram. Przynajmniej będziemy mogli coś doradzić bo bez tego to jedyną rzeczą jaką mogę powiedzieć to to że użyłbym maszyny stanów lub ew. zmodyfikowanego producer consumer (events) - dodana dynamiczna zmiana timeoutu w dequeue element przy naciśnięciu start.

Do tego pytanie - czy wysyłanie danych co 100ms może zostać przerwane przyciśnięciem innego przycisku? (tj. czy można opuścić jeden cykl)

Wyraz "ZAPYTANIE" wysyłany jest co 100ms do urządzenia

Wolałbym aby nie przerywać wysyłania głównego zapytanie co 100ms. maksymalnie wysyłane będzie kilkanaście góra kilkadziesiąt bajtów zapytania. Można policzyć, że wysłanie nawet tysiąca bajtów danych trwa dużo krócej niż 100ms. W odpowiedzi od urządzenia też jest kilkanaście góra kilkadziesiąt bajtów danych. Na razie pozwoliłem sobie ukryć właściwe zapytanie - po skończeniu tego projektu umieszczę cały program na tym forum.

Jeszcze jedno pytanie - czy w tym protokole jest jakiś mechanizm rozróżniający że dana odpowiedź jest do konkretnego zapytania. Chodzi mi o to, że jeżeli pierwsze zapytanie wysłałem i zaraz za nim drugie zapytanie i zdarzyło by się, że odpowiedź na pierwsze przyszła później niż odpowiedĹş na drugie to system rozróżniłby do którego zapytania tyczy się odpowiedĹş nawet w skrajnym przypadku gdyby obydwa zapytania były takie same ?

Więc jeśli chodzi o przyciski. W podanym przykładzie pokazałem standardowy pooling jaki się używa do przycisków. Powinieneś teraz dojść jak to zrobić. Jedna uwaga - przyciski przynależą do dodatkowych komend a nie do komendy start.

W przykładzie z klastra odczytuję dwie różne wartości które mogą być Ci potrzebne przy tworzeniu programu. Powodzenia.

Jeśli chodzi o TCP to nie ma możliwości identyfikacji zapytania - przynajmniej ja nic o tym nie wiem. Możesz zdefiniować własny protokół danych i stosować jakieś znaczniki lub np. używać sekwencji CRLF przy odczycie. Zobacz w dokumentacji do TCP Read / TCP Write.

Żeby to było po bożemu, to badanie, która komenda została naciśnięta itp. powinno się robić wewnątrz eventu Value Change. Na polling przycisków wraz z wersją 6.1 zaczęła spadać zasłona zapomnienia i niech tak zostanie.

Jeśli założymy że trzeba coś wysłać dodatkowo w pętli (jednej) to myślę, że pooling będzie najlepszy. Stosowanie eventu w takiej sytuacji mija się z celem i tylko zaciemni całą sprawę. Do tego jeszcze mamy 100ms - całą wieczność

Wysyłanie danych w jednej pętli załatwi nam synchronizację bo można założyć w programie odbierającym, że coś może jeszcze przyjść po zapytaniu i wiemy dla którego zapytania nastąpiła dodatkowa komenda.

No ale niestety nie znamy całości założeń do programu. Ale jak już napisałeś o eventach to pokaż koledze o co chodzi. Ja idę spać bo o 5:30 pobudka :/

oto się właśnie rozchodzi, ale jest kolejny problem nie wiem jak stworzyć tabelę składającą się z trzech komend ASCII np. "ZAPYTANIE1", "ZAPYTANIE2", "ZAPYTANIE3" i jak je wybierać napisaną przez ciebie procedurką.

na diagramie:
1) wybierz z działu array pustą tablicę
2) z text pusty bloczek tekstu
3) wrzuć bloczek w pustą tablicę to powstanie tablica tekstu
4) z array weź bloczek index array i zobacz w helpie jak działa

Jeśli założymy że trzeba coś wysłać dodatkowo w pętli (jednej)...

A dlaczego nie zrobić tego wysyłania w dwóch pętlach? Dlaczego nie w trzech, jeśli tyle potrzeba? Nie należy tego robić w jednej pętli tylko dlatego, że jest to możliwe. Stosowanie eventu nie mija się z celem, bo właśnie taki jest cel eventów - reagowanie na zdarzenia z interfejsu.
Załóżmy, że za chwilę zmieni się co nieco w projekcie i zapytania do urządzenia będą wysyłane nie co 100 milisekund, a co 2 sekundy. I teraz "całą wieczność" czeka poirytowany użytkownik na wybicie przycisku i się zastanawia, czemu się mu program zacina.

Oczywiście, że można. Ale z tego co widzimy kolega nie ma doświadczenia w LabVIEW i tak mu będzie najłatwiej to ogarnąć (chyba). Zresztą ja już bez producer-consumer z eventami lub ew. maszyny stanów nawet nie zaczynam projektu, bo zastosowanie poprawnego design pattern to podstawa.

Abstrahując od tematu podziału aplikacji na pętle (wątki) obsługi interfejsu i komunikacji do wersji 6.1 jogurcie_owocowy (mniam mniam :0) radzono również sobie doskonale z obsługą GUI bez eventów i skoro NI uznaje, że w wersji Basic 8.x nie są one potrzebne to znaczy że nie są niezbędne i niezastąpione.
Bardzo mnie irytują porady "wrzuć sobie eventa, semafora i dequeue" dla gości, którzy dopiero co odpalili LV i chcą tylko odpytać przycisk START, STOP i KONIEC.
Rumcajs.

Bardzo mnie irytują porady "wrzuć sobie eventa, semafora i dequeue" dla gości, którzy dopiero co odpalili LV i chcą tylko odpytać przycisk START, STOP i KONIEC.

Najprościej zaświecić lepszym przykładem. Nigdzie w tekście nie widzę nic ani o "dequeue" ani o semaforach. O strukturze event owszem, bo właśnie od początku nauki (czegokolwiek) należy sobie wyrabiać dobre nawyki, a do takich niewątpliwie należy obsługa interfejsu za pomocą eventów w LabVIEW.
To, że w wersji Basic ich nie ma, świadczy właśnie o ich przydatności. NI to chyba nie dobra wróżka dająca za darmo wszystko, co "niezbędne i niezastąpione".
jabu
Po przeszukaniu forum pod hasłem producer consumer znajdziesz między innymi POST z rozwiązaniem problemu bardzo podobnego do Twojego:


Pozdrawiam

Drogi Jogurcie,

- proszę spojrzyj na na pierwszą odpowiedź na niniejszy wątek Jarq, jest tam mowa o dequeue,
- podejrzewam, że NI specjalnie nie dodało do wersji Basic (nie darmowej) obsługi eventów, aby nie rzucać początkujących programistów na "głęboką wodę" - tak również jest praktykowane w innych językach wysokiego poziomu, że obsługa zdarzeń jest dla zaawansowanych użytkowników.
- zobacz proszę do jakich absurdów dochodzi w tym poście, chodzi mi o poszukiwanie przez siewnikdr rozwiązania najprostszego zadania jakim jest podłączenie indykatora LED do kontrolki typu przełącznik (za pomocą struktury event ?!) oraz przykładu powerled.vi przedstawionego przez AzazeL na widok którego jeży mi się włos na głowie - to nie jest "wyrabianie dobrych nawyków".

Przepraszam, jeżeli uraził Cię mój poprzedni post ale nie był on skierowany przeciwko konkretnej osobie a raczej próbą zauważenia i skomentowania pewnych zjawisk.
Pozdrawiam.
Rumcajs

Taki sobie luźny komentarz. Biję się w piersi (własne) bo OT.
Basic nie dlatego jest Basic, żeby było dla początkujących programistów, tylko żeby było tańsze. Takie LV dla ubogich.
A struktury event mimo, że jest to ciut bardziej zaawansowany poziom, to pozwalają na wykanaie pewnych zadań PROŚCIEJ niż gdyby ich nie było.