Polskie Centrum LabVIEW

Próbuję zrobić prosty program do akwizycji obrazu z kamery. Wykorzystuje framegrabber i wrapper dla LabView dostarczony przez jego producenta.

1. W pierwszej wersji programu (w Załączniku minimal_camera_code.vi) czas pobierania ramki z kamery jest bardzo wysoki i nie jest stały (kamera ustawiona jest na constant frame rate = 5ms, w sofcie producenta akwizycja odbywa się z prędkością 200fps)
Po dodaniu opóźnienia (rys. 2b) sytuacja poprawia się ale w pewnym momencie czas pobierania również przestaje być stały.

2. W drugiej wersji (w Załączniku minimal_camera_code2.vi) czas pobierania jest stały i wynosi dokładnie 1 ms po dodaniu "Wait until next multiple ms" = 25 ms (dodanie mniejszego powoduje to samo co w punkcie 1).

Rozumiem że problemy te spowodowane są ciągłym mieleniem pętli - spotkałem się już z tym problemem przy interfejsach użytkownika. Wynika to też z mojego niepełnego zrozumienia jak dokładnie wykonywany jest ten kod w LabView.

Proszę o jakąś propozycję rozwiązania, tak aby ramki były zbierane z kamerki w równych odstępach czasowych.

Hej! Mogłabym prosić o wrzucenie kodu w wersji 2012? Framegrabber'em bawię się już dłuższy czas i chociaż daleko mi do eksperta, mogłabym spróbować Ci pomóc

W załączniku kod dla wersji 2012.

Jeszcze kodów samego sterownika framegrabbera brakuje.

ed. Na szybko pomysł jeszcze: spróbuj wywalić ten IMAQ Array to Image i bez niego przetestować kod.

W sumie faktycznie dobrze byłoby wiedzieć co znajduje się w bloczku Grab8.vi Intuicja podpowiada mi, że może być tam IMAQ Grab Acquire.vi. Jeśli tak, to sprawdź co masz podpięte do wejścia Immediate.

Cytuję LabVIEW Help'a: "Immediate? determines if the system returns the image currently being acquired or the last completely acquired image. The default value is FALSE, which causes NI-IMAQ to wait until the current image is completely acquired before returning the image. TRUE returns the last acquired image."

Czyli jeśli masz podpięte True to pętla może obracać Ci się za szybko i ściągasz z farmegrabbera kilkakrotnie ten sam obrazek. Proponuję więc podłączyć False i wtedy kamerka powinna Ci trzymać równy rytm plucia obrazkami

No chyba, że nie masz tam IMAQ Grab Acquire... ;)

@PiDi : czas wykonywania IMAQ Array to Image jest przecież mierzony niezależnie, nie widzę tu żadnego powiązania i możliwości wpływu.

@Góras: W bloczku Grab8.vi znajdują się tylko odniesienia do .dll framegrabbera. Cała biblioteka do LabVIEW od producenta framegrabbera to tylko wrapper kodu napisanego w c.

Dzisiaj dostałem odpowiedź od producenta że LabVIEW nie radzi sobie z uzyskaniem prędkości powyżej 100 fps

Będę chyba próbował napisać jakąś aplikację w C i podłączyć ją do systemu pomiarowego zrobionego w LabVIEW. Jakiś pomysł na rozwiązanie tego? Pierwsza opcja to aplikacja przesyłająca obraz (do rozwiązania w jaki sposób komunikacja w LabVIEW), druga dane pomiarowe (nie będę mógł wtedy korzystać z Vision Development Module i wszystko trzeba będzie robić w OpenCV).

nie widzę tu żadnego powiązania i możliwości wpływu.

Nie widzisz możliwości czy z całą pewnością jednoznacznie stwierdzasz po przetestowaniu (tudzież autorytatywnie), że nie ma wpływu? ;P Spróbuj mimo wszystko usunąć IMAQ-owe rzeczy i sprawdź, czy coś się zmieni. Jeśli nie - wina na pewno sterownika. Następnie sprawdź, czy nie puchnie pamięć w czasie działania programu.

Dzisiaj dostałem odpowiedź od producenta że LabVIEW nie radzi sobie z uzyskaniem prędkości powyżej 100 fps

To niezłe: w jaki sposób LabVIEW sobie nie radzi? Skoro cały sterownik w LV to tylko wrapper dll-ki, to chyba jednak ta dll-ka sobie nie radzi?

Jeżeli mierzę czas wykonania IMAQ'owych rzeczy oddzielnie i odpalane jest to w sekwencji to chyba te czasy są tam prawidłowe?

Nie wiem tak dokładnie co się dzieje w LabVIEW, jak zarządza pamięcią, wykonaniem programu, event loopem.

Oprogramowanie producenta korzysta z tego samego sterownika, tej samej dll-ki i wyrabia. Taka była odpowiedź producenta, nie pytałem głębiej ale wydaje mi się że LabVIEW jest dosyć ciężkim środowiskiem, sam runtime może zabierać sporo zasobów i na nie real timowym systemie operacyjnym jakim jest Windows, jestem w stanie uwierzyć że jest to jednak związane z LabVIEW.

