Diskussion:LabVIEW

Labview Kritik

Der Sache mit dem Drahtwirrwarr und den Variablen die angeblich eingefügt werden "müssen" kann ich nicht zustimmen.

• In einem ordentlich strukturierten LabVIEW-Projekt wird der Wirrwarr durch Aufteilung in Sub-VIs und eine durchdachte Struktur in einem erträglichen Maß gehalten.

• Es stimmt dass lokale Variablen die Geschwindigkeit deutlich reduzieren (nicht nur laut Doku). Sie sind aber auch nicht als Ersatz für lange Leitungen gedacht, sondern für spezielle Sonderfälle, in denen der reine Datenfluss nicht ausreicht.

• Globale Variablen benötigen tatsächlich einen etwas höheren Aufwand (einigen Aufwand kann ich hier nicht erkennen seit es "echte" Globals gibt und man keine VI-based Globals mehr schreiben muss), ich kenne aber auch nur sehr wenige Einsatzzwecke bei denen Globale Variablen in LabVIEW wirklich Sinn machen.

Ich hab's nicht direkt im Artikel geändert und würde mich über eine Stellungnahme insbes. von Montauk freuen. Dass das kein Werbetext für LabVIEW ist, ist mir auch klar, ich finde aber man sollte diese Nachteile, die größtenteils auf einer falschen Herangehensweise an das Problem beruhen nicht als allgemeingültig für LV hinstellen.

Ich stimme dir im Prinzip zu, dass sich andere Programmiersprachen für sehr große Projekte deutlich besser eignen als LV, nur deine konkreten Argumente kann ich nicht nachvollziehen. --silmaril 17:32, 9. Dez 2004 (CET)

Es freut mich, dass Du nicht einfach loeschst, sondern die Sache zunaechst ausdiskutieren moechtest. Die Nachteile, die ich beschrieben habe beruhen auf einem langjaehrigen Erfahrungschatz mit sehr vielen interpretierten und kompilierten textbasierten Sprachen und eben auch LabVIEW.

• Bei textbasierten Sprachen ist es so, dass sich der Benutzer nicht um das Format selbst kuemmern muss: Einrueckungen und Farbmarkierungen werden z.B. von Programmen wie dem Emacs der Syntax entsprechend mehr oder weniger automatisch vorgenommen. In LabVIEW ist das anderes: Hier muss der Benutzer nicht nur den Programmablauf festlegen, sondern auch die Position eines jeden Drahtstueckes und eines jeden Symbols. Dieser Mehraufwand faellt bei kleinen Projekten nicht ins Gewicht, so dass es bei diesen auch nicht als Nachteil zu bezeichnen ist.
• Hat man jetzt aber grosse Projekte und man muss noch eine Funktion hinzufuegen oder massiv abaendern, dann ist eine grossflaechige Neuanordnung der Draehte, Symbole und Strukturen faellig, selbst dann, wenn es sich nur um eine kleine Veraenderung handelt, die aber einfach Platz auf dem Bildschirm benoetigt: Die Formatierung, die man bisher aufwendig per Hand vorgenommen hat muss nochmals neu gemacht werden. Muss z.B. eine Struktur auf innerer Ebene vergroessert werden (if, case etc.) dann muss auf allen darueberliegenden Ebenen auch Platz geschaffen werden. Bei textbasierten Sprachen wird der Text einfach eingefuegt, die Formatierung kostet keine Zeit.
• Die hier geschilderten Probleme beruhen meines achtens nicht auf einer falschen Herangehensweise. Man koennte zwar sicher die Durchfuehrung eines Projektes so gestalten, dass die Probleme nicht so haeufig und massiv auftreten, aber das ist nicht praxisgerecht. LabVIEW wird z.B. in der Forschung angewandt, nicht von Informatikern, sondern von Leuten, die LabVIEW nur als Mittel zum Zweck sehen. Es ist keine Zeit und das Wissen fuer grosse Projektplanung vorhanden.
• Da es sich hier nicht um einen Werbetext handelt, der Artikel zudem fuer die Breite Masse der Anwender gedacht ist, sollten Nachteile im Klartext und nicht verklausuliert formuliert werden, auch wenn es erfahrene Anwender wie Dich gibt, fuer die das keine Probleme sind.
• Ich stimme zu, dass lokale Variable fuer Spezialfaelle und nicht als Ersatz fuer lange Leitungen gedacht sind. Aber mit der Groesse und Komplexitaet eines Projektes nimmt die Anzahl der Spezialfaelle zu.
• Dass man fuer globale Variable kein eigenes VI mehr braucht, wusste ich nicht. In 6i war es jedenfalls so und das war sehr nervig.

P.S.: Wenn Du anderer Meinung bist, dann aendere den Text einfach. Auf einen Diskussionskrieg lasse ich mich nicht mehr ein, dazu habe ich die Zeit und Motivation nicht. --Montauk 12:44, 10. Dez 2004 (CET)

Deine Argumente lassen sich in dieser ausführlichen Form durchaus nachvollziehen. Ich habe den Artikel nochmal angepasst und hoffe, dass diese Fassung einen sinnvollen Kompromiss unserer beiden Ansätze verwirklicht.

Den Aufwand beim Erstellen globaler Variablen habe ich gestrichen. Die Aussage, dass Variablen verwendet werden "müssen" habe ich dadurch ersetzt, dass sie oft verwendet werden (ist in der Praxis ja wirklich so) und dass das die Geschwindigkeit herabsetzt und dem Datenfluss widerspricht. --silmaril 18:58, 15. Dez 2004 (CET)

