Aplikacja LabVIEW w postaci serwisu

[__behemot_]

Hej,

Zastanwiam się czy jest możliwe stworzenie aplikacji LabVIEW w postaci serwisu, uruchomic na wirtualnej maszynie i zlecac tylko jakies zadania lub miec odpalony serwis caly czas. Serwis mialby w moim przypadku wspierac komunikacje po TCP/UDP/UDPCP.
Wydaje mi się, że kiedyś podobne coś widziałam, ale nie wiem gdzie zacząć poszukiwania. Może ktoś już się z tym spotkał?

[Nowszy]

Witaj

Sposobów na osiągnięcie takiej funkcjonalności jest wiele i wybór konkretnej wymaga znajomości szczegółów aplikacji, wymagań, etc. Zawsze możesz stworzyć własną architekturę, powiedzmy Producer-Consumer, gdzie producent będzie odbierał komenty po sieci i przesyłał do konsumenta (-ów).

Inną możliwością jest wykorzystanie VI Servera i uruchamianie dynamiczne VIów za pomocą wbudowanej w LV funkcjonalności komunikacji z VI Serverem przez sieć (http://zone.ni.com/reference/en-XX/help ... g_options/ , https://decibel.ni.com/content/docs/DOC-6881)

[__behemot_]

Dziękuję za pomoc.
Zdecydowanie nadal nic nie wiem. (to nie sarkazm)

Założenie:
Celem projektu jest symulowanie urządzenia, komunikującego się po jednym z dostępnych protokołów: TCP/UDP/UDPCP w konfiguracji ustawionej przez użytkownika (endianity, port i inne specyficzne dla tego urządzenia). Użytkowników takiego symulatora jest wielu, jak również użytkownikiem jest inna aplikacja, która musi mieć możliwość przesłania danych konfiguracyjnych symulatora.
Symulator powinien działać jako proces ukryty, ale z możliwością uaktywnienia GUI. Symulator musi tworzyć logi i je gdzieś zapisywać (tu nie jest określone gdzie, ważne by było do nich dostęp).

Czy informacje te rozjaśniają sytuację? Czy łatwiej teraz określić najwłaściwszą technologię, architekture?
Samo oprogramowanie myślę, że nie będzie trudne, jedynie decyzja o architekturze :/

[Nowszy]

Witaj

Czy symulator będzie uruchamiany z aplikacji napisanych w LabVIEW, czy z różnych środowisk? Ja bym stworzył aplikację EXE która będzie nasłuchiwała na konkretnym porcie TCP i zarządzała wieloma klientami. Osobny port TCP (i inne) będzie stworzony do samej symulacji komunikacji.

Kwestia minimalizacji do Tray'a i inne jest raczej sprawą poboczną (dość stary artykuł, ale chyba nadal działa: http://digital.ni.com/public.nsf/allkb/ ... 250021D9FA). Na razie skoncentruj się na samej architekturze symulatora-serwera. Rozpisz sobie jakie pętle będą potrzebne, jak obsłużyć kilku klientów na raz, etc

[czab]

Nie wiem czy nie przekombinowałem, ale widziałbym to tak:

- Główny proces nadawczy/nasłuchowy pracuje sobie na komputerze jako demon, wywoływany z osobnego VI, Launchera.
- Demon pracuje w architekturze kolejkowanej maszyny stanów, gdzie kolejka przechowywana jest w Functional Globalu, dzięki czemu kolejne stany dodawane być mogą niezależnie przez Launchera i w samym demonie, w zależności od potrzeby. Docelowo w ten sposób mogą być także przekazywane dane.
- Launcher posiadać może opcję wywołania panelu frontowego symulatora. Konfigurację rozwiązać można albo przez wspomnianego globala, albo bezpośrednio na panelu frontowym symulatora/demona.

Nie wiem, czy nie mnożę tu bytów ponad potrzebę, jeśli jednak jest konieczność, żeby symulator pracował sobie w tle, może taka architektura warta jest rozważenia?

Załączam szkic tego, jak bym to widział. (odpalać proszę plik daemonTest.vi)