Forum: PC-Programmierung LabView - was haltet ihr davon?


von gegi (Gast)


Lesenswert?

Hallo ihr,

ich studiere Elektrotechnik und habe mich sehr auf den Kurs 
"Softwaretechnik" im kommenden Semester gefreut, weil in der 
Modulbeschreibung davon die Rede ist, dass uns da eine objektorientierte 
Programmiersprache beigebracht werden soll. Ich bin leider nur relativ 
fit in C++ und Java und im objektorientierten Software-Modelling mit 
UML. Gerade drum hätte ich mir das sowas von gerne von einem Dozenten 
ordentlich beibringen lassen wollen. Jetzt finde ich heraus, dass wir da 
(nur??) LabView machen... Ich habs mir ein bisschen angeschaut, mit OOP 
hat das ja wohl wenig zu tun, oder? Sieht aus wie ein besseres 
Crazy-Machines (dieses Computerspiel). Allerdings scheint das ja in den 
verschiedensten Bereichen eingesetzt werden zu können. Ich werde aber 
gerade nicht richtig schlau daraus.

Ist LabView eher eine Alternative für Ingenieure, die nicht 
programmieren oder keine Hardware beschreiben können? Oder ist es keine 
Alternative sondern eine völlig eigene Disziplin?

Oder liegt der Vorteil in der Stabilität, weil jegliche Art von Fehlern 
im Code ohne Code ja nicht möglich sind?

Wie gesagt, ich habe mich schon selber informiert, aber mich würde eure 
Meinung dazu interessieren. Was haltet ihr von LavView? Was gefällt euch 
daran und was nicht?

Wozu man es verwenden kann, kann ich leicht selber herausfinden. Aber 
wozu ist es GUT? Was sind da eure Erfahrungen?

Bin gespannt. Am Meisten hoffe ich darauf, dass ihr ein Interesse bei 
mir weckt. Das kam nach eigener Recherche nämlich noch garnicht auf. Ich 
habe Spaß an Softwareentwicklung und mittlerweile noch mehr an 
Hardwarebeschreibung, weshalb ich gerne in Richtung Embedded gehen 
würde. Ist LabView etwas für mich? -Theoretisch ist es das, klar, aber 
wie sieht es eurer Meinung nach aus?


Danke!

: Verschoben durch User
von bitwurschtler (Gast)


Lesenswert?

gegi schrieb:
> Ist LabView eher eine Alternative für Ingenieure, die nicht
> programmieren oder keine Hardware beschreiben können?

Nein!

von gegi (Gast)


Lesenswert?

bitwurschtler schrieb:
> gegi schrieb:
>> Ist LabView eher eine Alternative für Ingenieure, die nicht
>> programmieren oder keine Hardware beschreiben können?
>
> Nein!

Das soll KEINESFALLS irgendwie herablassend klingen, falls das so 
ankommen sollte. Ich weiß einfach nur nicht wirklich, woran ich mit 
diesem LabView bin! Ja?!

von Raul (Gast)


Lesenswert?

Angenommen Du bist Entwicklungsingenieur im Bereich elektrischer 
Maschinen und möchtest einen Generatorprototypen evaluieren. Da gibt es 
sicher viele Stellen an denen Du Temperaturen, magn. Fluss o.ä. erfassen 
möchtest. Du kaufst von NI entsprechende Hardware, klickst per D&D deine 
HW zusammen und Dein Auswerteprogramm kannst Du an einem Nachmittag 
basteln.

Du kannst auch an einem Nachmittag eine Entwicklungsumgebung für einen 
Mikrocontroller aufsetzen und versuchen eine blinkende LED zu 
realisieren.

Insofern ist Labview definitiv eine super Alternative! Schnelle, 
zielführende Implementierung - denn nicht jeder Ingenieur ist 
embedded-Entwickler, sondern bspw. ein Experte in MATLAB oder ANSYS 
Maxwell.

von Labviewkenner (Gast)


Lesenswert?

gegi schrieb:

> (nur??) LabView machen... Ich habs mir ein bisschen angeschaut, mit OOP
> hat das ja wohl wenig zu tun, oder? Sieht aus wie ein besseres
> Crazy-Machines (dieses Computerspiel). Allerdings scheint das ja in den
> verschiedensten Bereichen eingesetzt werden zu können. Ich werde aber
> gerade nicht richtig schlau daraus.

Labview kann stellenweise OOP, in der Regel nutzt man es meiner 
Erfahrung nach hauptsächlich prozedural.

