Polskie Centrum LabVIEW

Dziękuję za odpowiedzi. Pozwolę sobie jeszcze troche podrążyć ten temat. Wymienione zostały tylko dwie firmy DEPLHI i TPSA (telecom) - czy ktoś zna inne firmy w Polsce, które stosują LabView? Mowa wcześniej była cytat: "50 największych firm w Polsce używa LabVIEW ".

na przykład National Instruments Poland a tak na poważnie, coby reklamy nie robić, to google polecam i wpisz sobie LabVIEW +praca... conieco Ci sie wyświetli.

Dziękuję za pomoc. Faktycznie w google pojawia się szerego ofert, w których poszukuje się osób programujących w LabView. Ja jestem jednak bardziej zainteresowany tematem stosowania takich rozwiązań w polskim przemyśle. Czy ktoś się orientuje gdzie jest dostępna lista referencyjna polskich firm stosujacych środowisko LabView w przemyśle? Bardzo zaciekawiło mnie stwierdzenie, że "50 największych firm w Polsce używa LabVIEW " - chciałbym to zweryfikować, czy tak faktycznie jest, bo zaczynam w to wątpić. Przepraszam, że może kogoś urażę, ale nie wierzę w tę informację. Myślałem, że jest to obiektywna informacja poparta jakimiś danymi, ale wygląda, że jest to tylko opinia bez pokrycia.

Trochę mylące może być rozumienie tego, że jest to tam głowne środowisko programowania.Faktem jest jednak, że Duże Firmy środowisko takie posiadają i stosują.
Pytanie o to które to firmy należy zadać bezpośrednio NI PL, bo labview.pl nie jest oficjalnym organem NI Poland, tylko <proszę wstać, oklaski> prywatną inicjatwyą Bogdana Iwińskiego z firmy ("...")</oklaski, proszę usiąść>
NI Poland to przedstawicielstwo konkretnej firmy. Osadzone w Polsce od kilku lat i nie stosuje kiepskiego podejścia reklamowego typu zawyżanie wyników sprzedaży.
Zresztą 80 licencji to na prawdę nie jest duży wolumen sprzedaży
Biorąc za przykład TPSA: na pewno są miejsca w których słowo LabVIEW nic nie mówi pracownikom. I zaprzeczą oni, że jest tam stosowane. Podobnie w wielu innych firmach.
Gdzie zatem się stosuje LabVIEW? Ujmę to w ten sposób - tam gdzie jest to uzasadnione. Spektrum środowiska jest szerokie - od laboratoriów, po ciągłą produkcje. Warto zaznaczyć, że występuje ono jako narzędzie, nie jako główny wątek producyjny czy usługowy firmy. Często LabVIEW to aplikacja obsługująca pewien fragment produkcji, np. kontrolę jakości pewnego parametru produktu. Niestety jak na warunki przemysłu i konkurencji jest to często informacja rzekłbym "niejawna". W jednym z projektów zażyczono sobie wprost podpisania oświadczenia że nie będę infromował o tym dla kogo i jakiego typu aplikację wykonywałem.
Przez 120 miesięcy. Prośby takie lub aneksy do umów to nie są odosobnione sytuacje.
Mamy tutaj profesjonalistów pracujących w LabVIEW.
Nie jest to Osiemdziesięciu Delegatów Największych Firm w Polsce, ale stanowili by oni pewną część tej Grupy ;) Oczywiście mogę zapytać każdego z nich prywatnie czy mogą mówić o tym gdzie są zatrudnieni, ale jeśli sami się nie przedstawiają to jest to przecież ich prawem i prawem forum internetowego.

Mikrobi jak zwykle dobrze napisał.

Wiele firm się tym nie chwali, bo nie jest to ich główne narzędzie, a tylko fgragment procesu produkcji/testowania. Dlatego też więcej informacji można znaleźć na forach dyskusyjnych, informacjach i targach.
Przy okazji zapraszam na Automaticon

bogdani

wracajac do glownego pytania "szarego studenta" ...
moge powiedziec Ci czego na pewno nie zrobisz w LV.
1) na pewno nie zastosujesz go aplikacjach medycznych. zarowno oprogramowania jak i sprzetu. przyczyna - brak certyfikatow medycznych, tak wiec wszystko stosujesz na wlasna odpowiedzialnosc.
2) duzym bledem ze strony firmy NI jest skrajnie mala aktywnosc w zakresie przenoszenia (uproszczonego i ograniczonego oczywiscie) kodu do ukladow FPGA i mikrokontrolerow. LV-FPGA i LV-Embedded to pierwsze dosc niesmiale kroki w tym kierunku. i raczej nie udane. tak wiec jesli gdzies nie mozna postawic komputera to albo co najmniej sterownika programowalnego to tam tez nie zastosujesz LV.

