Ładowanie i wykonywanie subvi z listy

[oczekp]

Witam serdecznie, jako, że to mój pierwszy post to na wstępie chciałem się przywitać!
A przechodząc do tematu, ostatnio głowię się nad pewnym problemem, mianowicie chciałbym zrobić coś takiego:
mam program główny, który będzie korzystał z wybranych subvi. Chciałbym, żeby te subvi były wczytywane z folderu i dołączane do programu głównego, i istniała możliwość wyboru, które mają być wykonywane, a które nie przez użytkownika. Problemów mam kilka mianowicie czytałem, że niestety nie da się stworzyć case zależnego od ilości plików zawartych w folderze, chodzi o to by każdy kolejny case frame zawierał jeden subvi i w ten sposób mógłbym sobie dowolnie wybierać który chce wykonać.
Myślałem o czymś takim: wczytuję wszystkie ścieżki do plików z folderu o rozszerzeniu vi i wrzucam to tablicy. Umieszczam je, no właśnie i pytanie gdzie? Najlepszy byłby listbox opcją checkbox obok, tylko że nie widziałem czegoś takiego, a sam pomysł tylko na listboxa z opcją zaznaczania przez ctrl i kliknięcie kilku nie jest dla mnie intuicyjny:( Następnie wpisywanie zaznaczonych ścieżek plików do innej tablicy, zaś kolejno pętla for wykonywana z tymi subvi.

Taki ANSI algorytm wyglądałby mniej więcej tak:
wczytywanie wszystkich plików z rozszerzeniem vi z folderu->ładowanie nazw ścieżek do tablicy->tablice do listboxa z możliwością zaznaczania kilku elementów->czytanie zaznaczonych i wrzucanie do tablicy->pętla for wykonująca odpowiednie subVI.

No i właśnie mam tu kilka kolejnych pytań, czy to dobry pomysł, czy może znacie coś fajniejszego. No i drugie, to będą dość obliczenio-pamięciożerne subvi , więc chce je wywoływać za pomocą call by reference node. Powiedzmy, że wejścia będą zawsze takie same, ale np. wyjście już nie, da się dostosowywać to jakoś podczas działającego już programu. Albo np. czy da się by ilość wejść też się zmieniała. Ogólnie chcę się Was poradzić jak byście to zrobili.

To tak na szybkości zrealizowany program do tego:
Jest strasznie uproszczone, więc nie patrzcie na to, chodzi o to, że np wybierzemy sobie te pliki, klikniemy przycisk ok i zaczną nam się wykonywać wybrane subVi. I własnie jak je zmieniać albo wywoływać tak w locie. Nowa ścieżka, ładuje nowy subVi. Wejścia będą zawsze takie same, myślę, że wyjścia też. Bo zakładam, że tego to już by się nie dało zmieniać w programie. To co stworzyłem tu niżej działa całkiem ok. Ale to nie jest to co bym chciał tak do końca.


Jak coś niejasno napisałem to piszcie poprawię.
Za wszelkie sugestie i porady z góry dziękuję!

[oczekp]

to sobie sam odpowiem, może komuś się w przyszłości przyda. Myśl ogólnie jest podobna do tej co narysowałem. Czyli tworzy się listę wszystkich plików z rozszerzeniem vi w danym folderze wczytuję do listyboxa czy coś w tym stylu i następnie wybierając ładuję się przez call by reference node odpowieni vi. Właśnie taki przykład znajduję się w NI example w folderze Dynamically Loading and Calling VIs o nazwie Plug in Example.vi Więc jak kogoś interesuję to miłej lektury!

[vugie]

No i właśnie mam tu kilka kolejnych pytań, czy to dobry pomysł, czy może znacie coś fajniejszego. No i drugie, to będą dość obliczenio-pamięciożerne subvi , więc chce je wywoływać za pomocą call by reference node. Powiedzmy, że wejścia będą zawsze takie same, ale np. wyjście już nie, da się dostosowywać to jakoś podczas działającego już programu. Albo np. czy da się by ilość wejść też się zmieniała. Ogólnie chcę się Was poradzić jak byście to zrobili.

Możliwości są w zasadzie 3:
1. określasz sobie standardowe typy VI-ów i podczas otwierania starasz się je zidentyfikować (np. poprzez analizę błędu podczas kolejnych prób otwierania referencji za każdym razem z innym typem). Co prawda nie robiłem tak nigdy i węszę problemy z rzutowaniem typów przed Call by Reference (musi ono znać typ VI na etapie kompilacji)
2. Używasz wejść/wyjść typu Variant, które następnie rozpakowujesz do pożądanych typów (też trzeba jakoś zidentyfikować VI-je). Rozwiązanie chyba najprostsze i najpewniejsze.
3. Otwierasz referencję beztypowo, Za pomocą VI Servera (odpowiednie Property i Invoke Node) inicjalizujesz odpowiednie kontrolki (np. po nazwie), odpalasz VI metodą Run i po zakończonym działaniu zczytujesz kontrolki wyjściowe. Metoda ekstremalnie uniwersalna, choć pewnie bardziej niewygodna niż poprzednia.

[oczekp]

hej, dzięki za odpowiedź. Wypróbuję dzisiaj te metody w szczególności drugą:)