> Ist LabView eher eine Alternative für Ingenieure, die nicht
> programmieren oder keine Hardware beschreiben können? Oder ist es keine
> Alternative sondern eine völlig eigene Disziplin?

Labview hat mehrere große Stärken:
1. Man kann sehr schnell Benutzeroberflächen zusammenbauen, mit Graphen 
und Diagrammen usw
2. Verfügbare Treiber für NI- oder Fremdhardware machen den Umgang mit 
eben dieser Hardware sehr schnell und komfortabel
3. Viele mitgelieferte Bibliotheken (mathematische Funktionen, Filter, 
Dateizugriff usw)
4. Parallelisierung - afaik läuft Code, der im Blockdiagramm parallel 
aufgebaut ist, auch auf Hardware parallel und ggf auf mehreren 
Prozessorkernen
5. Mit Labview kann man Programme für Linux und Windows erstellen, für 
Echtzeitplattformen oder auch FPGAs - alles "gleich" und aus einer Hand

> Oder liegt der Vorteil in der Stabilität, weil jegliche Art von Fehlern
> im Code ohne Code ja nicht möglich sind?

Haha, vergiss es. Fehler machst du genauso.

> Wie gesagt, ich habe mich schon selber informiert, aber mich würde eure
> Meinung dazu interessieren. Was haltet ihr von LavView? Was gefällt euch
> daran und was nicht?

Hassliebe. Man kann extrem schnell Software für labororientierte 
Geschichten wie Prüfstände oder Experimente zusammenbauen, aber der 
Umgang mit dem Code (pixelgenaues Klicken, in 2 Dimensionen Code 
verschieben, um "Platz" zu schaffen) ist... gewöhnungsbedürftig.

> Wozu man es verwenden kann, kann ich leicht selber herausfinden. Aber
> wozu ist es GUT? Was sind da eure Erfahrungen?

Wie oben angeschnitten - alles im Labor, wo Hardware angesteuert und 
ausgelesen werden muss, Daten visualisiert, verarbeitet und gespeichert 
werden müssen...
Ich habe damit Racks mit elektronischen Lasten und Netzteilen 
angesteuert, CAN-Busse bedient, Bildverarbeitung gemacht, 
Industrieroboter gesteuert, autonome Prüfstände gefahren...
Ich denke, dass Labview dabei genauso schnell wie konventionell 
geschriebene Programme arbeiten kann, wenn man es richtig einsetzt. Man 
kann sich eben leicht ins Knie schießen (knappes Beispiel: Wenn Empfang 
der Daten, Verarbeitung, Visualisierung und Speichern in einer Schleife 
laufen, wird das ganze nicht performant laufen. Wenn aber Daten 
priorisiert empfangen und in einen Puffer geschrieben, mit weniger 
Priorität verarbeitet und gespeichert werden und dann langsam, aber für 
Menschen ausreichend schnell visualisiert werden...)

von bitwurschtler (Gast)


Lesenswert?

gegi schrieb:

> Das soll KEINESFALLS irgendwie herablassend klingen, falls das so
> ankommen sollte. Ich weiß einfach nur nicht wirklich, woran ich mit
> diesem LabView bin! Ja?!

Labview ist für Physiker, CERN und so die haben spass damit.
Oder für Maschinenbauer, die eben SPS aber keine Programmierung können.
Oder fürs Testfeld die dutzende Messinstrumente für fliessbandtester 
einrichten.

von Labviewkenner (Gast)


Lesenswert?

bitwurschtler schrieb:
> gegi schrieb:
>
>> Das soll KEINESFALLS irgendwie herablassend klingen, falls das so
>> ankommen sollte. Ich weiß einfach nur nicht wirklich, woran ich mit
>> diesem LabView bin! Ja?!
>
> Labview ist für Physiker, CERN und so die haben spass damit.
> Oder für Maschinenbauer, die eben SPS aber keine Programmierung können.
> Oder fürs Testfeld die dutzende Messinstrumente für fliessbandtester
> einrichten.

Das ist genau das Problem. In Labview kann man "sofort" was 
zusammenklicken, was grob tut was man will. Oberflächlich geht das ohne 
Programmierkenntnisse, aber wenn man mehr will als die "blinkende LED", 
muss man doch programmieren können. Letzlich tut man das Gleiche, was 
man auch in C tun würde.

von Dumdi D. (dumdidum)


Lesenswert?

Labviewkenner schrieb:
> 4. Parallelisierung

Dieser Punkt ist ein Riesenvorteil. Parallel programmieren ist damit 
nicht schwieriger als noetig.