Widząc ironiczny ton twojej wypowiedzi prosiłbym o odrobinę więcej konkretów, np. w jaki sposób widzisz to inaczej. Czy myślisz że na prawdę nie może być to problemem zarządzaniem, optymalizacją kodu, bo do czegoś LabVIEW ten kod sprowadza itp?

krzych07 pisze:Jeżeli mierzę czas wykonania IMAQ'owych rzeczy oddzielnie i odpalane jest to w sekwencji to chyba te czasy są tam prawidłowe?

Obrazek w IMAQ jest referencją. To, co dzieje się wewnątrz IMAQ-owych bloczków bywa nieodgadnioną tajemnicą, szczególnie z punktu widzenia zarządzania pamięcią. Poza tym wyświetlanie obrazka IMAQ w kontrolce to już zupełna wolna amerykanka - ten obrazek jest asynchronicznie aktualizowany przez wątek GUI LabVIEW. Jeśli wpiszesz IMAQ Image do kontrolki raz, a potem wykonasz jakieś operacje na tej samej referencji obrazu, to w kontrolce obraz się zmieni jak tylko wątek GUI się o tym dowie (a nie jak zwykle - po wpisaniu nowej wartości do kontrolki). Więc tak naprawdę narysowanie obrazka na GUI może się zdarzyć kiedykolwiek w tym programie.
Proszę, żebyś przetestował ten kod bez IMAQ tylko po to, żeby wykluczyć jednego potencjalnego (choć mało prawdopodobnego) winowajcę.

Widząc ironiczny ton twojej wypowiedzi prosiłbym o odrobinę więcej konkretów, np. w jaki sposób widzisz to inaczej. Czy myślisz że na prawdę nie może być to problemem zarządzaniem, optymalizacją kodu, bo do czegoś LabVIEW ten kod sprowadza itp?

Naszła mnie jedna myśl, ale zanim się rozwinę, musiałbyś jednak wrzucić kody tego sterownika. Generalnie trochę alergicznie reaguję na stwierdzenia "a bo to w LabVIEW masz, to paaanie, to seee neee daaa" ;) Tym bardziej, że DLLka to prawie oddzielna aplikacja, LV ma niewielki wpływ na to, co ona robi (a że niewielki =/= żaden, dlatego proszę o kody).

No i teraz mnie przekonałeś z IMAQowymi rzeczami, bez wyświetlania już przetestowałem nie ma żadnych zmian, jak tylko będę przy sprzęcie spróbuję jeszcze bez konwersji do IMAQ.

To jest wrapper dla labview:
Korzystam z karty GrabLink Full

http://sine.ni.com/apps/utf8/niid_web_d ... 21287E6E02

Dzisiaj dostałem odpowiedź od producenta że LabVIEW nie radzi sobie z uzyskaniem prędkości powyżej 100 fps

Dziwne... Moje LabVIEW zbiera ramki wypluwane przez kamerę co 6 ms i bardzo dobrze sobie z tym radzi

Góras pisze: Dziwne... Moje LabVIEW zbiera ramki wypluwane przez kamerę co 6 ms i bardzo dobrze sobie z tym radzi

Inna kamera, inny driver, inny system ;). Ani ja, ani producent nie twierdzi że z LabVIEW jest coś nie tak, po prostu sprzęt ten w połączeniu ze sterownikiem działa dobrze obsługiwany z softu producenta lub z kodu, a optymalizacje i sposób wykonywania kodu w LabVIEW sprawia że nie da sie osiągnąć większej prędkości.

Możesz zamieścić kod zbierania z kamery? Używasz jakichś dodatkowych mechanizmów typu timed structure z priorytetami itd? Bo to będzie moja następna próba przed poddaniem się ;)

Inna kamera, inny driver, inny system ;).

Prawda, nie chciałam jednak, żeby pozostało na forum wrażenie, że czegoś się w LabVIEW nie da ;)

...optymalizacje i sposób wykonywania kodu w LabVIEW sprawia że nie da sie osiągnąć większej prędkości

Oj tam, oj tam ;) Jeżeli masz podejrzenia, że LabVIEW może się nie wyrobić ze ściąganiem ramek z framegrabbera, dobrze jest przy inicjalizacji stworzyć mu duży bufor (IMAQ Configure Buffer) plus (IMAQ Configure List).

Możesz zamieścić kod zbierania z kamery? Używasz jakichś dodatkowych mechanizmów typu timed structure z priorytetami itd?

Podziękowania przyjmę w lajku

Ok, sprawdziłem to dziś bez żadnych IMAQowych rzeczy, w pętli zostało tylko grabowanie z kamerki, ciągle bez zmian. Średnio wychodzi dosyć wysoki framerate, ale tak jak było widać na wykresach ramki nie są zbierane w równych odstępach czasowych.
Próbowałem jeszcze struktur czasowych, niestety nic to nie pomogło.

Cóż pozostaje mi chyba jednak powrót na niższy level ;)