Ich bin Ingenieur und arbeite hauptsächlich mit LabView. Die von Euch erwähnten Nachteile kann ich nicht nachvollziehen. Ein GLEICH UMFANGREICHES Projekt mit einer Hochsprache verbraucht in Punkto Änderungsaufwand und Planung DEUTLICH mehr Zeit, als LabView. Das beides nicht auf Null reduziert wurde, ist kein Nachteil, sondern die GERINGERE Planungszeit und der GERINGERE Änderungsaufwand ist ein großer Vorteil. Darüber hinaus wird LabView durchaus in der Industrie eingesetzt, nicht nur in der Forschung. --84.167.193.165 13:54, 16. Dez 2005 (CET)

Sämtliche genannten Nachteile sind entweder nicht labViewspezifisch oder es handelt sich um Fehlverhalten von Usern. Ist die hohe Geschwindigkeit beim Porsche auch ein Nachteil, da diese den unreifen Fahrer zur Raserei verführt? MV

Ich muss meinen beiden Vorrednern vollkommen recht geben. Ich kann einige Kritikpunkte beim besten Willen nicht nachvollziehen, allerdings sind Verweise auf eine bestimmte Quelle nicht zu übersehen. Es gibt eine besondere Klientel von Programmierern, die der Welt einfach die Vorteile von JAVA oder Lunix unter die Nase reiben müssen. Mag sein, dass diese Vorteile in den reinen Informatikerdisziplinen mit sich bringen, bei den meisten Ingenieurstechnischen Anwendungen ist das aber nicht der Fall.

Dort wird Software nur als Mittel zum Zweck verstanden, Übersichtlichkeit ist oberstes Gebot. Mich interessiert das Ergebnis und die Interpretation einer Messung, der konkrete Weg dahin ist mal eher zweitrangig. Und so finden Programme wie LabVIEW auch in solchen Bereichen Anwendung, sei es in der Forschung, an Hochschulen oder aber auch in der Industrie.

Ich bin von Berufswegen für die Ausbildung von Ingenieuren zuständig und beobachte dort zunehmend ein gedankliches Problem: Einige dieser Programmierspezialisten können zwar hervorragend mit diversen Hochsprachen umgehen - und müssen das einem auch ständig und ungefragt unter die Nase reiben. Wenn in einem Diagramm aber mehr als zwei Messsignalverläufe auftauchen ist deren geistiger Horizont bereits überschritten.

Es gibt bei den meisten Problemstellungen mehrere unterschiedliche Lösungswege, doch denke ich, dass die höchste Priorität für einen Ingenieur in der Problemerfassung und der Ergebnisinterpretation liegen sollte, unabhängig davon, mit welchen Tools die Lösung erreicht wird.

Gerade hier liegt aktuell ein großes Problem: Es setzt sich zunehmend eine Ideologie (schon ein direkter Widerspruch zur Technik) durch, man könne mit Software alles lösen. Dies ist sicherlich nicht der Fall. Stattdessen führt diese starke Überbewertung der Rolle der Software zu der Absurdität, dass Studenten drauf los programmieren was das Zeug hält und zugegeben "schöne" Lösungen präsentieren - aber nicht im geringsten wissen, was und warum sie das eben gemacht haben. Wenn ein Ingenieur nicht weiß, was ein Messergebnis aussagt, spielt es auch keine Rolle, ob dieses mit kürzerer Rechenzeit erzielt wurde - es ist wertlos, weil faktisch nicht vorhanden.

Man sollte etwas mehr Wert auf Grundsätzliches legen und nicht soviel Zeit mit möglicherweise höherwertigen Hilfsmitteln verschwenden. Wenn ich nun mal primär an einem Ergebnis interessiert bin, dann tut es für mich auch ein einfacheres Tool. Ich stehe mit dieser Denkweise nicht alleine, ansonsten hätten Programme wie LabVIEW auch keine Präsenz am Markt. Ich selbst arbeite nicht mit LabVIEW, kann aber absolut nachvollziehen, dass viele Ingenieure dem graphischen Interface den Vorzug geben, da es wichtig ist einen strukturellen Überblick zu haben, was bei Programmierung in Hochsprachen weit weniger der Fall ist.

Sprich, man entscheidet sich für ein Tool (hier LabVIEW), weil es die notwendigen Funktionen erfüllt und einfach und übersichtlich ist. Es muss nur funktionieren, die eigentliche Arbeit ist woanders. Warum einige Programmier-Fetischisten das nicht so stehen lassen können und immer etwas zu bemäkeln haben (vergleich bei MATLAB, dort wird die gleiche Diskussion über Skriptsprachen geführt) bleibt für mich ein Rätsel. Ich weiß nur, dass es mich tierisch nervt, dass jeder Informatiker ungefragt über die Vorteile von Lunix und JAVA schwadroniert; und weil dies noch nicht gereicht hat, suchen diese zunehmend die Öffentlichkeit (Wikipedia bietet hier leider eine sehr gute Plattform), um wirklich jedes weit verbreitete Programm pauschal zu kritisieren.

Bitte, lasst uns in Ruhe oder bleibt wenigstens objektiv, einige Menschen haben halt andere Präferenzen als ihr, auch wenn ihr nicht verstehen könnt, dass diese die von Euch so geliebten und verehrten Programme nicht so mögen.

Für mich als Naturwissenschaftler gibt es noch einen großen Vorteil: Mann kann die Syntax nicht vergessen. Insbesondere wenn man nur alle paar Wochen am Programm herumschraubt und dazwischen noch andere Sachen machen muss. Außerdem sieht man bei LabView den Programmablaufplan (bei guter Programmierung) direkt und kann oft das Programm schnell überblicken.--Lukie.80 (Diskussion) 22:54, 17. Jan. 2018 (CET)

Inhalt von "Diskussion:LabView" hierher verschoben

Ist es normal, dass es noch ein LabVIEW existiert?

Nein, normal ist das nicht. --Montauk 01:13, 28. Nov 2004 (CET)

Inhaltlich scheinen sich die beiden Artikel ganz gut zu ergänzen, wir sollten sie aber besser zu einem zusammenfassen. Ich bin dafür, das unter LabVIEW zu tun, da das die offizielle Schreibweise von National Instruments ist. (Abkürzung für "Laboratory Virtual Instrument Engineering Workbench"). --silmaril 13:22, 29. Nov 2004 (CET)