Der grosse Nachteil ist, das es fast nicht geht das viele Programmierer 
an der selben Basis zusammenarbeiten (svn ist bei grafischen Sprachen 
nicht so gut integriert).

Fuer kleine Teams ist LabView aber extrem produktiv.  Waehrend in C noch 
der Configsatedateienparser geschrieben/integriert  und die GUI Platform 
eingebunden wird, ist das Programm in LabView schon fertig. Wenn man ein 
grosses System mit 50 Programmieren und 3 Jahren Entwicklungszeit 
erstellen will, dann ist C/C++/Java viel besser.

von Programmiersprachentheaterintendant (Gast)


Lesenswert?

> Du kannst auch an einem Nachmittag eine Entwicklungsumgebung für einen
> Mikrocontroller aufsetzen und versuchen eine blinkende LED zu
> realisieren.

Sobald die Realisierung in mehreren Etappen, gar über wechselnde 
Mitarbeiter mit unterschiedlichen Skills in LabView, geschieht (also 
länger als einen Nachmittag dauert) so beginnen die Qualitätsprobleme 
mit LabView Artefakten.
Z.B. verschiedene Stände einer LabView-Arbeit zu vergleichen, resp. die 
Unterschiede dazwischen  bis ins letzte Detail angezeigt zu bekommen ist 
nicht. Das artet in eine Mischung von Ostereiersuchen und Memoryspiel 
aus.
Parzelle Änderungen mergen? Da läuft die Maus heiss, ab den vielen km 
welche sie abspulen muss.


Ob LabView, UML, oder el. Schemas: so prägnant ein gut gemachtes Bild 
besser als 1000 Worte in der "Aussage" ist, Support im Sinne von 
Bearbeitungsautomation (suchen und ersetzen? refactoring support?) durch 
SW lässt zu wünschen übrig (zumindest im Vergleich zu was /state of the 
art/ bei textuellem Quellcode ist).

von Johnny B. (johnnyb)


Lesenswert?

Dumdi D. schrieb:
> Waehrend in C noch
> der Configsatedateienparser geschrieben/integriert  und die GUI Platform
> eingebunden wird, ist das Programm in LabView schon fertig. Wenn man ein
> grosses System mit 50 Programmieren und 3 Jahren Entwicklungszeit
> erstellen will, dann ist C/C++/Java viel besser.

Der Vergleich LabView mit C hinkt aber gewaltig!
Wenn schon, dann ist LabView mit VisualStudio (C#/.NET), Qt Creator IDE 
oder ähnlichem zu vergleichen und dann sieht LabView schnell mal sehr 
alt aus. (Ausgenommen die bereits fertigen VI's von NI für deren eigener 
Hardware)

von Peter D. (peda)


Lesenswert?

LabView ist der Versuch, Software wie Hardware zu entwickeln. Man 
zeichnet quasi einen Schaltplan der Software.
Mein Eindruck ist, das wird schnell unübersichtlich, sobald die Projekte 
etwas größer werden. Und wenn man sich nicht viel Disziplin auferlegt, 
auch schnell undurchschaubar, unwartbar, kaum erweiterbar.
Man sollte dafür einen PC mit 2 Bildschirmen haben und die können nicht 
groß genug sein. Das macht es auch schwierig, mal eben was auszudrucken 
und offline zu lesen.

von bitwurschtler (Gast)


Lesenswert?

Peter D. schrieb:
> LabView ist der Versuch, Software wie Hardware zu entwickeln. Man
> zeichnet quasi einen Schaltplan der Software.

Es ist halt beides "programmieren". Der Deutsche denkt bei Programmieren 
eben an Textähnlichen programmcode, während im Amerikansichen 
Programmieren auch Knöpfe drehen und Stecker stecken bedutet.

Da eins wie ein Synthesizer wie Hardware programmiert wurde ;-)

https://youtu.be/IvUU8joBb1Q?t=15

von Christopher J. (christopher_j23)


Lesenswert?

