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
gegi schrieb: > Ist LabView eher eine Alternative für Ingenieure, die nicht > programmieren oder keine Hardware beschreiben können? Nein!
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?!
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.
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...)
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.
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.
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.
> 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).
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)
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.
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
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.
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).
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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".
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).
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ß.
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.
X4U schrieb: > Wie misst Labview denn, m.W. läuft das immer über ein Messgerät. Nein, du kannst Einsteckkarten in den PC stecken.
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.
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.
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.
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?
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.
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.
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?
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.