Ich habe die beiden Artikel nun unter LabVIEW zusammengeführt. Die Inhalte des Artikela LabView habe ich übernommen, ergänzt und einige Fehler korrigiert. --silmaril 14:36, 7. Dez 2004 (CET)

Verschoben durch: --SirJective 09:23, 21. Dez 2004 (CET)

LabView 8.20

Ich finde es wäre wichtig zu ergänzen das ab LV8.2 Objekorientiertes programmieren möglich ist. Mit Klassen und Vererbung ein nicht unwesentlicher schritt für die Entwicklung diverser Anwendungen unter LV.--Mr.Sieb 14:44, 15. Aug 2006 (CEST)

Vorschlag: Am Ende des Absatzes "Programmiermethoden" folgendes anhängen

Bei sehr großen und umfangreichen Projekten ist es (wie in jeder Programmiersprache) extrem wichtig, von Anfang an eine durchdachte Struktur zu verwenden und den Code zu Modularisieren. Durch den vorhanden Projektmanager (ab V8.0) wird dies um einiges erleichtert. Die Verwaltung einer großen Anzahl an VI’s sowie externer Dateien ist dadurch um vieles übersichtlicher. Auch die major und minor Versionsverwaltung gestaltet sich hiermit wesentlich einfacher. Eine wesentliche Neuerung (ab V8.20) besteht darin Objektorientiert programmieren zu können. Klassen und Attribute sowie dessen Methoden können natürlich auch vererbt werden.

irgendwelche einwände ? --Mr.Sieb 13:14, 16. Aug 2006 (CEST)

offensichtlich nicht ... eintrag gemacht --Mr.Sieb 15:30, 17. Aug 2006 (CEST)

Versionsnr. aktualisiert auf 8.20-> 8.2.1 --MrSieb 15:10, 26. Apr. 2007 (CEST)

doch, habe Einwände... (wenn auch spät, aber mensch muß ja erstmal auf den Artikel stoßen) Atribute können z.B. nicht vererbt werden, denn sie sind immer privat und es können auch nur spezielle Methoden (dynamische VIs) vererbt werden. auch fehlen diverse Möglichkeiten, die ich bei einer objektorientierten Programmierung erwarten würde (Konstruktoren, Möglichkeit für Interfaces, Factories ...) Insofern hat Labview mit der Einführung von Klassen zwar einen Schritt in Richtung Objektorientiertheit gemacht, aber ich hoffe es bleibt nicht dort auf der Strecke stehen, denn das Ziel ist noch weit entfernt.

das mensch --(nicht signierter Beitrag von 84.58.161.50 (Diskussion) 23:06, 12. Jun. 2007 (CEST))

Screenshots und Urheberrecht

Ich find's ja toll, dass wir jetzt ein paar Screenshots von LabVIEW im Artikel haben. Leider deckt sich das m.E. in keiner Weise mit Wikipedia:Bildrechte#Screenshots. Solange wir keine ausdrückliche Freigabe von National Instruments haben, müssen wir die Bilder wohl aus dem Artikel rausschmeißen.

Irgendwelche Gegenmeinungen?

Macht sich jemand die Arbeit, offiziell bei NI anzufragen? --silmaril 15:57, 28. Aug 2006 (CEST)

Ich werde dies tun, hab gute kontakte bei NI.--Mr.Sieb 15:21, 11. Sep 2006 (CEST)

Habe nicht vergessen, nur immer noch keine Antwort bekommen, werdmal nachhacken. --Mr.Sieb 19:59, 6. Dez. 2006 (CET)

Super, schonmal danke für die Mühe! Ich hoffe, Du bekommst eine sinnvolle Antwort. Leider befürchte ich, dass NI Germany nicht die Kompetenz besitzt, das zu entscheiden, und von den Amis eine sinnvolle Antwort zu Urheberrechtsthemen zu bekommen kann schwierig werden. --silmaril 13:47, 12. Dez. 2006 (CET)

Nachdem bis jetzt immer noch nichts bewegt hat, habe ich die Bilder mal rausgenommen. Wenn jemand Bilder mit NI's Einverständnis besorgen kann, wäre das natürlich super! So ganz grafik-frei sieht der Artikel schon enorm trocken aus :-( --silmaril 22:58, 13. Mär. 2007 (CET)

Sorry, aber das ist echt mühsam hab über meine persönlichen kontakte in Salzburg mal eine Kontakt in den Staaten bekommen dort einige Mails im Kreis geschickt jetzt hab ich zwar den zuständigen Pressekontakt tja und die Dame ist jetzt im Moment nicht erreichbar-> Julia.Betts wrote. I will be out of the office starting 04/02/2007 and will not return until 04/06/2007.

If you need immediate assistance prior to my return please contact Trisha McDonell at 512-683-6215. If this is urgent please try my cell at 512-659-9643.

If this request is urgent call my cell 512-659-9643.

Ich bleib drann versprochen vielleicht find ich noch einen alternativ Kontakt anrufen dort werd ich eher nicht :-) Evtl könnten wir mal fragen woher die bilder im englischen Wikiartikel kommen --MrSieb 11:19, 16. Apr. 2007 (CEST)

Da brauchen wir nicht lange zu fragen. Die Screenshots im englischen Artikel sind alle entsprechend gekennzeichnet. Da steht u.a. "…qualifies as fair use under United States copyright law. Any other uses of this image, on Wikipedia or elsewhere, may be copyright infringement.". Das Problem ist, dass es im europäischen Recht den Begriff "Fair use" nicht gibt. Für die EN-Wikipedia sind die Bilder ok, für DE brauchen wir aber wirklich freie Bilder, da hier die juristischen Ansprüche höher liegen. Meiner Erfahrung nach könnte es sehr schwierig werden, bei den NI-Amis jemanden zu finden, der willens ist, das zu verstehen. Leider gibt es dort sehr viele Leute, für die die Welt am Rande der USA endet. Aber ich will hier niemanden entmutigen ;-) --silmaril 20:24, 18. Apr. 2007 (CEST)