Labview sehe ich in erster Linie als Werkzeug zur Datenerfassung, d.h. 
im Bereich Messtechnik. Es gibt gute und vergleichsweise günstige 
Hardware und die Auswahl ist relativ groß. An der Uni hatten wir neben 
LabView noch dSpace-Systeme im Einsatz, die sich in Matlab/Simulink 
integrieren aber ihre Stärke vor allem in der Regelungstechnik haben und 
auch ein ganzes Stück teurer sind. Messen kann man mit diesen 
dSpace-Systemen natürlich auch. Sowohl Labview, als auch dSpace/Simulink 
setzen auf die Einfachheit der grafischen Programmierung mittels 
Blockschaltbildern. Bei einfachen Sachen ist das dann auch wirklich sehr 
einfach aber bei komplexeren Dingen wird es dann schnell 
unübersichtlich. Allgemein habe ich bei den ganzen grafischen 
Programmiersystemen das Gefühl, dass es auf "write-only"-Code 
hinausläuft. Das gilt umso mehr, wenn verschiedene Personen am gleichen 
Projekt arbeiten und je größer ein Projekt wird. Hier mal ein paar 
AD-Kanäle samplen, filtern, aufbereiten und graphisch darstellen, dafür 
ist Labview super. Komplexere Dinge, wenn digitale Datenübertragung mit 
im Spiel ist, Protokolle implementiert werden müssen, etc. dann ist 
Labview eher Kampf und Krampf.

von A. S. (Gast)


Lesenswert?

Mach den Kurs auf jeden Fall (oder Matlab/stateflow) um diese Art der 
Programmierung zu kennen. Um es zu nutzen, wo es sinnvoll ist (einfach 
oder einmalig oder schnell) und wo nicht (komplex und langfristig und 
fortlaufend weiterentwickelt).

von qwerty (Gast)


Lesenswert?

Mit Labview kommt man bei vielen Dingen schnell zum Ziel. Allerdings bei 
komplexeren Dingen oder Änderungen/Erweiterungen eines bestehenden 
Programmes kommt man auch schnell an die Grenze von dem, was man selber 
erfassen kann.

Daher finde ich: kleine Labview-Tapeten sind ok. Komplexe 
Labview-Tapeten mit zig Verschachtelungen und Hierachieebenen sind ein 
Drama, wenn man es nicht selber gemacht hat, sondern die Arbeit von 
jemand anders verstehen muss. Da jedes Projekt wächst und immer wieder 
meist von unterschiedlichen Personen geändert und erweitert wird, 
empfehle ich auf keinen Fall Labview zu nutzen. Wir haben hier schon mit 
so einigen Labview-Tapeten richtige Dramen erlebt.

von Gerhard O. (gerhard_)


Lesenswert?

Wir verwenden LabVIEW schon seit sehr vielen Jahren für interne 
Meßaufbauten im Labor und es hat sich sehr bewährt. Wenn man sich daran 
gewöhnt hat kommt man eigentlich ganz gut damit zurecht. Modularisierung 
und Abstraktion mit eigenen VIs ist sehr wichtig um übersichtlichen Code 
zu erstellen. Auch kann man das Grundgerüst immer wieder verwenden. 
Anbindung an Kommunikationsschnittstellen wie Ethernet, Serial, IEEE-488 
ist halt sehr bequem.

von Jan W. (jan_woj)


Lesenswert?

Labview wird sehr schnell unübersichtlich. Ein Hineinzoomen in 
Teilbereiche, soweit ich es richtig bedient habe, ist nicht möglich. Man 
muss sehr schnell Teile in neue Vis auslagern, sonst verliert man sich 
schnell. Irgendwie hat es für mich den Eindruck das man versucht mit 
Labview  die Analog Elektroniker welche sich gegen das Programmieren 
streben,  zum Programmieren zu bringen. Vielleicht klappt es bei 
manchen.
Ich habe gehört das Phyton sehr oft in professionellen Bereichen  für 
komplexe Messaufgaben / Steuerungen benutzt wird.

Gruss,
Jan

von Wolfgang (Gast)


Lesenswert?

Jan W. schrieb:
> Labview wird sehr schnell unübersichtlich.

Warum sollte es dir in Labview mit "Spagetticode" anders ergehen, als in 
anderen Programmiersprachen.

> Ein Hineinzoomen in Teilbereiche, soweit ich es richtig bedient habe,
> ist nicht möglich. Man muss sehr schnell Teile in neue Vis auslagern,
> sonst verliert man sich schnell.

Genauso, wie du in anderen Programmiersprachen irgendetwas in Funktionen 
auslagerst, wird es bei LabView in VIs gepackt.

von A. S. (Gast)


Lesenswert?

Wolfgang schrieb:
>> Labview wird sehr schnell unübersichtlich.
>
> Warum sollte es dir in Labview mit "Spagetticode" anders ergehen, als in
> anderen Programmiersprachen.

Ich glaube, es geht nicht um schlechten Code. Sondern darum, dass die 
Ausdruckskraft in Labview bei größeren Projekten geringer ist als in 
eher textbasierten Sprachen. Dies merkt man dann z.B. bei:
- Navigieren über den Code (Lesen, erfassen, untersuchen)
- Refakturieren
- Änderungen im VCS verfolgen
- mergen

