Przerwanie TCP Open

[jogurt_owocowy]

Hejka

Załóżmy, że mamy kawałek kodu jak na rysunku. Coś się dzieje w programie(pierwsza klatka sequnce), program dochodzi do drugiej, w której ma otworzyć połączenie TCP. Wejście timeout bloczka TCP Open jest ustawione na 20 sekund. Załóżmy teraz, że z jakichś powodów nie udaje się otworzyć połączenia, więc po upłynięciu 20 sekund bloczek zwróci błąd i przejdzie do kolejnej klatki. Ale jak zrobić, żeby użytkownik mógł anulować próbę otworzenia połączenia przed upływem tego czasu?

Z góry dzięki za pomoc, pozdrawiam.

[Mikrobi]

Proponuję bloczek nawiązujący połączenie zamknąć w pętli while i równolegle puścić pętlę samobójczą:
Uwaga: jeśli nie udało się nawiązać połaczenia - VI startuje od nowa (warunek zatrzymania: Continue while Error). Mozna oczywiście rozważyć inny powód zatrzymania tej pętli, ale należy to też przekazać przez zmienną lokalną do dolnej pętli.
Do przerywania pracy tego VIja proponuję zastosować to:

[jogurt_owocowy]

Dzięki za szybką odpowiedź (:
Jednak ten sposób jest jak dla mnie zbyt samobójczy. Może nie napisałem tego jasno przedtem, ale chodziło mi o to, żeby po anulowaniu przez użytkownika próby otwarcia połączenia, program nie wyłączał się, ale poszedł dalej, do kolejnej klatki (stąd ta struktura Sequence na rysunku).
Ostatecznie znośnym rozwiązaniem(na pewno lepszym, niż żadne) byłoby takie przerwanie działania programu, a następnie bezpośrednie uruchomienie go ponownie. Mam już ewentualnie jakieś pomysły na to, ale jak to zrobić najłatwiej?

PS. Aż żal, że w LV nie ma klocka "goto" ;)

[Blamek]

Jedyne co mi na chwile obecna do glowy przychodzi to albo eksperymenty z bloczkiem stop (malo eleganckie), albo kombinacje z VI Server (troszke zabawy, bo bloczek Run VI ma mozliwosc ustawienia opcji wait until done na false, jest to furtka do uruchomienia metody Abort VI, ale jest troszke zachodu z dobraniem sie do wartosci do terminali).

[Mikrobi]