Vor- und Nachteile

Wie weiter oben bereits ausgeführt, sind die unter "Nachteile" aufgeführten Punkte

a) entweder keine Nachteile

b) "Nachteile" bei falscher Bedienung (wobei nicht erklärt wird, wieso diese falsche Bedienung bei LabView wahrscheinlicher ist, als bei anderen Umgebungen)

c) oder Nachteile, welche jede Umgebung hat, jedoch bei LabView DEUTLICH geringer sind, als bei anderen Umgebungen (oder Sprachen). Der "Nachteil" an einer bestimmten Progammiersprache oder Entwicklungsumgebung ist jedoch nur ein solcher im Vergleich zu anderen Sprachen.

Der ganze Abschnitt, zumindest die "Nachteile", sollten neu geschrieben werden und sich dabei an den wirklichen Nachteilen im Vergleich zu Programmiersprachen orientieren. --217.224.26.160 09:21, 12. Dez. 2006 (CET)

Ja, da gebe ich Dir Recht. Jetzt brauchen wir nur noch jemanden, der sich die Zeit nimmt... (nein, ich komme in absehbarer Zeit nicht dazu.) --silmaril 13:44, 12. Dez. 2006 (CET)

---

Ich werd hier mal langsam beginnen die Nachteile zu überarbeiten. Ich werd mal einfach "lautdenken"

• Kleine Änderungen können aufwendige Neustrukturierungen nach sich ziehen, wenn das Schaffen von Raum auf dem Blockdiagramm durch Verschieben geschieht. Denn dann müssen die Drähte und Symbole oftmals neu geordnet werden, um die Übersichtlichkeit wiederherzustellen. Alternativ kann aber auch ein Teil des Codes in ein neues Unterprogramm ausgelagert werden.

Ergänzung-> Allerdings muss hier des öfteren die Struktur bzw. der Ablauf angepasst werden da sich der Gültigkeitsbereich diverser Controlls oder/und Variablen ändert. Mit einem schlichten verpacken in ein Subvi ist es oft nicht getan.

Meiner erfahrung nach ist das wirklich ein extremer Nachteil bei Textbasierten Sprachen sind schnell mal wo ein paar Zeilen eingefügt. Softwareentwicklung und speziel Prototyping ist ein lebender Prozess anfoderungen, änderungen innerhalb einer Projektphase sind keine seltenheit ob selbst verursacht oder durch den auftraggeber ist nicht LV abhängig. ---

• Um keinen Drahtwirrwarr zu erzeugen, werden von weniger versierten Nutzern oft vermehrt Variablen eingeführt, die die Geschwindigkeit herabsetzen und dem Datenflussmodell widersprechen. Erfahrene 'Verdrahter' definieren zusammengesetzte Datentypen, um weniger Drähte verlegen zu müssen.

Ich glaube das kann man völlig weglassen fehlerhafte bedienung kann einer Software nicht zum Vowurfgemacht werden es gibt ja nich umsonst Labview Kurse oder CodingStyle vorgaben. ---

• Der einfache Einstieg in die LabVIEW-Programmierung verleitet leider dazu, "einfach drauflos zu programmieren", allerdings kann auch die grafische Programmierung nicht die ordentliche Planung des Projektes ersetzen.

Auch das sollte wegfallen, Labview ist eine Programmier umgebung für Techniker&Programmierer zu gleich der Techniker hat die möglichkeit sehr schnell Lösungen für spezifische Problem selbst zu realisieren Komplexe Anwednungen brauchen in jeder Sprache ein ordentliches Konzept und eine gute Planung ---

• Die Signalorientierung führte in früheren Versionen zu einem Polling der Signalquellen und GUI-Elemente in Schleifen, anstatt zu einem von Ereignissen ausgelösten Signalfluss. Seit LabVIEW 7 existieren auch sehr weitgehend konfigurierbare Eventstrukturen, die auf Ereignisse aus dem Benutzerinterface und auf Systemereignisse reagieren können. Das vermeidet beim Pollen verschwendete Rechenzeit und erlaubt sehr effektive Konstrukte, insbesondere beim Benutzerinterface.

Nachteil?Vorteil? eher eine Eigenschaft von LV, Evtl könnte man hier den NAchteil Grafischer anzeigen in LV prinzipielle erwähnen (noch)keine direkt unterstüzung von 3D beschleunigung Stichwort 3DGraph etc.. ---

• LabVIEW-Programme lassen sich nur mit der originalen LabVIEW-Entwicklungsumgebung bearbeiten, an dessen Funktionsumfang man gebunden ist. Insbesondere ist keine ausgewachsene Versionsverwaltung mit all ihren Vorzügen möglich, was auch das kollaborative Arbeiten erschwert.

Also is man nicht immer an die entwicklungsumgebung gebunden ?? Auserdem besitz LV mittlerweilen sehr viele schnittstellen, ActivX, .net extern dll aufrufe stellen auch kein problem dar um nur ein paar zu nennen. Versionsverwaltung Gibt es mitlerweile in Kombination von 3rd Party CVS,MS Sourcode Management etc. etc. Das Modul von NI ermöglicht dann bei Konflikten die Grafische darstellung der änderung und makiert diese im Blockdiagramm da dies ja das eigentlic problem der Versions verwaltung darstell das handling von Binärdatei ansonst klappt das nur mit CVS auch ganz gut gibt dann eben keine Merge oder compare Funktionen wobei SourCode Managment Software Tools automatisch mergen zu lassen meiner meinung nach sowieso an selbstmord grenzt :-) ---