Dem entgegen spricht die Erfahrung, dass man als fachfremder meint, den 
Code intuitiv lesen zu können. Das führt bei Managern und Programmierern 
unabhängiger kleinerer Teilprojekte (wenige 10kLoc oder <<100 Seiten 
Grafik) zu Unverständnis, warum die unbelehrbaren Nerds es sich nicht 
einfacher machen.

von Markus K. (markus-)


Lesenswert?

Wolfgang schrieb:
> Jan W. schrieb:
>> Labview wird sehr schnell unübersichtlich.
>
> Warum sollte es dir in Labview mit "Spagetticode" anders ergehen, als in
> anderen Programmiersprachen.

Als ich vor 15 Jahren bei einer Firma angefangen habe, hatte ich zuerst 
nur den Labview Code von den Kollegen gesehen: 10-fach verschachtelte 
Kontrollstrukturen (If in einer Schleife in einer Sequenz in einem if 
...) und so Zeugs und dachte, die können alle nicht programmieren. Dann 
habe ich aber den C-Code von den selben Leuten gesehen und der hat ganz 
normal ausgesehen. Da haben sie so etwas nicht gemacht.

Deswegen habe ich den Eindruck gewonnen, dass Labview eher dazu 
verführt, schlechten/unübersichtlichen Code zu schreiben.

von PittyJ (Gast)


Lesenswert?

Bei uns in der Firma mußten wir das auch mal benutzen.
- Der Editor ist schlecht. Variables Zoomen ist nicht möglich.
- Die Diagramme werden schnell unübersichtlich.
- Wartbarkeit ist kaum gegeben, nach einem halten Jahr versteht man 
seinen Code selber nicht mehr.
- Einfach mal mit einem Texteditor auf Code schauen geht nicht. Tools 
wie diff/merge und SVN-Paralellsichten gehen gar nicht.

Mein Tipp: einmal probieren, und dann versteht man, warum seit 40 Jahren 
mit Source-Code im Ascii-Format gearbeitet wird.

von Kai I. (kderh)


Lesenswert?

LabView hat schon so einige Vorteile.
Besonders, wie schnell und einfach man GUIs entwickeln kann ist toll, 
finde sehr schade dass es so teuer ist und es keine 
Community-Free-Version mit Compiler gibt, sonst glaube ich schon dass 
man öfter damit erstellte Anwendungen auch außerhalb der Industrie 
finden würde. Zumal man durch die grafische Programmierung für die 
meisten Aufgaben nicht erst irgendwelche Sprachdokumentationen wälzen 
muss, man geht einfach die nach Kategorien sortierte Funktionspalette 
durch, bis man einen passenden Block gefunden hat.
Praktisch ist auch die quasi automatische Multithreadingfähigkeit, da 
(meines Wissens nach) parallele Stränge per default auf einen Thread 
Pool verteilt ausgeführt werden.
Hardware I/O mit NI Hardware und anderen Geräten, die passende APIs 
mitbringen, ist natürlich sehr komfortabel und wird so auch für 
Nicht-Programmierer (die wohl einen großen Teil der Zielgruppe stellen) 
fast schon trivial ohne vorher 100 Seiten API-Doku durchzulesen.

Dass grafische Programmierung natürlich im Vergleich zu Text schwerer 
sauber zu halten, zu lesen und zu warten ist, bestreitet sicher keiner. 
Tools wie Diff und Analyse sind nur bei der teuren Edition dabei und 
auch dann nicht so einfach in typische Versionsverwaltungs-Workflow zu 
integrieren.
Um Tapetenbildung entgegen zu wirken sollte man konsequent 
abgeschlossene Funktionsteile in eigene VIs auslagern (man schreibt ja 
auch in den Textsprachen Funktionen und nicht alles in main rein) und 
auf jeden Fall das "Dataflow" Prinzip verinnerlichen, so kann man viele 
unnötigen Kontrollstrukturen (v.A. diese blöden "Filmstreifen") 
einsparen.

von Johannes O. (jojo_2)


Lesenswert?

Für kleinere und einfache Sachen ist Labview gut. Da lässt sich schnell 
was zusammenklicken. Insbesondere auch von Leuten, die weniger Erfahrung 
im Programmieren haben.