mgawlik: co do LabVIEW Embedded: wiesz, nie od razu Kraków....czy też Rzym. Biorąc pod uwagę to co robi obecnie NI i iSystems to można się spodziewać kolejnego przewrotu w programowaniu. NI szykuje nie tylko kolejne Virtexy (gołe bramki pisząc w uproszczeniu) ale i Spartany czyli FPGA z rdzeniem mikroprocesorowym. Bare Metal LabVIEW czyli środowisko osadzane bezpośrednio wsprzecie - w procesorach jest już przygotowane na 32bitowe jednostki Axioma i Intela (i nie tylko).
A oparta na Virteksie karta NI7811R bardzo dobrze sprawuje się w pewnych rozwiązaniach.
...zapewne w innych gorzej, nie udało mi się jej skłonić np. do parzenia porządnej herbaty
;)
Moja odpowiedź dla studenta jest taka: warto uczyć się LabVIEW, warto w to wchodzić i inwestować swój czas. Po pierwsze - jest to bardzo wygodne środowisko pracy.
Po drugie: to środowisko ewoluuje. Patrząc na zmiany od wersji 4tej do 8ej można z znaczną dozą zaufania określić dalszy kierunek rozwoju.
Zmierza on w kierunku LabVIEW coraz bliższego sprzętu. I raczej nie będą to urządzenia dedykowane jak Compat RIO.
zakładam że nie naruszylem tą wypowiedzią poufnych danych firmy NI

uczyc sie warto, to nie podlega dyskusji
natomiast co do LV embedded to nie zgadzam sie z toba. wygenerowanie kodu w C na 32bit. mikropocesor to nie jest rozwiazanie problemu. trzeba jeszcze jakos dostarczyc mu dane, odebrac wyniki, a najlepiej jeszcze uruchomic przerwania (wielopoziomowe rzecz jasna). nie tedy droga. bo zamiast opanowac jeden system musze opanowac co najmmniej dwa (LV i srodowisko charakterystyczne dla danego procesora).
jesli chodzi o FPGA to tez sie nie zgadzam. za pomoca symulowania backplane'u magistrali PIC mozna zmusic karte FPGA do pracy niezaleznej od bazowego komputera. chyba zgadzasz sie ze mna ze rowniez nie tedy droga.
o ile moge zrozumiec ze przypadek pierwszy moze byc drogi w realizacji, o tyle w przypadku drugim wystarczy tylko niewielka przerobka hardware'u ale na etapie produkcji a nie dorabiania czegos na boku. (znajomy technik mowi na to rzezbiarstwo). jest tez mozliwosc dobrania sie do powstajacego na pewnym etapie kompilacji kodu w VHDL. tylko co z tego jesli jest to nadal droga okrezna, o jakichkolwiek certyfikatach i umocowaniach prawnych nie wspomne.
z tego co wiem z prezentacji prowadzonych przez NI (tak wiec twoje obawy o poufnosc chyba sa bezpodstawne) jedna z firm specjalizujacych sie w zawansowanych mikrokontrolerach pisze ... nie wiem jak to sie nazywa ... ale bedzie przenosic ograniczone kody z LV do danego kontrolera. tylko ze to znowu bedzie "na okolo" , bo firma owa ma zmodyfikowac pewne czesci LV pod swoje zastosowania. czyli konkluzja, ze jednak nie NI tylko jakis "podwykonawca" przeciera sciezke mikrokontrolerow.
nastepna rzecz - na tej samej prezentacji widzialem prototypowa plytke z DSP Texas Instruments programowana w LV. moja radosc trwala krotko bo mozna zaprogramowac tylko ten konketny DSP i tylko w tej konkretnej plytce. gdzie tu sens ?
a co do budowania rzymu, krakowa czy innych miast - parcie w strone szybkiego tworzenia aplikacji dedykowanych obserwuje od dobrych 8 lat. zaproponiwanie srodowiska graficznego (ktore przeciez juz jest) jako alternatywy dla VHDLa bylo by genialnym posunieciem. nie moge zrozumiec polityki NI w tym zakresie. w zasadzie maja juz wszystkie klocki tylko nie chca zbudowac z nich domku.

co do parzenia herbaty przez NI7811R to myśle ze jakby grupa studentów dorwała sie do niego to nawet i by kawe robił

mgawlik pisze: natomiast co do LV embedded to nie zgadzam sie z toba. wygenerowanie kodu w C na 32bit. mikropocesor to nie jest rozwiazanie problemu. trzeba jeszcze jakos dostarczyc mu dane, odebrac wyniki, a najlepiej jeszcze uruchomic przerwania (wielopoziomowe rzecz jasna). nie tedy droga. bo zamiast opanowac jeden system musze opanowac co najmmniej dwa (LV i srodowisko charakterystyczne dla danego procesora).

1. Wygenerowanie kodu z możliwością monitorowania jego wykonywania się + monitorowania zajetości pamięci w duzym skrócie i uproszczeniu (Blackfin Analog Device) wymaga pewnych mechanizmów. Dostępnych w Blackfinie właśnie. A dokładniej od Blackfina.
2.
LVEmb. nie jest dedykowane dla jednego konkretnego typu procesorów, owszem, dostarczane jest z kitem Blackfin'a AD. Dostępnych targetów (układów) jest o wiele więcej.

mgawlik pisze: jesli chodzi o FPGA to tez sie nie zgadzam. za pomoca symulowania backplane'u magistrali PIC mozna zmusic karte FPGA do pracy niezaleznej od bazowego komputera. chyba zgadzasz sie ze mna ze rowniez nie tedy droga.

