Hey zusammen, Wenn man auf aktuelle Stellenausschreibungen achtet, nistet sich immer mehr Labview unter die klassischen Anforderungen (C++, Matlab, ...) ein. Glaubt ihr das tendentiell mit LabView ein neuer Zweig entsteht, quasi, dass es in einem Betrieb dann speziell Leute gibt, die nur LabView machen (Vielleicht gibt es die ja schon). Meint ihr auch, das LabView zu einem Tool wird das unabdingbar wird in ferner Zukunft? Beste Grüße alex
matlab&simulink sind bereits unabdingbar... da will labview halt auch mitmischen..
>LabView zu einem Tool wird das unabdingbar wird in >ferner Zukunft? Dachte die LabView Zeiten sind bereits gezählt .... !?!
Labview ist ein bisschen wie Basic: Man bekommt schnell ansehnliche Ergebnisse. Aber nur mit Selbstdisziplin. Sachen wie "hier klackern", "da Spannung messen", "dort Oszibild aufnehmen" und das ganze auswerten(FFT etc.), Protokoll erzeugen und auf einem FTP-Server ablegen sind Sachen, die man in einem halben Arbeitstag ordentlich hinbekommen kann. Vorteil ist die breite Basis von unterstützen Geräten. Fast jeder namhafte Messgerätehersteller bietet die passenden VI's an. Wenn man bei NI-Hardware bleibt, ist man sogar (im Rahmen der Hardwaregrenzen) unabhängig. Solange man mit dem Endegrät eine Spannung messen kann, misst man eben eine Spannung. Da ist es egal ob es ein Oszi, DMM oder nur ein 08/15 USB-Device ist. Man hat sogar die Möglichkeit, dass alles als Realtime (auf der entsprechenden Hardware) bzw. FPGAs laufen zu lassen... Mirko
Ich würde auch behaupten, dass LabView in Zukunft höchstens abnimmt was die Verbreitung angeht.
Alexander Haleer schrieb: > Meint ihr auch, das LabView zu einem Tool wird das unabdingbar wird in > ferner Zukunft? - um Firmware für Geräte zu schreiben? -> NEIN - um Software für Tablets/PCs/Handys zu erstellen -> NEIN - um mathematische/wissenschaftliche Berechnungen zu machen -> NEIN - um im Prüffeld ein Messystem zu erstellen -> JA - um Messungen automatisiert aufnehmen und auswerten -> JA [...] National Instruments ist nicht nur Labview. Man kann auch in LabWindows in C progammieren. Diese Firma stellt auch die passende Hardware hierfür her. Wenn in einer Stellenbeschreibung also Labview steht, ist auch meistens in der Firma etwas Hardware dafür vorhanden. Es ist EIN Tool, mit welchem man EINE Problemgruppe gut bearbeiten kann. Es ist nicht die Eierlegende Wollmichsau (mit Reitgerte).... ;) Mirko
Mr Bean schrieb: > Ich würde auch behaupten, dass LabView in Zukunft höchstens abnimmt was > die Verbreitung angeht. >Dachte die LabView Zeiten sind bereits gezählt .... !?! Auf was stützt ihr euch da, was für Gründe könnte es geben? Gibt es bessere Alternativen?
Lars B. schrieb: > Dachte die LabView Zeiten sind bereits gezählt .... !?! Mr Bean schrieb: > Ich würde auch behaupten, dass LabView in Zukunft höchstens abnimmt was > die Verbreitung angeht. Nur so aus Interesse: Kennt ihr Firmen oder Leute, die in der Vergangenheit Labview genutzt haben und jetzt nicht mehr? Was benutzen die jetzt stattdessen? Edit: Alexander war schneller :) Edit2: Alternativen scheint es zu geben: http://www.edn.com/electronics-blogs/rowe-s-and-columns/4378137/What-s-your-LabView-substitute- Aber scheinen bei Weitem nicht die Verbreitung von Labview zu haben.
Alexander Haleer schrieb: > Wenn man auf aktuelle Stellenausschreibungen achtet, nistet sich immer > mehr Labview unter die klassischen Anforderungen (C++, Matlab, ...) ein. > Glaubt ihr das tendentiell mit LabView ein neuer Zweig entsteht, quasi, > dass es in einem Betrieb dann speziell Leute gibt, die nur LabView > machen (Vielleicht gibt es die ja schon). > Meint ihr auch, das LabView zu einem Tool wird das unabdingbar wird in > ferner Zukunft? Ja, Testautomatisierung ist unausweichlich. In der produktion stehen ganze batterien von Prüftürmen die mit Labview gesteuert werden: borad auf nadelbett legen, Prüfprogramm starten, -> messgeräte (Scope, Multimeter, generator,usv,JTAG-Adapter) werden angesteuert und ein komplettes Protokoll xSeiten als PDF) erzeugt. Da ist nix mehr mit handisch ins protokoll eintragen, das wird alles über GPIB rausgekitzelt. MfG,
Fpga Kuechle schrieb: > das wird alles über GPIB rausgekitzelt. Das ist doch sowas von uralt! Parallelbus und langsam und teuer und sowieso! Es gibt doch USB 3.0, Bluetooth, Ethernet...das ist alles besser! Gibts denn noch jemanden der sowas benutzt? ;) DuckundWech Mirko
MirkoB schrieb: > > - um Firmware für Geräte zu schreiben? -> NEIN > - um Software für Tablets/PCs/Handys zu erstellen -> NEIN > - um mathematische/wissenschaftliche Berechnungen zu machen -> NEIN > - um im Prüffeld ein Messystem zu erstellen -> JA > - um Messungen automatisiert aufnehmen und auswerten -> JA > [...] > > National Instruments ist nicht nur Labview. Man kann auch in LabWindows > in C progammieren. Diese Firma stellt auch die passende Hardware hierfür > her. > Wenn in einer Stellenbeschreibung also Labview steht, ist auch meistens > in der Firma etwas Hardware dafür vorhanden. > > Es ist EIN Tool, mit welchem man EINE Problemgruppe gut bearbeiten kann. > Es ist nicht die Eierlegende Wollmichsau (mit Reitgerte).... ;) > > Mirko das ist cool zusammengefasst, vielen dank dafür!
MirkoB schrieb: > Fpga Kuechle schrieb: >> das wird alles über GPIB rausgekitzelt. > > Das ist doch sowas von uralt! Parallelbus und langsam und teuer und > sowieso! > Es gibt doch USB 3.0, Bluetooth, Ethernet...das ist alles besser! > Gibts denn noch jemanden der sowas benutzt? ;) Es geht um messgeräte, da ist USB 3.0, bluetooth, wlan noch nicht angekommen und meist unnötig: Für nen Multimeter ist parallelbus schon überdimensioniert, ein paar bit digitalisierte Spannungswerte brauchen keine Bandbreite. Allein bei Scopes siehts anders aus (screenshots), da hats auch Ethernet. MfG
...meine Frage war auch mehr provozierend gestellt. ;) GPIB geht einfach...wenn nur nicht diese dicken, unelastischen Kabel wären... Mirko
Ich darf schon seit einer ganzen Weile mit LabWuh arbeiten. Habe auch Schulungen und Prüfungen gemacht. Ich dürfte das gar nicht sagen, aber LabView wird schnell zum Krampf... vor allem wenn es mal etwas komplexer wird. Was man in C einfach als Spaghetti-Code mit ein paar Funktionen runter reißen kann erfordert dann in LabView gleich komplexere Strukturen (Event-/Queue-Basierte Verarbeitung). Oder der LabView Code wird unübersichtlich. Bei LabView muss man sich vorher schon überlegen welche Architektur man benötigt und sich über das Software-Design Gedanken machen. Einfach drauf los programmieren führt zu unübersichtlichen/komplexen Ergebnissen. Wenn man bisschen Geschwindigkeit braucht muss man auch wissen was man da macht. z.B. gibt es die tollen Express-VIs mit denen man super einfach eine Messung durchführen kann. Aber "Express" steht nur für den Coding-Aufwand, nicht für die Ausführgeschwindigkeit.
Angehängte Dateien:
-
labview.jpg
240 KB
Yalu X. schrieb: > Nur so aus Interesse: Kennt ihr Firmen oder Leute, die in der > Vergangenheit Labview genutzt haben und jetzt nicht mehr? Ich kenne ein Forschungsinstitut, in dem Labview für neue Aufbauten (Anlagensteuerung, -regelung, Messungen, wenig GPIB, viel Ethernet) durch C# oder Python ersetzt wurde. Die Labview-Programme waren nach ein paar Änderungen unwartbar geworden. Mit Labview kann man zwar ordentlich programmieren, allerdings ist das genauso aufwändig wie in richtigen Sprachen.
....ein wunderschönes Beispiel dafür, wie man in LabView ein "MachMalSchnell" Programm mit "DaMussNochRein" sowie einer Prise "MachMalAnders" programmiert. Ich könnte darauf wetten, dass derjenige, der das Programmiert hat, niemals eine LabView Schulung mitgemacht hat und sich das alles selbst erarbeitet hat. Hut ab vor dem Fleiß, aber sowas kommt dann dabei raus. Dieser Code ist definitiv unrettbar... Da hilft nur neu und sauber aufsetzen. Weil es mich gerade interessiert: (GPIB und Phyton) Ist es Möglich mehrere Task (Threads) anzulegen? z.B. Thread1 macht die Datenerfassung, Thread2 die Datenfilterung und Thread3 die Oberfläche? Mirko
Das Bild war ein Beispiel von irgendwo aus dem Internet, da ich aus besagtem Institut nichts habe (oder posten würde), dort sah es nur halb so schlimm aus ;) >niemals eine LabView Schulung mitgemacht hat und sich das alles selbst >erarbeitet hat. Das ergibt sich in solchen Strukturen wohl. Keiner interessiert sich für Software und fummelt nur solange, bis er an der Anlage seine Messungen machen kann, dann kommt der nächste, baut etwas um und will etwas anderes messen und fummelt wieder.
MirkoB schrieb: > Weil es mich gerade interessiert: (GPIB und Phyton) > > Ist es Möglich mehrere Task (Threads) anzulegen? z.B. Thread1 macht die > Datenerfassung, Thread2 die Datenfilterung und Thread3 die Oberfläche? > > Mirko Ja ,das geht. Wenn du nicht willst, dass die GUI während der Messung einfriert mußt du sogar 2 Threads nehmen.
>Ich darf schon seit einer ganzen Weile mit LabWuh arbeiten. Habe auch >Schulungen und Prüfungen gemacht. Ich dürfte das gar nicht sagen, aber >LabView wird schnell zum Krampf... vor allem wenn es mal etwas komplexer >wird. Das ist wie mit C: Am Anfang hat der unerfahrene Programmierer noch die Übersicht, später wird das Programm chaotisch.
>Mit Labview kann man zwar ordentlich >programmieren, allerdings ist das genauso aufwändig wie in richtigen >Sprachen. stimmt:
1 | #include<stdio.h> /******** SpigotQuine -- usage: ./spigot [pi or e] ********/ |
2 | char*s="G1%%xJ{;Q7wunmuGuu%%uu#include<stdio.h>/*Spigot_Quine*/#include<stdli" |
3 | "b.h>/*_IOCCC2012_*/int*e," "i,j,k,n" ";char*q" ",*a,*d,*z,*p=%s%c;" |
4 | "int" "%cmain(){a=calloc(" "1,1e4+n*2);;for(*" |
5 | "a=\0@3,z=d=a+n+1,j=n*8-7;" "k=0,j-1" ";j-=2){" "for(a[1]+=2;--z-a;" |
6 | "*z=k%%10,k/=10)k+=j/2**z;;for(;k=k%%j*" "10+*++z,z<d;)*z=k/" "j;;\0@2,z=" |
7 | "d=a+n*2,*z=1,j=0;++j<n;){for(;k=k%%" "j*10+*z,a-z;*z" "--=k/j)a+" |
8 | "+;for(k=0;z-d;*a--=k%%10,k/=10)k+" "=*++z+*a\0" "@;}d+=spr" |
9 | "intf(q=d-20,p,p,34,32,n+1)+2;;;;" "for(n=n*2" "0-400;k<n" |
10 | ";++k%%n?j=!puts(" "d):(d[j]=" |
11 | "47,d++,d[j-2" "]=42),k%%" |
12 | "20<1?puts(d" "-1),a++:0" |
13 | "){for(i=-1" ";i++<32;!" |
14 | "*z?q[662]" "=0,z=q+207:" "*z+z[1]<6" "5?z+=11:*" |
15 | "z==34?p=0" ":0)d[i]=((k/2" "0-1?275*q[" "*a+10]-8*" |
16 | "q[*a+0]-8" ":128)>>(i/11+k/" "4%%5*3))&1?k" "/3*!j&&p?" |
17 | "j=34:(j=" "i+1,*z++):32;k/3*" "j--&&p?d[z--,j]=3" "4:0;}}int" |
18 | "*y,n=%d;/*..~",*f="nnLa5~z23~|22t$q(s82r&q(s82q'q(s8;q(s8;q(s8:" "r(s8:r(s8:" |
19 | "q)s89r)sLr#t+" "sLx,uJw-yGu/wnnnU",*g="nnLa<z::t$u88t(u67t*u57s,t56t,t56~v56" |
20 | "tF6tF6tF8t1p" "Nu/qOv+rS}Xxnng";int main(int m,char**v){char a[2012],b[2012 |
21 | ],*p=a,*r=m>1 &&*v[1]=='e'?g:f,*q=b,*t=r;;sprintf(a,"%s%s%s",s,r==g?s+281: |
22 | s+168,s+386); sprintf(b,a+22,a,34,32,24);for(sprintf(a,"%.33s/*%.28s*/%.3" |
23 | "3s/*%.28s*/%" ".33s\"%s*/",b,b+66,b+33,b+76,b+66,b+99);*r;r++){;for(m=0;m++ |
24 | <(*r-34)%77;*q++=*r>111?32:*p++)(q-b)%66<1?*q++=10:0;*r-110&&*r-126&&r-t<(t-g? |
25 | 62:45)?*q++=34,((q-b)%66<1?*q++=10,*q++=34:0):0;}*q=0;puts(b+1);}/*IOCCC2012*/ |
Ich bin froh, wenn ich nix mit LabView machen muss/darf. Einfache Geschichten sollten sich aber schnell damit bewerkstelligen lassen. NI bietet auch ganz schön viel HW für LabView an und andere Hersteller ebenso. Hat eigentlich schon iwer. mal was von VEE von Agilent gehört? Vllt. auch schon mal gesehen oder damit gearbeitet? - Ich selber hab's nur kurz in Aktion gesehen; hat keinen besseren oder schlechteren Eindruck wie LabView hinterlassen, aber ich weiß auch nicht wie/was an den beiden Programmen vergleichbar ist (bzw. auf Leistungsumfang). http://www.agilent.com/find/vee
Kann man das in LabVIEW nicht mit SubVIs in den Griff kriegen? Simulink kann ja auch schön übersichtlich werden.
franz schrieb: > stimmt: > #include<stdio.h> /******** SpigotQuine -- usage: ./spigot [pi or e] > ... Das ist ja lustig, dass dabei was rauskommt.
>franz schrieb: >> stimmt: >> #include<stdio.h> /******** SpigotQuine -- usage: ./spigot [pi or e] >> ... >Das ist ja lustig, dass dabei was rauskommt. Klar, ist ja auch von hier: http://www.ioccc.org/years.html#2012 >Kann man das in LabVIEW nicht mit SubVIs in den Griff kriegen? Simulink >kann ja auch schön übersichtlich werden. Klar kann man, nur nicht jeder kann ...
MirkoB schrieb: > Weil es mich gerade interessiert: (GPIB und Phyton) > > Ist es Möglich mehrere Task (Threads) anzulegen? z.B. Thread1 macht die > Datenerfassung, Thread2 die Datenfilterung und Thread3 die Oberfläche? Wie schon von masla erwähnt: Ja. Mit pygtk oder pyqt funktioniert übliche GUI-Programmierung wie gewohnt (Threads, Signals, Slots etc.), mit SciPy hat man quasi Matlab-Funktionalität (Simulink und andere Toolboxen natürlich nicht), mit PyVISA kann man GPIB ansprechen. Mit letzterem habe ich allerdings keine Erfahrungen.
labview ist für jeden der schon mal ernsthaft programmiert hat eine reine qual. allein schon ne schleife machen ist einfach nur bescheuert. ergo ist labview mMn etwas für leute die nicht programmieren können (was ja auch ok ist). letztlich glaube ich, dass man mit pessimistisch geschätzt 200% der zeit die man für eine labview-lösung braucht eine bessere lösung mit einer richtigen programmiersprache schreiben kann. hersteller-SDKs vorrausgesetzt natürlich. eine daseinsberechtigung hat labview denke ich nur im test engineering.
>labview ist für jeden der schon mal ernsthaft programmiert hat eine >reine qual. Für Dich vielleicht. Ich programmiere seit 25 Jahren unterschiedliche in unterschiedlichen Sprachen: C, C++, Java, Python, Matlab und LabView Jede Sprache hat Ihre vor und Nachteile. Man muss sie nur bedienen können.
franz schrieb: > Jede Sprache hat Ihre vor und Nachteile. Man muss sie nur bedienen > können. ja da stimme ich dir zu, jede sprache hat ihre daseinsberechtigung. nichts schlimmeres als leute die für alles "ihre" sprache verwenden wollen. dennoch finde ich programmieren mit labview sehr umständlich, da man sich alles zusammenklicken muss und es nicht einfach runterschreibt. allein für eine schleife die werte aus vorherigen schleifendurchläufen speichert brauche ich zumindest 5 mal solang.
Frank Meier schrieb: > labview ist für jeden der schon mal ernsthaft programmiert hat eine > reine qual. allein schon ne schleife machen ist einfach nur bescheuert. > ergo ist labview mMn etwas für leute die nicht programmieren können (was > ja auch ok ist). > letztlich glaube ich, dass man mit pessimistisch geschätzt 200% der zeit > die man für eine labview-lösung braucht eine bessere lösung mit einer > richtigen programmiersprache schreiben kann. hersteller-SDKs > vorrausgesetzt natürlich. > eine daseinsberechtigung hat labview denke ich nur im test engineering. Das kann ich nicht ganz bestätigen, sicherlich ist LabView etwas gewöhnungsbedürtig, wenn man nur "normale" Programmiersprachen kennt, wie z.B. C. Aber wenn man den Dreh raus hat, dann kann man super schnell Programme erstellen. Bei uns in der Firma basieren alle Prüf- und Programmierplätze auf LabView. Ich nutze LabView auf der Arbeit nicht nur für Prüfplätze, sondern auch beispielsweise als Funktionsgenerator um Neuentwicklungen auf Funktion zu überprüfen. Innerhalb von Minuten kann ich jede gewünschte Bitfolge z.B. als NRZ-Code ausgeben lassen oder auch Arbitäre-Funktionen. Die Komponenten von NI sind zwar gefühlsmäßig relativ teuer, aber dafür hat man einen erstklassigen Support und die Hardware läuft äußerst stabil (sowas ist natürlich Entscheidend, wenn die Produktion im weitentfernten Land ist). Aber ich muss zugeben, dass ich mir noch nie Alternativen zu LabView angeschaut habe. Gruss Daniel
>dennoch finde ich programmieren mit labview sehr umständlich
Für manche Sachen ist es etwas umständlich. Ich habe aber oft Matlab im
Hintergrund benutzt. Man kann in LabView direkt Matlab-Scripte schreiben
und Matlab damit aufrufen. Dann kann man Abläufe "scripten".
Es gibt auch ein Python-Interface, aber das ist wohl in der Entwicklung
stehen geblieben. Die letzten Updates sind schon recht alt.
Ähnlich wie bei Daniel S. wird in meiner Firma LabView für Prüf- und Testaufbauten verwendet. Vee von Agilent kenne ich, allerdings ist man da auf Hardware von Agilent angewiesen. Annahme: Ihr habt eine beliebige Hardware, die eine Spannung/Strom oder sonstwas misst. Diese Werte möchtet ihr auf den PC übertragen, auf der Oberfläche in einem eigene Fenster dargestellt bekommen in Form eines Diagramms und gleichzeitig sollen diese Daten als Excell-konforme Logdatei abgespeichert werden. Die Hardware verfügt über eine serielle Schnittstelle (z.B. USB). Wie lange würde es mit C dauern die PC Verbindung zum Gerät herzustellen, die Oberfläche zu basteln, das Diagramm darin zeichnen zu lassen (Wobei die Daten im Diagramm Live-Daten sein sollen), die Logdatei zu erstellen, etc.? In LabView dauert das ca. 15-30 Minuten höchstens.
>LabView-Programmierer ...
In C brauche ich dafür höchstens 15 Minuten.
Viele verlernen mit solchen Tools, was eigentlich passiert: USB
Schnittstelle, Gerät ansteuern, auswerten,....
Das hat dann zur Folge, wenn Probleme auftreten, kann diese keiner mehr
lösen.
Man kann sich übrigens auch in C/C++ usw.. auch Libraries erstellen, die
man dann bei neuen Aufgaben wieder einsetzen kann. Und man hat selber
alles im Griff!
Sepp schrieb: > > In C brauche ich dafür höchstens 15 Minuten. Auja, die Challenge nehme ich an. Setting: Ein Oszilloskop, ein Voltmeter und Speichern von jeweils 10 Meßpunkten mit FFT und Suche der Spitzenwerte in eine Excel-Tabelle. Du in C in 15 Minuten, ich in LabView in 30. Beide dokumentieren das in einem Youtube-Video, damit nicht geschummelt wird.
Harry Potter schrieb: > Ich brauch dafür in Python max. 5 Minuten Dann mach mal. Allein für die Genugtuung Recht zu haben sind 5 Minuten eine sehr kleine Investition.
Sepp schrieb: > In C brauche ich dafür höchstens 15 Minuten. > Viele verlernen mit solchen Tools, was eigentlich passiert: USB > Schnittstelle, Gerät ansteuern, auswerten,.... > Das hat dann zur Folge, wenn Probleme auftreten, kann diese keiner mehr > lösen. > Man kann sich übrigens auch in C/C++ usw.. auch Libraries erstellen, die > man dann bei neuen Aufgaben wieder einsetzen kann. Und man hat selber > alles im Griff! Ohje schwerer Fall von NIH-Syndrom.
MirkoB schrieb: > National Instruments ist nicht nur Labview. Man kann auch in LabWindows > in C progammieren. Diese Firma stellt auch die passende Hardware hierfür > her. Habe ich mal gemacht. Sehr effektiv! Ansonsten ist meine Meinung eher diese hier: Beitrag "Re: FPGA grafisch programmieren" > Es ist EIN Tool, mit welchem man EINE Problemgruppe gut bearbeiten kann. > Es ist nicht die Eierlegende Wollmichsau (mit Reitgerte).... ;) Das stellt NI aber gerne so dar!
Harry Potter schrieb: > Ja wie denn, ich habe kein Oszilloskop. Macht nichts. Bei 5 Minuten gebe ich Dir sogar dann recht, wenn Du das bei zwei Meßgeräten Deiner Wahl hinbekommst, die Daten automatisch mit Python zu aquirieren, eine kleine Signalverarbeitung zu machen und in Excel zu speichern. Aber bitte mit Video. P.S.: Um Mißverständnisse zu vermeiden: 5 Minuten für die Erstellung der Meßapplikation. Nicht für das Laufenlassen der Messung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.