Hab aber leider genau auch schon das Gegenteil erlebt. Restbussimulation 
per Labview, inkl. Anbindung an verschiedene DLLs, Netzwerk usw. Das 
Ding ist gewachsen und gewachsen und war letztendlich kaum noch zu 
warten. Durch die Komplexität (oder ggf. auch weils auf Windows lief) 
wurden dann teils auch Echtzeitbedingungen (100 ms) nicht mehr 
eingehalten.

von X4U (Gast)


Lesenswert?

Eine Frage an die Labview Spezies

Wo ist der Vorteil von Labview gg. eine SPS welche die Daten zum 
Beispiel nach Excel schreibt und/oder auf einem HMI Panel darstellt?

Preislich ist die SPS Lösung wohl immer günstiger.

von Ulf (Gast)


Lesenswert?

PittyJ schrieb:
> - Der Editor ist schlecht. Variables Zoomen ist nicht möglich.
Das soll wohl mit Labview NG (next generation) gehen.
Bei dem Rest stimme ich Dir zu, daher habe ich es mir noch nicht 
angeschaut.

X4U schrieb:
> Wo ist der Vorteil von Labview gg. eine SPS welche die Daten zum
> Beispiel nach Excel schreibt und/oder auf einem HMI Panel darstellt?
Jeder kann mit Labview und ein paar Mausklicks eine Filterfunktion oder 
eine FFT einbauen. Bei einer SPS sind die Datenverarbeitungsfunktionen 
i.d.R recht eingeschränkt. Außerdem bekommt man fast jedes Messgerät mit 
passender Labviewschnittstelle.
Es hat halt alles seine Anwendung: SPS um die Maschine zu steuern, 
Labview um da Messdaten rauszuziehen.

Aber wie schon mehrfach erwäht wurde: sobald die Sache etwas komplexer 
wird, kommt mit hoher Wahrscheinlichkeit visualisierter Spaghetticode 
raus.

von Wolfgang (Gast)


Lesenswert?

X4U schrieb:
> Wo ist der Vorteil von Labview gg. eine SPS welche die Daten zum
> Beispiel nach Excel schreibt und/oder auf einem HMI Panel darstellt?

Mit einer SPS wird du keine 1MSa/s erfassen können. Auf jedem PC kannst 
du einen Taschenrechner laufen lassen, aber daran wird wohl keiner die 
Leistungsfähigkeit eines PCs messen wollen.

von X4U (Gast)


Lesenswert?

Wolfgang schrieb:
> Mit einer SPS wird du keine 1MSa/s erfassen können.

Mit Labview, nehme ich mal an, aber auch nicht. Es gibt schnelle Geräte 
die das erfassen aber 1Msa/s online/realtime zu verarbeiten, kann 
Labview das?

von X4U (Gast)


Lesenswert?

Ulf schrieb:
> Jeder kann mit Labview und ein paar Mausklicks eine Filterfunktion oder
> eine FFT einbauen.

Verstehe, aber wenn man sowieso ein Messgerät zum erfassen braucht 
braucht warum dann keines mit FFT?

> Bei einer SPS sind die Datenverarbeitungsfunktionen
> i.d.R recht eingeschränkt.

Ist ja auch eine andere Baustelle Twincat aber hat z.B. FFT. So weit ich 
weiß, hab aber lange nichts mehr in dem Bereich gemacht.

von Wolfgang (Gast)


Lesenswert?

X4U schrieb:
> Es gibt schnelle Geräte die das erfassen aber 1Msa/s online/realtime zu
> verarbeiten, kann Labview das?

Messen und aufzeichnen - ja.
"Verarbeiten" ist ein weites Feld und da kommt es drauf an, was du 
darunter verstehst".

von X4U (Gast)


Lesenswert?

Wolfgang schrieb:
> X4U schrieb:
>> Es gibt schnelle Geräte die das erfassen aber 1Msa/s online/realtime zu
>> verarbeiten, kann Labview das?
>
> Messen und aufzeichnen - ja.
> "Verarbeiten" ist ein weites Feld und da kommt es drauf an, was du
> darunter verstehst".

Andersherum gefragt, wie viele FFTs/s schafft Labview pro Sekunde (z.B. 
bei 1024 samples).

von X4U (Gast)


Angehängte Dateien:

Lesenswert?

Wolfgang schrieb:
> Messen und aufzeichnen - ja.

Wie misst Labview denn, m.W. läuft das immer über ein Messgerät.

Das letzte was ich mal probiert hab war ne FFT (und diverse Rausch und 
Störabstände) von einem Analog-Devices A/D Wandler. Lief aber über ein 
Blackfin board per USB und Labview war "nur" das frontend.