• Ausführbare LabVIEW-Programme können vom Entwicklungssystem zwar erstellt werden, erfordern jedoch die Installation einer Laufzeitumgebung auf dem Zielsystem. Bei Verwendung von bestimmten Zusatzmodulen, wie z.B. IMAQ Vision, ist zudem eine kostenpflichtige Lizenz pro Zielplattform notwendig.

Über das LizenzModell von NI möcht ich jetzt gar ned genauer nachdenken da bekomm ich nur einen hohen Puls definitiv ein NAchteil das für jedes noch so kleine Modul kassiert wird. die Laufzeitumgebung ist auch bei VB oder .net nötig oder Java also eigentlich fast normalfall.

Weitere Gedanke bzw ergänzungen Folgen.. bitte um feedback

--MrSieb 15:58, 26. Apr. 2007 (CEST)

---

Ich habe folgenden Teil aus der Sektion Nachteile gelöscht:

• aufgrund der vorprogrammierten Blöcke, die in den vorgefertigten Libraries von Labview angeboten werden, die wiederum aus verschiedensten Unterebenen bestehen, die noch mehr Blöcke enthalten für Simulationen oder Erstellung von Reglern für mechatronische Systeme mit Echtzeitanforderung weniger geeignet als zum Beispiel Simulink, in der jeder Block eine bestimmte Funktion besitzt und man daher die volle Kontrolle über sein grafisch erstelltes Programm inne hat.

Die große Anzahl an Applikationen, in denen LabVIEW mit hoher Performance und geringem Jitter Echtzeitaufgaben z. B. im HIL-Bereich erfüllt, spricht eindeutig gegen diese Aussage. Natürlich ist es bei Echtzeitanwendungen z. B. selten sinnvoll, High-Level Express-VIs einzusetzen, die letztendlich Komfortfunktionen für Einsteiger darstellen. LabVIEW bietet in vielen Fällen unterschiedliche Abstraktionslevel für die verschiedenen Funktionspaletten an. Von High-Level Komfortfunktionen bis zu Low-Level-Funktionen für höchste Performance und Transparenz. Wenn Simulink keinen High-Level-Ansatz bietet, kann man das wohl kaum als Nachteil von LabVIEW bezeichnen.
--Proteus1902

---

Sehe ich genauso.

Zitat: "Kleine Änderungen können aufwendige Neustrukturierungen nach sich ziehen, wenn das Schaffen von Raum auf dem Blockdiagramm durch Verschieben geschieht, da dann die Drähte und Symbole oftmals neu geordnet werden müssen, um die Übersichtlichkeit wiederherzustellen. Dieses Problem kann durch Strukturierte Programmierung gemildert werden (insbesondere durch konsequente Verwendung von Sub-VIs).

Der einfache Einstieg in die LabVIEW-Programmierung verleitet dazu, „einfach drauflos zu programmieren“, allerdings kann auch die grafische Programmierung nicht die ordentliche Planung des Projektes ersetzen."

Also mit anderen Worten: "Der Einstieg in LabView ist zu einfach. Bei dem Einstieg in eine Programmierumgebung hat man sich gefälligst gehörig 'einen ab zu brechen' - sonst kann es ja nix sein!" Oder was genau ist mit der Kritik gemeint, dass wenn man aus Unerfahrenheit falsch programmiert, man Probleme bekommt? Man könnte es eher als Vorteil sehen, dass man selbst als unerfahrener Programmierer viel früher schon was (unsauberes -jedoch funktionierendes!) auf die Beine stellen kann. Wärend in C noch geflucht wird, dreht sich bei LabView immerhin schon was - wenn auch mit "Drahtwirrwar" - das jedoch später mit mehr Erfahrung nicht mehr auftritt. MV --84.171.54.139 20:53, 5. Feb. 2008 (CET)

---

Bei Nachteile würde ich den Verweis auf "Strukturierte Programmierung" raus nehmen, da in dem Artikel von einer sequentiellen Programmabarbeitung ausgegangen wird. Die große Stärke von LabView sehe ich eher in der parallelen Programmabarbeituung, wie sie z.B. auf FPGAs genutzt wird. Gegenüber VHDL ist das natürlich deutlich übersichtlicher... Für sequentielle Programme würd ich tendenziell andere, "Schrift-Sprachen" nutzen -- 77.8.138.128 22:37, 13. Mär. 2009 (CET)

---

Ich habe "Das Realisieren von binären I/O Kommunikationsprotokollen (z.B. Kommunikation mit einem µC über RS232) ist wesentlich schwerer zu realisieren, als in textbasierten Programmen." von den Nachteilen entfernt. Meines Erachtens (ich programmiere mit LV seit knapp 4 Jahren, davon die Hälfte Kommunikation mit µCs über die RS-232) ist das in LV nicht schwerer als in anderen Sprachen, schon gar nicht wesentlich schwerer. Wer anderer Meinung ist bitte genauer beschreiben. -- Marco.Geisler 12:42, 21. Apr. 2009 (CEST)

Ich habe mehrere Jahre LabVIEW-Erfahrung, habe neulich jedoch zum ersten mal eine solche Kommunikation mit einem µP über RS232 ausprobiert. Es war wirklich sehr einfach - kann mir nicht vorstellen, dass es in einer Hochsprache einfacher gehen soll. MV --79.199.165.101 15:27, 10. Dez. 2009 (CET)

Zur Performance

Ich halte die Behauptung, daß die Performace von LabVIEW vergleichbar ist mit der von anderen Hochsprachen, für irreführend. Das mag für Code stimmen, der innerhalb von „festverdrahteten“ (d.h. von NI nicht in G programmierten) VIs ausgeführt wird. Alles, was man aber selber verdrahtet, wird erheblich langsamer ausgeführt und erreicht nicht einmal die Geschwindigkeit von Skriptsprachen wie Python. Ein dramatisches Beispiel dafür ist der XML-Parser, der von NI bei LabVIEW 7 mitgeliefert wurde und bedauerlicherweise nicht in C, sondern in G programmiert war. Für eine 1MB-XML-Datei benötigte er ca. eine Minute. In meinen Augen ist diese mangelnde Performance auch unter "Nachteile" aufzuführen.

