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...
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
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.
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.
Thread beobachten
Seitenaufteilung abschalten