[Ender]

Witam
W załączniku propozycja rozwiązania. Największą jego wadą jest konieczność stworzenia case'a dla każdego subvi'a, co przy dużej ilości wywoływanych plików może być poważnym problemem. Nie ma za to problemu z jednakowymi wejściami i wyjściami we wszystkich wywoływanych plikach.
Sposób wywoływania poszczególnych subvi wybieramy kładąc subvi na diagramie, klikając na nim PKM i wybierając opcję 'Call setup' - na stronie NI wszystkie dostępne tam opcje są dokładnie opisane VI Call Configuration Dialog Box.
Może na coś się przyda.
Pozdrawiam
Ender

[oczekp]

Hej, dzięki za pomysł.
Mam prośbę mógłbyś zrzucić to do wersji 8.5 albo jakoś inaczej, bo nie mogę tego otworzyć:/

[Ender]

Mówisz i masz A na przyszłość dobrą praktyką jest podawanie w pierwszym poście posiadanej wersji LV, pozwala to uniknąć między innymi takich problemów ;)

[Pitol]

(...) A na przyszłość dobrą praktyką jest podawanie w pierwszym poście posiadanej wersji LV, pozwala to uniknąć między innymi takich problemów

Po lewej stronie przy nazwie użytkownika jest napisana wersja jakiej używa (jeśli oczywiście wypełnił te pola w swoim profilu). W przypadku oczekp widać, że korzysta z LV 8.5. ktoś jest leniwy i nie patrzy!!

[Ender]

Ups... to przez te upały

[wino]

Powiedzmy, że wejścia będą zawsze takie same, ale np. wyjście już nie, da się dostosowywać to jakoś podczas działającego już programu. Albo np. czy da się by ilość wejść też się zmieniała.

Możesz rozwinąć to zdanie bardziej? Dlaczego VI mają mieć różne wyjścia, możesz podać jakiś przykład?

[oczekp]

Dzięki Ender działa naprawdę fajnie, już wiem jak dalej to rozwinąć:). Co do różnych wejść,chciałem przed wyborami wskażnika rozbijać obraz na cztery tablice R,G,B i szarość i następnie takie dane do subvi. Problemem było to, że niektóre metryki bedą wykorzystywać tylko kanał szarości, a RGB nie. A chciałbym ładować te metryki na zasadzie pluginów z folderu. Rozwiązaniem na pewno byłby pomysł, że na wejściu zawsze mam typ image imaqa natomiast dla każdego pluginu oddzielnie rozbijam tablicę co mi jest potrzebne, zastanawia mnie tylko czy jak będę miał sporo tych wskażników czy to za bardzo nie spowolni działania programu.

[oczekp]

Mam jeszcze jedno pytanie w jaki najlepszy sposób wykonać strukturę dla takiej aplikacji:

Mniej więcej chodzi mi o takie działanie. Wczytuję ścięzkę do folderu z plikami źródłowymi, następnie wczytuję ścieżke z plikami po kompreji. Wybieram z załadowanej listy wskaźnik do policzenia. Jak mam wykonane te czynności to odblokowuję się przycisk licz, klikam wykonują się obliczenia w nowym subvi, ktorych wynik mogę zapisać do bazy danych bądź obejrzeć, albo po zapisaniu albo przed, to już dowolnie na jakimś tam podglądzie.