Die Aussage von NI, daß G „kompiliert“ wird, ist kaum zu bewerten, weil Kompilieren ein sehr weiter Begriff ist. Skriptsprachen kompilieren für eine virtuelle Maschine, wobei weite Teile auch direkt in Prozessorcode übersetzt werden können (JIT-Compiler). Die Grenzen sind also fließend. Entscheidend ist die Maschinencodequalität, und da geben meine Tests LabVIEW in rein algorithmischen Programmen (d.h. alles selbstverdrahtet, keine Fix-und-Fertig-VIs) schlechte Noten.

Ich stelle das hier zur Diskussion, weil ich kein LabVIEW-Experte bin und meine Beobachtungen sich nur auf unsere LabVIEW-Installation beziehen. – Torsten Bronger 13:25, 26. Apr. 2007 (CEST)

--- Ich kann keine Zahlvorweisen und habe selbst nicht wirklich Tests irgenwelche art bezüglich performance gemacht also vergleichende performance. Beim XMLParser glaub ich das sofort wobei Parser ja immer "langsam" sind meiner erfahrung nach spzeziell wenns um Strings geht. Wirklich probleme bezüglich performanche hab ich nur im bereich der JET Engine gemacht (zugriffe auf AccessDatein). Bei sehr, ich sag mal trägen LV anwendungen, ist in 90% der Fälle unsauberer code bzw. schlechtes Konzept schuld oft kommt noch hinzu das Anwendungen nicht als Applikation betrieben werden (exe) sonder von der Entwicklungsumgebung aus gestartet werden hier ist in den meisten Fällen die Debug funktion aktiv die anwendungen oft um eine Faktor 10 langsamer macht. Ich bin mir sicher das performance problem wie in jeder Sprache durch ein "besseres" Konzept (wie in andere sprachen auch) eleminiert werden können. Weiter gibt es die möglichkeit das RT(RealTime) System zu verwenden. Dies macht die anwendung jetzt nicht zwingend schneller aber sie wird zu 100% deterministisch.

NI Vis sind meines wissens schon in G programmiert nur ist meist das Blockdiagramm nicht zugänglich es mag auch Vis geben die von Ni geschrieben dlls benutz in welche sprache diese geschrieben sind ist mir nicht bekannt.

Das stimmt. Die Blockdiagramme sind meistens passwortgeschützt. Oder es wird eine DLL (C oder C++) verwendet.

--MrSieb 16:33, 26. Apr. 2007 (CEST)

Also schlampige Programmierung war bei meinen Beobachtungen nicht im Spiel.  ;-) Ein ganz einfaches Programm, das an einen String schlichweg ein "a" anfügt und das viele Male, läuft in LabVIEW rund 70 mal langsamer als in Python, und Python-Programme werden von einer virtuellen Maschine interpretiert und benutzen nicht mal [JIT]-Technologie.

Klick mal auf das Glühbirnen-Symbol. Dann rennt die Applikation aber wie verrückt.

Allerdings haben wir hier LabVIEW 7.0 Express. Damit kann ich, soweit ich weiß, keine Stand-Alone-EXE-Datei bauen. Ich kann jedoch die "Fehlerbehandlung" und die "automatische Fehlerbehandlung" in den VI-Optionen ausschalten – bringt aber nichts. Es kann zwar sein, daß nur die String-Funktionen von LabVIEW Mist sind, aber es ist unwahrscheinlich. Die Operationen sind zu einfach, als daß LabVIEW da besonders schlecht sein sollte. Im übrigen habe ich auch numerische Berechnungen auf großen Arrays als C++-Code ausgelagert.

Und das ist auch gleich ein gutes Stichwort: Es ist nämlich nicht schlimm, wenn LabVIEW langsam ist. Für 95% eines Programms ist das unerheblich, und den Rest kann man in C++ oder was auch immer programmieren und einbinden. Macht man in den ganzen Skriptsprachen ja nicht anders. Bloß sollte der Wikipedia-Artikel das auch so sagen und nicht die Werbeslogans von NI nachplappern.

Hat jemand einen Link zu einer Benchmark-Seite oder etwas in der Richtung? – Torsten Bronger 09:14, 27. Apr. 2007 (CEST)

Gerade das Beispiel mit dem Anhängen an einen String trifft einen Punkt, an dem LabVIEW sich von den meisten Programmiersprachen erheblich unterscheidet. Fast alle Datenübergaben in LabVIEW sind by value. Ein optimaler Algorithmus für den beschriebenen Test würde selbstverständlich mit Pointern arbeiten (zumindest hinter den Kulissen). Dies wäre aber mit dem Datenfluss-Modell von LabVIEW nur extrem schwer vereinbar, wenn man berücksichtigt, dass der Compiler auch deutlich komplexere Programmstrukturen fehlerfrei umsetzen muss.

Offenbar war bei diesem Test ein gewünschter Weg zum Ziel Bestandteil der Aufgabenstellung. Das ist wenig zielführend. Durch das Datenfluss-Konzept unterscheidet sich LabVIEW so maßgeblich von sequentiellen Programmiersprachen, dass man in vielen Fällen bei den Algorithmen anders denken muss. Salopp gesagt: "Der Versuch in LabVIEW C zu programmieren wird scheitern."

Die erwähnten Häkchen zur "Fehlebehandlung" dürften bei der Performance übrigens keine Rolle spielen, da es hierbei um Fehler-Dialoge geht. Wichtig ist vielmehr "enable Debugging" (ich weiß jetzt nicht, wie das in der deutschen Version heißt).