War schon toll was da alles zu sehen war aber die app war gigantisch 
groß.

von Martin S. (strubi)


Lesenswert?

gegi schrieb:
> Wozu man es verwenden kann, kann ich leicht selber herausfinden. Aber
> wozu ist es GUT? Was sind da eure Erfahrungen?

Für ungeduldige Frickler, die "mal eben" verschiedene kompatible Geräte 
auslesen und Daten sammeln wollen: Brauchbar und effektiv.
Für Applikationsentwicklung der robusteren und skalierbaren Art kann ich 
bisher nur davon abraten. Habe mich nach ca. 20 Jahren wieder mal mit 
Labview beschäftigt und musste mit Schrecken feststellen: Der Editor und 
das Bedienungskonzept ist in den frühen 90ern steckengeblieben.
Auch macht LV keine gute Nummer, wenn es um schnelles automatisches 
Erstellen von GUIs zu Geräten mit intelligenten Protokollen geht.
Da ist das Framework umständlicher als bei Freewaretools wie zB 
MyOpenLab und man verbrät ohne Ende Zeit mit Frickelei und 
unzulänglichem Debugging-Werkzeug.
Mit Python bin ich längst viel produktiver, dazu kommen die Vorteile 
einer sauberen Sprache (die man zugegebenermassen mit Labwindows auch 
haben kann), und einer exzellenten Wiederverwertbarkeit. Lässt sich 
übrigens auch in LV integrieren.
Fazit: Es reicht, sich bedingt mit Labview-Basics herumzuschlagen, bzw. 
ad-hoc, wenn ein Kunde unbedingt "writeonly"-entwickeln will und den 
Unterhalt selber macht.

von Wolfgang (Gast)


Lesenswert?

X4U schrieb:
> Wie misst Labview denn, m.W. läuft das immer über ein Messgerät.

Nein, du kannst Einsteckkarten in den PC stecken.

von Dumdi D. (dumdidum)


Lesenswert?

X4U schrieb:
> die das erfassen aber 1Msa/s online/realtime zu verarbeiten, kann
> Labview das?

Ja, sogar noch mehr, bei uns geht 10Msa/s (und 50% der Daten 
wegwerfen). Datenverarbeitung ist da auch drin. Dazu muss aber paralell 
programmiert werden und alle Kerme ausgelastet werden

Fft ist so schnell wie in anderen Bibliotheken auch.

von A. S. (Gast)


Lesenswert?

Kai I. schrieb:
> Dass grafische Programmierung natürlich im Vergleich zu Text schwerer
> sauber zu halten, zu lesen und zu warten ist, bestreitet sicher keiner.

Leider doch. Eben jene Manager, die zwar kein Fachmann sind, aber es 
trotzdem beurteilen können.

von Pandur S. (jetztnicht)


Lesenswert?

Der Nachteil von LV ; Sequentielle Verarbeitung und timings.

Loesung : Labwindows auch von National Instruments. Beinhaltet alle VIs, 
ist aber ein C/C++ Compiler. 3 Zeilen C Code sind viel schneller und 
effizienter wie der Versuch noch ein paar Faeden durch eine Wand 
durchzuschieben.

von Wolfgang (Gast)


Lesenswert?

Zitronen F. schrieb:
> Der Nachteil von LV ; Sequentielle Verarbeitung und timings.

Wenn du keinen parallel laufenden Threads anlegst, kannst du natürlich 
nicht erwarten, dass irgendetwas parallel läuft. Und Race Conditions 
musst du natürlich immer im Auge behalten. Wenn Ergebnisse aus parallel 
laufenden VIs in einem nächsten VI gemeinsam verarbeitet werden sollen, 
muss das VI mit der Ausführung natürlich warten, bis alles da ist. Oder 
was meinst du mit sequentieller Verarbeitung?

von A. S. (Gast)


Lesenswert?

Wolfgang schrieb:
> Oder was meinst du mit sequentieller Verarbeitung?

Dass sequentielle Verarbeitung mit entsprechenden Warte- und 
Überwachungszeiten und mehreren übergeordneten (Abbruch-)Events (der 
klassische SPS-Loop-Ansatz) mit Labview schwieriger sind.

Graphisch ist meist besser für Data-Flow. (Signalwege)
Textuell meist besser für Control-Flow.

von Christoph (Gast)


Lesenswert?

Autor: Achim S. (achs)
>Dass sequentielle Verarbeitung mit entsprechenden Warte- und
>Überwachungszeiten und mehreren übergeordneten (Abbruch-)Events (der
>klassische SPS-Loop-Ansatz) mit Labview schwieriger sind.