Dzięki za szybką odpowiedź (:
Jednak ten sposób jest jak dla mnie zbyt samobójczy. Może nie napisałem tego jasno przedtem, ale chodziło mi o to, żeby po anulowaniu przez użytkownika próby otwarcia połączenia, program nie wyłączał się, ale poszedł dalej, do kolejnej klatki

ekhm.... :?
Czy górnego diagramu nie można zamknąć do subVIja, któren będzie działał jako TCP Open? Nawet wyprowadzając na zewnątrz parametry jak adres i port?
Owszem, powinien w razie zdalnego przerwania pracy generowac warrning (a nie error) o wymuszonym przerwaniu nawiązywania połaczenia, ale to już jest oczywiste.
Taki dwupętlowy subVI zwracający referencję do połaczenia TCP i error powinien rozwiązać problem o którym wspominasz. Przecież to taki bloczek będzie w takiej sytuacji siedział w tej ramce sekwencji.
Drugi diagram to drugi subVI, który uruchomisz lub nie. Należy jednak z niego usunąć pętlę while i wtedy jednorazowe wykonanie takiego diagramu przerwie pracę górnego "dwupętlowca"

[Mikrobi]

Jedyne co mi na chwile obecna do glowy przychodzi to albo eksperymenty z bloczkiem stop (malo eleganckie), albo kombinacje z VI Server (troszke zabawy, bo bloczek Run VI ma mozliwosc ustawienia opcji wait until done na false, jest to furtka do uruchomienia metody Abort VI, ale jest troszke zachodu z dobraniem sie do wartosci do terminali).

to jest rozwiązanie z grupy VIServer.

[Blamek]

Jasne zagalopowalem sie nieco, zamiast przejzec dokladnie to co napisales, kombinowalem z alternatywnymi rozwiazaniami.

Tak sie tylko zastanawiam ... piszesz zeby zamknac bloczek odpowiedzialny za polaczenie tcp w osobnym subVI, ale AbortVI nie zadziala, jesli wczesniej nie odpalimy tegoz subVIa za pomocą VIServer'a, wiec jednak chyba mamy to samo na mysli ...

[jogurt_owocowy]

Kurde, alem głupi :oops: Teraz jasne. Dzięki.

Pozdrawiam

[Mikrobi]

No tak...
:oops:
To jednak nie zadziała - bloczek z TCP-IP ma wyższy priorytet. idę się powstydzić... Wniosek jaki mi się nasuwa (...już klęcząc w kącie na grochu): nie ma takiej mozliwości programowej z chwilą kiedy sterowanie wejdzie do bloczka TCP. Abort VI powinien działać w takich warunkach. Powinien.

[Blamek]

Reasumujac rozwiazanko powinno wygladac mniej wiecej tak, z malym zastrzezeniem ... nie dobralem sie do terminala bledow z bloczka connect.vi (czyli jesli nastapi timeout to sie o tym nie dowiemy, no chyba ze posrednio, bo referencja do polaczenia bedzie niewlasciwa), ale nie to jest przedmiotem dyskusji, podobnie jak nie zaprzatalem sobie glowy co zrobic dalej z nawiazanym polaczeniem.

[jogurt_owocowy]

Panowie, dziękuje bardzo za wsparcie. Na razie poszedłem dalej w swoim programie, póki co użytkownik będzie widział "TCP Open-nic nie ruszać bo się zawiesi"(; Jak starczy czasu to do tego wrócę, a chyba będę musiał, bo resztą programu jest tak piękna, że takiego buga nie można zostawić

Pozdrawiam

[jogurt_owocowy]

..

[jogurt_owocowy]

No i wróciłem do tego, coś tam posiedziałem, podłubałem (dzięki Blamek za inspirację), ale pojawił się zonk.
Rzeczywiście da się w ten sposób przerwać działanie TCP Open, ale pojawił się inny problem: "(...)nie zaprzatalem sobie glowy co zrobic dalej z nawiazanym polaczeniem(...)" - a zonk pojawia się właśnie tutaj. Dalej np. można spróbować korzystając z utworzonego połączenia coś wysłać do serwera (załączony serwer.vi - po włączeniu czeka na połączenie i jak się takowe pojawi to czyta przychodzące stringi i wypisuje je w okienku). Pozwoliłem sobie trochę zmodyfikować Twoje pliki w następujący sposób Rys. 1.: connect2.vi - po wywołaniu otwiera połączenie "do siebie" na porcie 6342. Potem korzystając z odnośnika połączenia wysyła do serwera literkę C jak connect Rys 2.: terminate2.vi - po uruchomieniu connect2.vi wyłuskuje zawartość kontrolki odnośnika połączenia, więc korzystając z tego samego odnośnika połączenia wysyła do serwera literkę T jak terminate.
Doświadczenie robię tak:
uruchamiam serwer.vi a następnie uruchamiam sobie kilkukrotnie plik terminate. I można by się spodziewać, że sprawy potoczą się tak: 1. terminate2.vi uruchamia connect2.vi (i zatrzymuje się na invoke node bo Wait Until Done=TRUE) 2. connect2.vi otwiera połączenie (bo serwer działa), korzystając z utworzonego odnośnika wysyła do serwera literkę "C" i kończy działanie. 3. connect2 się zakończył, więc terminate2.vi idzie dalej, w strukturze case wyłuskuje odnośnik połączenia z kontrolki connect2.vi i za jego pomocą wysyła do serwera literkę "T". Wydaje się, że serwer powinien odbierać sekwencję C i T na przemian, ale tak nie jest (rys.3.) Tu właśnie robi się kuku, bo czasami TCP Write w pliku terminate2.vi działa OK, wysyła literkę i wszystko jest ok, a czasami zwraca błąd: 1-An input parameter is invalid.
Oczywiście ma do tego prawo, ale odnośnik połączenia jest taki sam(sprawdzałem) w connect2.vi jak i w terminate2.vi z czego wniosek, że błąd powinien się pojawiać równocześnie przy obu bloczkach TCP Write, tymczasem występuje tylko w terminate2.vi.
A mi się już skończyły pomysły dlaczego tak może być :/
Pozdrawiam

[jogurt_owocowy]

...