Eine differentierte Betrachtung der Performance ist also alles andere als trivial. Es hängt immer von der Aufgabenstellung im Einzelfall ab, und davon, wie sie umgesetzt ist. Für größere Number-Crunching-Algorithmen binde ich auch lieber eine C-DLL ein. Das hat meist nicht einmal viel mit der Performance zu tun, sondern eher damit, dass sich komplexe Formeln in textorientierten Sprachen intuitiver darstellen lassen (in vielen Fällen ist auch der Formelknoten eine Alternative).

Die Beobachtunng, dass an schlechter Performance schlechter Code schuld ist, kann ich nur bestätigen. Gerade der einfache Einstieg in LabVIEW führt sehr häufig dazu, dass sich die Anwender nicht weitergehend mit der Thematik befassen. Das Ergebnis sind dann oft unsinnige Herangehensweisen und daraus resultierend mieserable Performance. Die Schuld wird dann meist LabVIEW gegeben, obwohl ein fähiger LabVIEW-Programmierer hier wesentlich mehr "herausholen" könnte. --silmaril 13:21, 6. Mai 2007 (CEST)

Das ist mir zu vage. Ich kann ganz gut programmieren und habe LabVIEW verstanden, und trotzdem geht die Performance in die Knie, sobald das Programm vom einfachen "Daten fließen von links nach rechts sequenziell durch verschiedene VIs" abweicht, d.h. Falluntescheidungen, Schleifen etc. eine Rolle spielen. Zumal der erwähnte lahme XML-Parser von National Instruments verfaßt war und die wohl einige Experten haben.

Und damit nochmal zum Ursprung: Ich halte die Aussage des Artikels "die Performance [ist] vergleichbar mit der anderer Hochsprachen" für falsch, und auch das mit dem kompilieren würde ich rausnehmen, schlicht weil keiner weiß, was dieser Compiler wirklich erzeugt, und compilieren ein weiter Begriff ist. Wenn also keiner mir ein performantes algorithmisches VI zeigen kann, mache ich das in den nächsten Tagen. – Torsten Bronger 22:26, 9. Mai 2007 (CEST)

Wie man schnellen Kode schreibt und was man dafür nicht tun sollte ist ja auch nirgends dokumentiert, sondern muss jeder LabVIEW-Programmierer durch mühseliges Ausprobieren herausfinden. Auch dass Express-VIs (nur) zum Einstieg da sind, ist nicht dokumentiert. Auch gibt es Situationen, wo sinnlos Speicher volläuft, und der lässt sich nicht mehr freigeben.

Wenn etwa schon das Auslesen von Messdaten aus einer Messkarte (bspw. 2,5 MSa/s und 20 Kanäle) den Rechner in die Knie zwingt, muss man sich anschließend mühselig vom standardmäßigen Double-Signal-Output zum Int16-Array-Output (zudem undokumentiert verschachtelt) durchwursteln (was tatsächlich hilft) und darf anschließend das gesamte Programm umschreiben und eine Unmenge VIs neu basteln. Und dann bricht die Performance "hinten" zusammen, weil man eben selbstgeschiebene VIs zum Berechnen benutzt. Dieser Versuch war also auch für die Katze, und installiert einen C-Compiler.

--Henrik Haftmann (Diskussion) 14:58, 8. Aug. 2012 (CEST)

Die Coding Challenge zeigt des öfteren was möglich ist Einzige regel KeinExterner Code :-) http://zone.ni.com/devzone/cda/tut/p/id/5286 hier zb Primfaktoren zerlegung, ursprünglich war das zeit limit für 100 Zahlen 10 minuten der schnellste code hat es in 86ms bewältigt. Keine Ahnung ob du soetwas sehen wolltest, Ich habe mich auch umgesehen ob es irgen welche benchmarks gibt die Sprachen mit einader vergleichen muss aber meinem vorredener recht geben einen objektiven vergleich zu machen ist mehr als schwierig. Das einzige was ich gefunden habe war das http://www.vi-lib.com/vi.lab/BenchmarkExecutionSpeedof.html bezieht sich noch auf 6i und 7 Express. btw LAbview Express bedeutet lediglich nur das die neuerung der Express Vis hinzu gekommen ist (Standalone EXE erzeugen ist mit dem Applikationbuilder möglich). Express Vis sind wizzards die code generieren um schnell ergebnis zu erreichen die performance ist echt misserabel selbst Ni empfiehlt Express Vies nur zum "testen" zu verwenden. Der Compiler erzeugt Maschinen Code -> http://www.ni.com/devzone/lvzone/dr_vi_archived6.htm Aber vermutlich alles marketing ;-) Klar jemand der sich hinsetzt schreibt mit sicherheit in C oder C++ oder gleich in Assambler schnelleren code nur hald in der 10fachen entwicklungszeit (ich bin mir sicher das der faktor trozdem unter 2 bleibt) aber nimms raus der Ganze Artikel muss sowieso komplett neu aufgebaut werden. Der einwurf "was ist LAbview" ist nicht von der hand zu weisen.--MrSieb 11:59, 15. Mai 2007 (CEST)

Also die Coding Challenge beeindruckt mich nicht, weil mir da die Vergleichsmöglichkeiten fehlen. Aber das mit dem Kompilieren überzeugt mich. Das kann als Kompilieren durchgehen, auch wenn der Maschinencode sicherlich um einiges schlechter ist als der der kompilierenden Hochsprachen. Aber vor der Großen Überarbeitung ändere ich da nichts. – Torsten Bronger 21:45, 17. Mai 2007 (CEST)

Was ist Labview

Leider ist der derzeitige Artikel für solche Leser geschrieben, die Labview schon kennen. Denn es ist nicht einmal vernünftig erklärt, was Labview ist und wozu es da ist. Es ist sogar so schlecht erklärt, dass ich aufgrund des Artikel nicht einmal weiß, welche Fragen ich hier stellen müsste. Nur durch Infos von außerhalb habe ich eine vage Vorstellung, wie sie lauten. Als da wären:

• Läuft Labview auf einem PC?
• Braucht es oder hat es für gewöhnlich eine Verbindung zu Geräten außerhalb des PC? Welche Geräte sind dies? Wie werden sie angebunden?
• Welche Aufgabenstellung hat Labview zu erfüllen (einfache Beispiele)?
• Welche Mittel werden eingesetzt, um diese Aufgabenstellung zu erfüllen?
• etc. (weitere Fragen vermag ich im Moment nicht zu stellen.)
• -- 84.132.90.31 18:38, 6. Mai 2007 (CEST)

Es fehlen tatsächlich Erläuterungen zum LabVIEW-Prinzip. LabVIEW ist irgendwo zwischen Visuelle Programmierumgebung und Datenstromorientierte Programmierung angesiedelt. Am besten passen die Erläuterungen, die man bei en:Visual programming language findet. -- Kerbel 21:50, 6. Mai 2007 (CEST)

Ich kenne LabVIEW aus der Gebäudeautomatisierung. Man kann mit LabVIEW eine Benutzeroberfläche einrichten, auf der man Regler für die Steuerung der verschiedensten Geräte hat (für Heizkörper, Jalousien, Videokameras und andere). Man wird die Benutzeroberfläche außerdem so einrichten, dass der Ist-Zustand der Geräte abgelesen werden kann, außerdem auch Sachen wie Raumtemperatur, Außentemperatur, Angaben darüber, welche Fenster geöffnet sind und anderes. Der LabVIEW-Programmierer kann im Hintergrund festlegen, wann welche Geräte auf ihren Zustand abgefragt werden sollen, welche Aktionen unter welchen Bedingungen automatisch ausgeführt werden sollen, wann auf der Benutzeroberfläche ein Alarm ausgegeben werden soll und anderes. Ob man den Einsatz in der Gebäudeautomatisierung als typisches Einsatzgebiet für LabVIEW-Programme sehen kann, das weiß ich nicht. -- Kerbel 23:57, 6. Mai 2007 (CEST)

Rekursionen

Wie kann ich denn in LabVIEW rekursive Aufrufe umsetzen? Das ist eine ernstgemeinte Frage. Sobald ich beispielsweise eine Fakultätsfunktion rekursiv umsetzen möchte, hagelt es Fehlermeldungen.

--TorPedo 23:15, 10. Okt. 2007 (CEST)

Wie auch im Artikel angedeutet, gibt es in LV "eigentlich" keine Rekursion. Wie es dennoch geht steht z.B. hier: http://digital.ni.com/public.nsf/allkb/7140920082C3AC15862572840015A81E

Näher möchte ich an dieser Stelle nicht auf die Frage eingehen, da dieser Platz für Diskussionen über den Artikel gedacht ist. Fragen zu LV sind in den verschiedenen LV-Foren besser aufgehoben. --silmaril 14:44, 12. Okt. 2007 (CEST)

Was Rekursion angeht - es war auch früher möglich, jetzt, seit LV 2009 ist es einfacher zu implementieren. Aber der Link hat mit Referenzen wenig zu tun. (nicht signierter Beitrag von Labview (Diskussion | Beiträge) 01:34, 1. Okt. 2009 (CEST))

Alternativen Freeware

Ich bin der Meinung es könnten vllt Links zu Alternativen zu LabVIEW hinzugefügt werden, da LabVIEW in der einfachsten Version schon über 1.000 Euro kostet. --Jobe09 09:20, 10. Feb. 2010 (CET)

Welche denn? Curtis Newton ↯ 09:32, 10. Feb. 2010 (CET)

Literatur?

Ich bin etwas skeptisch, ob diese Literaturliste das Thema ideal repräsentiert. Georgi und Mütterlein ja, aber warum 2 Mal Rahman Jamal? Tagungsband = irrelevant, Grundlagenbuch nicht mehr erhältlich..--88.65.143.172 10:10, 6. Dez. 2010 (CET)

Bin nach kurzem draufschauen der gleichen Meinung und habe die beiden Bücher entfernt. Curtis Newton ↯ 13:23, 6. Dez. 2010 (CET)

Eventuell sollte das Buch Einführung in Labview auf den neuesten Stand gebracht werden. Es gibt nun die 5.Auflage ISBN 978-3-446-42386-2 (nicht signierter Beitrag von 217.10.52.10 (Diskussion) 09:03, 13. Nov. 2013 (CET))

Fragen

Hallo, ich würde es begrüßen, wenn der Artikel dahin gehend ergänzt werden könnte:
Unterschiede zwischen den einzelnen LabView-Versionen?
Welche LabView-Version läuft unter welcher (Windows- oder Linux-)Version? (Z.B. arbeiten manche noch auf Systemen mit älterem Windows (bspw. WINDOWS XP) und/oder wollen es auf einem älteren, ausgedienten, aber noch funktionsfähigem Rechner darauf testen/ausprobieren/kleine Experimente/erste Geh-Versuche damit anstellen.)
Gibt es eine kostenfrei- bzwizensierbare, evtl. abgespeckte LabView-Version zum Kennenlernen oder Ausprobieren?
(Ein User hat ja bereits hier im Diskussionsbereich darauf hingewiesen, daß selbst die "Basic"-Version erst ab 1000 Euro zu haben ist …)
Gibt es GNU- oder LGPL-lizensierte Alternativen ? Oder überhaupt gar keine ?
Vielen Dank für die Ergänzung des Artikel. MfG --Guenni60 (Diskussion) 15:27, 18. Jun. 2021 (CEST)

Seit 2020 gibt es eine kostenlose "Community"-Version, die laut NI denselben Funktionsumfang hat und nur die Einschränkung trägt, dass der Einsatzzweck u.a. nichtkommerziell sein muss: https://www.ni.com/de-de/about-ni/newsroom/news-releases/ni-releases-free-editions-of-flagship-software--labview.html --129.206.221.203 18:14, 2. Nov. 2021 (CET)