Wobei die Philosophie von LabView von vorne herein eine 
"Parallelverarbeitung" ist.
Das Problem auf Mikrocontrollern oder dem PC, dass Parallelverarbeitung 
immer ein Problem darstellt und nur mühselig in den Griff zu bekommen 
ist, ist bei LabView schlicht nicht vorhanden. Für eine bestimmte Klasse 
von Problemen ist das ein riesiger Vorteil.

von A. S. (Gast)


Lesenswert?

Christoph schrieb:
> Das Problem auf Mikrocontrollern oder dem PC, dass Parallelverarbeitung
> immer ein Problem darstellt und nur mühselig in den Griff zu bekommen
> ist, ist bei LabView schlicht nicht vorhanden

Bei Mikrocontrollern auch nicht. Parallele Prozesse sind nie ein Problem 
(egal ob per Interrupt, RTOS oder SPS-Loop), sie sind ja parallel. 
Problematisch wird es erst, wenn sie synchronisiert werden müssen oder 
Echtzeit auf endlichen Ressourcen erwartet wird. Hat Labview da 
qualitative Vorteile?

von Martin S. (sirnails)


Lesenswert?

Ich programmiere seit Jahren in Labview. Wir automatisieren damit unsere 
Nadeladapter.

Kurzum: In den letzten 3 Jahren bin ich auf keine einzige 
Labviewspezifisiche Limitierung gestoßen. Gerade der .NET-Support der 
neueren Versionen funktioniert inzwischen absolut gut und erweitert das 
Spektrum von Labview enorm.

Man kann Labview und C/C++/Java & Co. nur bedingt vergleichen. Das sind 
grundlegend verschiedene Zielgruppen und grundlegend verschiedene 
Ansätze.

Größtes Manko bei Labview ist die schlechte Erweiterbarkeit. Man 
zeichnet sich ja quasi ein "Bild". Stellt man fest, man muss erweitern, 
dann wird das sehr schnell zum Verschiebemassaker - auch wenn das ab 
Version 2015 deutlich! besser geworden ist, da es diverse, und nach 10 
Jahren auch gut funktionierende Hilfsmittel gibt.

Hardwareansteuerung läuft problemlos. Die Visa-Schnittstelle ist 
wirklich sehr brauchbar - und vor allem auch sehr schnell.

Labview ist m.M.n. eine Automatisierungssoftware. Algorithmen lassen 
sich eigentlich gut umsetzen und die Wartbarkeit von Code ist dann gut, 
wenn mit Disziplin programmiert wurde, und die Design Rules eingehalten 
wurden.

Kurzum: Ich würde heute viele Dinge nicht mehr ohne Labview machen, weil 
es enorm leistungsfähige Tools an die Hand gibt. Viele VIs sind derart 
leistungsfähig - binnen 20 Minuten ist ein PID-Regler inklusive GUI 
gebaut.

Aber trotzdem gibt es genauso Bereiche, die unter Labview nicht gut 
umsetzbar sind. Die GUI steckt in den 2000ern und viele von der .NET IDE 
gewohnte Funktionen fehlen schlicht komplett oder sind mega kompliziert.

OOP ist zwar prinzipiell möglich, wird aber faktisch nie genutzt. 
Klassen und Vererbung vielleicht noch, aber das war's dann eigentlich.

von Christoph (Gast)


Lesenswert?

Autor: Achim S. (achs)
Datum: 28.03.2018 07:55

>Christoph schrieb:
>> Das Problem auf Mikrocontrollern oder dem PC, dass Parallelverarbeitung
>> immer ein Problem darstellt und nur mühselig in den Griff zu bekommen
>> ist, ist bei LabView schlicht nicht vorhanden

>Bei Mikrocontrollern auch nicht. Parallele Prozesse sind nie ein Problem
>(egal ob per Interrupt, RTOS oder SPS-Loop), sie sind ja parallel.
>Problematisch wird es erst, wenn sie synchronisiert werden müssen oder
>Echtzeit auf endlichen Ressourcen erwartet wird.
So lange es sich um einen Einkernprozessor handelt und man die 
Peripherie außer acht lässt, ist da nichts parallel.
LabView zwangsweise dann auch nicht, aber ...
>Hat Labview da qualitative Vorteile?
Ja, weil die Struktur von LabView der von Petrinetzen entspricht und 
damit die Synchronisation automatisch gegeben ist.

Bitte 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
Noch kein Account? Hier anmelden.