Komunikacja Host Target

[Space_Monkey]

Mam problem z aplikacją RT. Gdy uruchomię ją z labview wszystko działa(choć trwa to koło minuty zanim wszystko zadziała tak jak powinno - to normalne?). Natomiast gdy wyrzucę ją do *.exe i wyśle na Target, Host odbiera tylko jedną "paczkę" danych i wyświetla je jako bierzące przez cały czas.
Czy ktoś miał już podobny problem?
Jak go rozwiązać?
Jak zdiagnozować co się dzieje?

Target to PC AMD XP
LabView 8.2

[Mikrobi]

Fusy, fusy będą dobre. Kurze wnętrzności są przereklamowane. A szklana kula wszystko wykrzywia.
A teraz konkretnie: konfiguracja komputera mówi nam o tym, że masz na czym programować, co więcej wiemy że masz środowisko LabVIEW8.2. Jest tylko jeden problem. Dalej nie widzimy twojego kodu, zatem każda odpowiedź będzie wieszczeniem lub wróżba.
..aaa...zapomniałem o Tarocie dla proGramistów... O tak, to powinno zadziałać. 8)

[Space_Monkey]

Ha! Ha! Ha!
A tak na serio - nie wysłałem kodu bo uznałem że skoro działa pod projektem to znaczy że jest ok...i wydaje mi się że to problem sprzętu. MAX nie zgłasza żadnych problemów ,z komunikacją, ani przy wysyłaniu danych, ani przy konfigurowaniu Target'a, ani przy wgrywaniu oprogramowania. Jednak przy próbie testu Target PC programem na USB (utworzony w MAX) pojawia się błąd przy inicjowaniu połączenia sieciowego. Karta (Intel 82558) jest sprawna - sprawdzona w innym PC.
Pozdrawiam i dziękuje za odpowiedz!

[Space_Monkey]

Dwa słowa:
Windows firewall

Sprawa zamknięta!

[Mikrobi]

Gratulujemy
I dziękujemy za informację.

[Space_Monkey]

Dodam tylko że po wyłączeniu Firewall'a , Target nadal nie przechodzi pomyślnie testu kompatybilności z kartą sieciową, choć wszystko pod labview gra i buczy:)

[Space_Monkey]

Jednak nie do końca wszystko jest OK. Jak napisałem w pierwszym poście, program rusza po około minucie. Zapytałem wtedy - czy to normalne. Niedawno dowiedziałem się że nie.
Problem wygląda następująco:
Komunikacja między Hostem a Targetem rusza dopiero po około minucie od startu aplikacji. W międzyczasie na pulpicie Targetu pojawiają się kilka razy informacje z Hosta ale dopiero po około 60 sekundach komunikacja nabiera ciągłości.
Testowałem wszystkie ustawienia karty w MAX'ie. Ostatnio zainstalowałem Trace Execution toolkit i wyszło na to że na początku wykonywanie pętli (głównej i komunikacyjnej) jest "rozjechane", tj.
pierwsza wykonuje się główna (zadeklarowane 30 iteracji)
a następnie druga.

WHY?

[Koza]

Witaj,

Wygląda na to, że system nie zdążył wgrać wszystkich sterowników a już odpalił exeka. Widziałem kiedyś podobny problem. Rozwiązanie było banalne - wstawić przed całym głównym kodem bloczek wait z dopiętą stałą o wartości (u Ciebie) ca 60 sekund.
Jeśli możesz, podaj jaką masz płytę główną i jakie parametry komputera (RAM, procesor, etc).

Proszę też o informację, czy "opóźniacz" rozwiązał problem.

Pozdrawiam,
Koza

[Mikrobi]

Wygląda to dla mnie tak:
Pętla główna ma priorytet 1000, komunikacyjna 750.
Brakuje kolejności startu/synchronizacji pętli. Przez to pierwsza startuje pętla o wyższym priorytecie, wykonuje się, a potem dopiero puszcza pętle komunikacyjną.

Jeśli chcesz nawiązać komunikację, proponuję pierwszy kontakt host-target wykonać przed startem pętli timowanych. Da to czas silnikowi zmiennych współdzielonych na zestawienie komunikacji.

Mogę sie oczywiście mylic, nie mam tutaj RT żeby to sprawdzić, ale może poskutkuje.

[Space_Monkey]

Dzięki za szybką odpowiedz

Do Kozy:
Wywnioskowałeś że system nie zdążył załadować sterowników z przebiegu Trace Execution, czy strzelasz? Ja raczej nie orientuje się za co odpowiada większość procesów tam wypisanych, ale zauważyłem że to nie ma znaczenia czy system startuje z EXE jako programem rozruchowym czy pare minut po starcie RT Target'a testuje na nim program - czyli wyrzucam VI'a na Target. W obu przypadkach opóźnienie występuje.
Komputer to PC na:
AMD XP 1,25GHz
512 DDR (Dual)
Płyta - ASRock K7NF2-Raid
Sieciówka - Intel SB82558B (PCI)

Onboard LAN,audio i USB disabled.

Do Mikrobi:
Proszę wybaczyć ale jestem Lamą i jak Lama myślę,więc...
wydaje mi się skoro między kolejnymi wykonaniami pętli głównej procesor nie jest przydzielony do innych zadań (czyt. jest wolny) to nie przeszkadza to w tym że w międzyczasie mógłby wykonać i drugą pętle. Panowie z NI mówią że powinno działać od razu, czyli że SVE nie powinien tu wadzić.
Jak zsynchronizować te pętle? Randezvous?

Pomysłów jeszcze nie testowałem ale na pewno to zrobię i Wam opisze, chciałem tylko teraz uzupełnić info i namieszać trochę ;)
OK!
Teraz wypinam Internet i podłączam RT
Pozdrawiam

[Mikrobi]

Masz dwa bloczki RT-HOST i HOST RT.
Co jest w środku?
Możesz je wywołać wcześniej i przesłać jedną wartośc tam i z powrotem?

[Space_Monkey]

Wykonałem kilka prób: umieściłem przed pętlą główną "wait" i obserwowałem ile iteracji (pętli głównej i sieciowej) musi upłynąć zanim zostanie nawiązana komunikacja. Czas podpięty do Wait wpływał odwrotnie proporcjonalnie do ilości iteracji wykonanych przed nawiązaniem komunikacji i stosunek ten był stały. Czyli stały jest też czas jaki program zużywa na nawiązanie komunikacji (czuję że nadużywam tego zwrotu).
Próbowałem też pobudzić komunikację przez wielokrotne wywołanie pętli z wymianą danych (Host->RT i RT->Host) ale nie to nie dało.

W RT-Host jest wymiana danych ze zmiennych będących w pętli głównej (FIFO) do zmiennych współdzielonych sieciowo. W projekcie, w programie Hosta jest mirror tych zmiennych (bind to source).

Co dalej?