Hallo, ich will mit Hilfe von Labview eine Software schreiben, die mir eine bestimmte analoge Wellenform aus verschiedenen Stücken zusammensetzt, die alle unterschiedlich getimed sein können, die Anordnung permutiert und sowas. Ich programmiere sonst Python, Matlab, ein Wenig C... Aber mein Problem ist nun, ich krieg keinen Fuß auf den Boden. Ich hab keinen Plan wie ich da ran gehen muss, es gibt tausend seltsam heißende Strukturen, unterteilt in Frontpanel und Backend, keine Ahnung was ich da wie nehmen soll. Ich sitz jetzt schon 2 Tage da, und bekomm nicht viel mehr als irgendwelchen vorgekochten Mist aus Signalgeneratorassistenten. Arrays erstellen, an bestimmten Punkten bestimmte Signale einfügen, keine Ahnung wie das wirklich geht. In Python hab ich das in einer halben Stunde programmiert, wenn ich die Kaffeetasse vorher noch selber spülen muss. Ist diese schwierige Durchdringbarkeit von LabView eine allgemeine Sache, oder ist das nur meine Wahrnehmung? Ist die Software so kompliziert oder bin ich echt nur zu dumm? Tutorials etc. hantieren auch alle entweder nur mit DAQ-Assistenten oder zählen einfach die verschiedenen Strukturen auf...
:
Gesperrt durch User
Ging mir bei Version 3 auch mal so. Damals waren noch einige Bugs drin. Nachdem mir dann jemand ca. 2 Stunden lang gezeigt hat, wie man anfaengt, ging's dann aber recht gut. Nur der Anfang ist nicht ganz einfach, weil es ja nur bedingt mit Programmieren zu tun hat. Ob es "Scheisse" ist, darfst Du gern fuer Dich selbst beurteilen. Mit den heutigen Moeglichkeiten und meinem heutigen Wissen wuerde ich wahrscheinlich nicht mehr damit anfangen, da gibt es andere Software insbesondere unter Linux, die u.a. flexibler und schneller ist. Desweiteren ist der finanzielle Aspekt bei Labview zu beachten. Fuer jeden Arbeitsplatz eine Lizenz, die m.E. ueberteuert ist. Man merkt, dass NI inzwischen zu gross geworden ist und zu viele Firmen davon abhaengig sind. Und die neuen Versionen kann ich als E-Techniker eigentlich auch nicht mehr gebrauchen. Ab 5.1 war es fuer meine Zwecke ausgereift. Gruss hro
> da gibt es andere Software > insbesondere unter Linux, die u.a. flexibler und schneller ist. Zum Beispiel???
Ich meine damit keine spezifische Software, sondern viele verschiedene, meist kostenlose Pakete, die man sich je nach speziellem Anwendungsfall zusammenstellen kann. Ich persoenlich programmiere gern in Perl und binde dann Bibliotheken oder auch externe Anwendungen ein, wenn ich spezielle Anforderungen habe, z.B. Grafiken zeichnen muss oder ein GUI benoetige. Das Programmieren mit Labview (6.1) unter Linux ist ein ziemlicher Krampf und leider von den HW-/SW-Voraussetzungen sehr limitiert. Gruss hro
Wenn du Alternativen zu Labview hast dann lass es sein. Leider gibts die meistens nicht, weil es für viele Geräte nur Labview Treiber gibt oder der ganze Rest der Firma/Uni mit Labview arbeitet. Es ist nicht "scheiße" aber für eine bestimmte Zielgruppe. Wenn du heute schon 100% weißt was das Programm machen soll und wie genau der Labview Schaltplan aussehen soll und wenn du viele Geräte benutzt für die du Labview Treiber hast, dann ist es ok. Nachträgliche Änderungen an einem Programm führen schnell zu Chaos. Mal ein paar Tipps für den Anfang: Benutze möglichst viele Lokale und besonders globale Variablen. Und dann möglichst viele Funktionen in Sub-VIs auslagern. Nicht unbedingt weil man es vielleicht mal wieder braucht sondern eher um den Haupt-Schaltplan übersichtlich zu halten. Zu den Sub-VIs immer schön Bildchen malen damit man gleich sieht was die machen.
Wie bei jeder Programmiersprache, muss man sich erstmal an diese gewoehnen, die Eigenarten kennen lernen und die moeglichkeiten der Entwicklungsumgebung nuetzen lernen. Bei LabVIEW ist das ganze etwas gewoehnungsbeduerftiger, da man die Denkweise der bekannten textbasierten Programmierung nich ohne weiteres direckt uebernehmen kann. Dennoch muss jeder fuer sich entscheiden was besser oder schlechter ist. Ich persoenlich denke, dass die grafischen Programmiersprachen immer mehr kommen werden, weil unser Gehirn empfaenglicher fuer einen bunten Kasten ist, als fuer hunderte zeilen Code. Da aber die meisten von uns zuerst eine Textbasierte Programmiersprache lernen, stoesst LabVIEW bei vielen erst einmal auf Ablehnung. Bei mir war es nicht anders. Die staerken von LabVIEW liegen vor allem im DAQ. Man findet nahezu fuer jede Anwendung die passende Hardware direckt von NI oder unzaehligen anderen Anbietern. Mir persoenlich ist kein anderes Werkzeug bekannt, mit dem ich in der lage bin, auf einem System und innerhalb weniger minuten die Signalgenerierung, Signalaufnahme und Siganlverarbeitung zu realisieren. Lasse mich gerne eines besseren belehren.
Thomas schrieb: > @hro > ja aber kann man mit Perl ein USB-Scope auslesen? Ja sicher. Aber ich muss mich um das Protokoll selbst kuemmern und kann nicht einfach eine vi aus Labview nehmen. Und fuer die Darstellung benoetige ich wieder etwas Hirnschmalz und vor allem ZEIT. Das ist es ja, was Labview fuer Firmen so attraktiv macht. Messtechnische Aufgaben klatscht man mit Labview recht zuegig zusammen. Gruss hro
Wenn hro schreibt, dass LabView nur bedingt mir Programmierung zu tun hat, muss ich aber entschieden widersprechen. Das ist genau die Meinung, die Vorgesetzte in der Firma haben: Da muss man ja nur ein paar Blöcke miteinander verbinden, dann läufts und macht ne schöne GUI. Dem ist aber in keinster Weise so. Ich habe in der Firma in den letzten Jahren große bis sehr große LabView- und C-Projekte umsetzen dürfen und kann daher beurteilen, dass die Komplexität von LabView keineswegs geringer ist als die von C. Die Anwendungsfälle unterscheiden sich natürlich, zumindest bei uns, sehr stark. LabView hat zwei große Nachteile: 1. Viele Studenten lernen LV in der Uni. Dann kommen sie in die Firma und meinen dies anwenden zu können. Heraus kommt der letzte Murks (unübersichtlich, nicht wartbar...). Dass sich dann gestandene Programmierer nicht auf sowas einlassen ist nachvollziehbar. 2. Wie auch hier schon angesprochen arbeiten viele Leute (vor allem im privaten Bereich) mit LabView 6.1 . Die Version ist ja kostenlos. Aktuelle Versionen haben jedoch ganz andere Möglichkeiten. Interessierte sollten sich mal eine 30Tage-Eval besorgen, um dies mal sachlich beurteilen zu können. Und zum TO: Das Problem beim Programmieren liegt meistens zwischen Tastatur und Bürostuhl!
Das Problem ist, dass man ein Labview Programm nicht einfach ändern kann wenn es fertig ist. Da muss man alles neu zurecht schieben, Verbindungen neu machen usw. Wenn man eine Variable die ganz links im Schaltplan ist ganz rechts dann nochmal braucht? Entweder lange Leine ziehen oder extra lokale Variable machen. Wenn man den Variablen sinnvolle Namen gibt die länger als "Signal" sind ist der Bildschirm schnell voll. Dann muss man Sub-VIs erstellen. Und dann wieder alle Variablen die im Sub-VI gebraucht werden verbinden... Zoom Funktion gibt auch nicht. Thomas
> Das Problem ist, dass man ein Labview Programm nicht einfach ändern kann > wenn es fertig ist. Da muss man alles neu zurecht schieben, Verbindungen > neu machen usw. Wenn man eine Variable die ganz links im Schaltplan ist > ganz rechts dann nochmal braucht? Entweder lange Leine ziehen oder extra > lokale Variable machen. Wenn man den Variablen sinnvolle Namen gibt die > länger als "Signal" sind ist der Bildschirm schnell voll. Dann muss man > Sub-VIs erstellen. Und dann wieder alle Variablen die im Sub-VI > gebraucht werden verbinden... Zoom Funktion gibt auch nicht. > > Thomas Noch nicht mal Cluster kennen, aber rumflamen. Das hat man gern :-) LabVIEW ist genau so eine vollwertige Programmiersprache wie es C oder C++ sind. Sie hat Vorteile (gute Übersichtlicheit, DAQ, verfügbarkeit Gerätetreiber) und Nachteile (Performance, verleitet zum unsauberen Programmieren), wie jede andere Sprache auch. Dem TO würde ich empfehlen eine Schulung bei NI zu besuchen. Alternativ kann man natürlich auch Tuturials durcharbeiten, aber das ist lange nicht so effektiv.
Ich kenne Cluster und mag Labview trotzdem nicht. Habe aber auch nie behauptet dass das keine vollwertige Sprache sei. Ganz im Gegenteil, da kann man "alles" mit machen.
Ich habe mir jetzt "Einführung in LabView" von Georgi und Metin gekauft und jetzt geht es halbwegs. Ich hatte erst ein anderes englisches Buch und die NI Schulungsunterlagen, aber die waren so konfus, keine Ahnung. Das war mehr Verkauf und "das kann man machen", als wirklich mal eine Einführung in die Konzepte. So langsam geht es voran, wird aber wohl noch bis nächste Woche dauern, bis ich die Applikation dann fertig habe. Erstmal kämpfe ich mich durch die prinzipielle Struktur von LabView. Aber man muss wirklich sagen, dass die Bedienbarkeit und die Intuitivität in der Vielzahl der Optionen und Möglichkeiten ertrinken. Man kann alles machen- aber selbst beim kleinsten Kram muss man sich durch den riesigen Haufen wühlen. So Sachen wie die Optionen im Kontextmenu tlw.- furchtbar!
>Ist LabView Scheiße, oder bin ich dumm?
Aber sicher. Totaler Mist. Drueck den Dreck in die Tonne. Waehhhhhhhh.
Eine viel bessere Alternative ist das LabWindows von derselben Firma,
auch mit all den Treibern fuer die Gerate.
Und immer diese Tabelle beachten: http://digital.ni.com/public.nsf/websearch/da470eb199497f4086256931007050c0?opendocument&node=13106_US Anders gesagt: immer schön die neuste Verson kaufen.
Hasso Jupp, schreib einmal deine Sezifikation und Deine LabVIEW Version auf. Welche Probleme hast Du genau ?
Hallo Die NI-Produkte (LV,LW) kenne ich nur bedingt (LW Ver.3) Damals war es für mich gut, ich konne Basic-Programme nach C übersetzen und so die ersten Versuch in C machen (schon eine Weile her). Als Messtechniker war mir die textuale Programmierung für meine Aufgaben aber zu aufwendig. Deshalb habe ich mich für eine graphische Sprache entschieden. Zur Diskusion standen LV und HP VEE (HP= Hewlett Packard heute Agilent), da es auch unter Unix lief. Leider läuft VEE heute nur noch unter Windows und hat eine Menge Funktionen, die ich nicht brauche. Ich persönlich halte VEE für die übersichtlichere "Sprache", wobei NI erheblich mehr Werbung macht als Agilent. Natürlich ist die beste Programmiersprache die, die ich kenne und bei jeder Programierung ist Disziplin gefordert ;-) Wobei natürlich zu beachten ist, das nicht jede Programmiersprache für jeden Zweck geeignet ist. Mit VEE ein Spiel zu programmieren geht (Beispiel vorhanden), aber das ist so, als wenn ich mit meinem Fahrrad an einem Radrennen teilnehmen würde: Ankommen würde ich auch ;-) Noch ein Wort zu den Gerätetreibern (bei LV heißt das wohl VI): es ist ein tolles Verkaufargument wenn ich sagen kann, ich unterstütze 750 Geräte. Dumm nur, wenn ich das 751. Gerät programmieren muss. Ich persönlich bevorzuge ein gutes Handbuch mit allen Befehlen und Beispielen für die Einstellung. Dann kann ich die Befehle so verwenden, wie sie für mich richtig sind.
R. B. schrieb: > Die staerken von LabVIEW liegen vor allem im DAQ. Man findet nahezu fuer > jede Anwendung die passende Hardware direckt von NI oder unzaehligen > anderen Anbietern. Mir persoenlich ist kein anderes Werkzeug bekannt, > mit dem ich in der lage bin, auf einem System und innerhalb weniger > minuten die Signalgenerierung, Signalaufnahme und Siganlverarbeitung zu > realisieren. Lasse mich gerne eines besseren belehren. ...DIAdem? gehört aber mittlerweile ebenfalls zu NI.
Schön, daß Du das jetzt noch beitragen konntest. Jetzt können die anderen sicherlich besser schlafen.
Thread beobachten
Seitenaufteilung abschalten