Nie w tym kierunku idzie rozwój tej części środowiska. Trudno tutaj oficjalnie mówić coś więcej, ale NI wspomina o układach FPGA Spartan i nowych generacjach Virtex'ów. Mnożyć backplane'ów raczej nie będą.

mgawlik pisze:o ile moge zrozumiec ze przypadek pierwszy moze byc drogi w realizacji, o tyle w przypadku drugim wystarczy tylko niewielka przerobka hardware'u ale na etapie produkcji a nie dorabiania czegos na boku. (znajomy technik mowi na to rzezbiarstwo). jest tez mozliwosc dobrania sie do powstajacego na pewnym etapie kompilacji kodu w VHDL. tylko co z tego jesli jest to nadal droga okrezna, o jakichkolwiek certyfikatach i umocowaniach prawnych nie wspomne.

Myślę że chodzi tu raczej o współpracę. Bazą są tutaj uklady Virtex i Spartan a to nie NI jest ich producentem tylko firma Xilinx - ma gotowe środowiska, opracowane metody optymalizacji i kompilacji kodu wynikowego do własnych ukladów: po co wyważać otwarte drzwi i ponownie wynajdywać koło? Indianie mawiali "Jesli nie możesz ich pokonać - przyłacz się do nich".

mgawlik pisze:z tego co wiem z prezentacji prowadzonych przez NI (tak wiec twoje obawy o poufnosc chyba sa bezpodstawne) jedna z firm specjalizujacych sie w zawansowanych mikrokontrolerach pisze ... nie wiem jak to sie nazywa ... ale bedzie przenosic ograniczone kody z LV do danego kontrolera. tylko ze to znowu bedzie "na okolo" , bo firma owa ma zmodyfikowac pewne czesci LV pod swoje zastosowania. czyli konkluzja, ze jednak nie NI tylko jakis "podwykonawca" przeciera sciezke mikrokontrolerow.
nastepna rzecz - na tej samej prezentacji widzialem prototypowa plytke z DSP Texas Instruments programowana w LV. moja radosc trwala krotko bo mozna zaprogramowac tylko ten konketny DSP i tylko w tej konkretnej plytce. gdzie tu sens ?

Rozumiem że niemowlęta, w drugim roku życia powinny już skakać o tyczce ? Aby sprowadzić kod o poziomie abstrakcji LabVIEW do poziomu C lub asemblera danego procesora sygnałowego (i nie tylko) trzeba stworzyć po drodze wiele mostów programowych pisząc opisowo.
Obecne rodziny DSP róznią się miedzy sobą nawet w obrębie jednego producenta. Uwzględnienie zróżnicowania i specyfiki procesora z danej rodziny nie przenosi się w całości na procesory innych rodzin. Producentów również. Wiesz Kraków, Rzym...

mgawlik pisze:a co do budowania rzymu, krakowa czy innych miast - parcie w strone szybkiego tworzenia aplikacji dedykowanych obserwuje od dobrych 8 lat. zaproponiwanie srodowiska graficznego (ktore przeciez juz jest) jakos alternatywy dla VHDLa bylo by genialnym posunieciem. nie moge zrozumiec polityki NI w tym zakresie. w zasadzie maja juz wszystkie klocki tylko nie chca zbudowac z nich domku.

Być może mogło by to zostać odebrane jako
a) próba wrogiego przejęcia rynku b) próba naśladownictwa.
Ze strony NI wygląda to raczej na jawną deklarację wspólpracy z firmami Xlinx, Texas Instruments, Analog Device i innymi. Jest przecież bardzo dużo róznych firm, wiele rozwiązań. Koło już wynaleziono.

wszystko to bardzo ladnie, ale fakt pozostaje faktem, ze w 2006 roku wladowanie kodu z LV do uC lub FPGA jest bardzo kiepsko wykonalne.
i jeszcze jedna drobna uwaga - nie trzeba pisac mostow miedzy LV a kontrolerami. trzeba bazujac na koncepcji jezyka G dostosowac istniejace komponenty do zastosowan w kontrolerach. im bardziej uniwersalne bedzie to dostosowanie tym gorzej bedzie wygladac. widzieliscie moduly MATLABA do programowania wybranych (raptem 6ciu czy 8miu) typow mikroprocesorow ? tak sie to wlasnie powinno robic. nie zwiekszac palety mozliwych platworm sprzetowych, ale dedykowac LVemb. pod konketne uklady, wykorzystujac w pelni i ch mozliwosci (lacznie z reprogramowaniem ukladu przez samego siebie podczas pracy). a czy zrobi sie to samemu czy dolaczajac do kogos - co za roznica ? fakt pozostaje faktem, ze w 2006 roku takich mozliwosci nie ma.
microbi mowil o 2letnim dziecku i skoku o tyczce - dobre porownanie. wirtuozi skrzypiec zaczynaja mniej wiecej w 5tym roku zycia. mysle ze dla NI to juz troche za pozno. szkoda, bo niezle sie zapowiadalo.