Wcześniej wykonałem takie coś jak w załączniku w event structure, ale nie wiem czy to poprawnie. Będe wdzięczny jak ktoś rzuci okiem.

[oczekp]

ok, trochę posiedziałem i poczytałem i zdecydowałem się na interfejs wg. while+event.
Zrobiłem mniej więcej coś takiego:

Wygląda to tak, że na początku wczytuje sobie subvi z folderu subvi, jak nie ma ich to zamykam aplikację, jak są to jadę do while i czekam na eventa. Tu wpisuję sobie ścieżke do pliku i wybieram wskaźnik z listy, naciskam przycisk policz. Uruchamia się subvi, które na wejściu ma sciężki do plików i wskaźnika a na wyjściu da mi obliczony wynik w postaci tablicy, którą to następnie będę mógł wyświetlać za pomocą przyciska wyświetl, czy tam zapisz do bazy. I tu pytanko, jest ok?:) czy nie?
Subvi licz wygląda mniej więcej tak:

Tak jak wspomniałem, na wejściu mam ścieżki do plików i ścieżkę do wybranego wskaźnika. Następnie wykonuje się kolejne subvi, którego zadaniem jest przerobienie ścieżki do plików na tablicę plików, które się znajdują w danym katalogu(chodzi o to, że wstępnie w głownym mainie podaję ścieżkę do folderu, w którym znajduję się n-plików o rozszerzeniu bmp, a następnie wczytuję do tablicy wszystkie ścieżki tych plików, które tam są). Kolejno wyrzucam z tego subvi te dwie tablice i dodatkowo kontroler błedu, taki, że jak 0 to znaczy,że ok, jak 1,2,3 to tam odpowiednie błedy wyświetlam. Kolejno wrzucam to na subvi wskażnika, które wybrałem w mainie. Po kolei, wczytuję jeden plik, następnie go przerabiam na tablicę w i takiej formie wrzucam do wskaźnika, który mi oblicza wskaźnik. Powtarza się to tyle razy ile jest plików w danym folderze. Całość jest zebrana w tablicę i przesłana z powrotem do maina. Tam gdzie ten wynik. No i tu kolejne pytanie, czy taki sposób przekazywania i wykonywania jest ok? Czy może zastosować tu coś bardziej profesjonalnego, albo rozwiązać to jakoś inaczej. Głównym założeniem jest to, żeby te subvi z wskażnikami, były jak najprostsze, żeby w razie co można było łatwo dopisać kolejny plugin i go wrzucić po prostu do folderu, gdzie jest reszta.
Mam jeszcze jedno pytanie, a dokładniej chodzi mi o to, że większość wskażników jest z odniesieniem materiału po kompresji i materiału źródłowego, ale jednak nie wszystkie. Niektóre korzystają tylko z materiału po kompresji. I zazwyczaj ich sposób obliczania polega na tym, że biorę pierwszy plik i porównuję go z następnym i dopiero wstawiam wynik do tablicy. Jak widać subvi z wskaźnikiem uruchamia się za każdym razem dla nowego pliku. A w jaki sposób zapamiętać poprzednią wartość, albo się do niej odnieść. Ja zrobiłem coś takiego:

Działa mi to, ale tylko wtedy, gdy w licz.vi nie dam close reference, o tu:

I tu mam też pytanie czy tak można, czy da się może jakoś inaczej, np stworzyć global variable do tej tablicy Array w licz i wykorzystać to w tym vi z wskaźnikiem. Czy może coś innego?
Jak ktoś to przeczyta to szacun mu za to:)
Pozdrawiam!

PS. jeszcze wykombinowałem takie coś:

I tu można spokojnie zamknąć reference, z tym, że wadą tego rozwiązania jest to, że muszę dla każdej metryki zrobić trzy wejścia. Wejście źródłowe, po kompresji i to zapamiętujące poprzednią wartość po kompresji. A w poprzednim przypadku miałem tylko standardwoo dwa.

[picia88]

Witam, mam taki sam problem jak kolega zaczynający temat, chcialbym tylko poprosić o programy kolegów Endera i Oczekpa na wersję LabView 7.1 bo w takiej muszę działac, Z góry dziękuję. Pozdrawiam