Umstieg auf, bzw. Neueinstieg in LabVIEW, ein paar Fragen

Hallo liebe LabVIEW Profis,

da ich jetzt nicht mehr vor LabVIEW wegrennen kann und mich in das Thema einarbeiten muss (und will) wollte ich bevor es los geht ein paar Fragen los werden. Leider gibt es in meinem Freundes- und Bekanntenkreis niemanden der sich mit LabVIEW auskennt.

In der Vergangenheit habe ich schon mehrere Software- und Elektronikprojekte, hauptsächlich Mikrocontroller gesteuerte Betriebsmittel nebenberuflich umgesetzt. Die gängigen Programmiersprachen fallen mir nicht schwer (bis jetzt hauptsächlich Borland Delphi, C (AVR-Mikrocontroller), php, Unix-shell). Jetzt hat ein Kunde einen Anlagenumbau angefragt mit der Bedingung daß die Software in LabVIEW erstellt werden soll.

Da meine Schwerpunkte bis jetzt bei der Codebasierten objektorientierten Programmierung lagen (auch sehr hardwarenah) macht mir das Thema LabVIEW nicht wenig Kopfzerbrechen. Besonders das "Timing" macht mir Sorgen. Bis jetzt konnte ich beim debuggen von Code (oder µCs per on-chip-debugger) zu jedem Zeitpunkt sehen in welchem Zustand sich das System befand und was "als nächstes" passiert. Wie ist das bei LabVIEW ? Lässt sich dort mit akzeptablem Aufwand ein "Timing" im Programm realisieren ? Irgendwie kommt mir diese graphische Programmierung etwas "schwammig" vor.

Die Messdatenerfassung soll mit einer selbst entwickelten USB-Hardware erfolgen die einen virtuellen COM-Port emuliert. Wie würdest ihr den Aufwand einschätzen Messdaten (verschiedene Kanäle) die entweder auf Anfrage oder zyklisch von der Messbox kommen so aufzubereiten daß sie nach Kanälen getrennt an VI's weiter gegeben werden können? Die Daten kommen "wie üblich" mit Trennzeichen versehen von der Hardware. Bisher habe ich Daten immer Interruptgesteuert aus dem COMport Buffer abgeholt und verarbeitet.

Bestimmte Sollwerte sollen ebenfalls an den virtuellen COM-Port geschickt werden. Lassen sich in LabVIEW mit vertretbarem Aufwand Befehls-strings zusammenbauen und an den virtuellen COM-Port senden? Wie verhält es sich mit Bit-Operationen in LV, z.B. dem Zerlegen einer Zahl in ihre Bits oder anders herum ?

Wie behaltet ihr den Überblick über die vielen unterschiedlichen VI's ?

Das waren die Punkte die mir am meisten Magenweh bereiten, vielleicht kann mir Jemand von euch eine gute Einschätzung dazu geben der selber vorher auf die herkömmliche Art programmiert hat.

Vielen Dank schon mal im Vorraus und sorry für den etwas unpräzisen Thread,
RabenFlug

Anzeige

Hallo RabenFlug,

"Kunde hat angefragt" - prima, ein Kunde:)Und der verlangt LabVIEW

"Timing"/"schwammig" - LV ist genauso konkret wie andere Programmiersprache, es wird nur die parallele Programmierung vereinfacht. Anders ausgedrückt: man muss mehr auf's Timing achten, wenn Dinge nacheinander ablaufen sollen. Dies lässt sich durch die Datenflußprogrammierung aber leicht sicherstellen.

"COM-Port simuliert" - Wenn der COM-Port auch per Hyperterminal benutzbar ist, kann man ihn auch von LabVIEW aus benutzen, sowohl lesen als auch schreiben.

"mit vertretbarem Aufwand" - Für alle genannten Aufgaben gibt es vorgefertigte Funktionen: man kann Strings C-like formatieren oder Zahlen per boolscher Operation verknüpfen...

"Überblick" - ab LV8 gibt es Projekte. Dort kann man (virtuelle) Ordner verwenden. Außerdem kann man sich ein Namensschema für subVIs überlegen - bei anderen Programmiersprachen benennt man Funktionen ja auch nicht einfach so wild drauflos... Und wenn man Künstler ist, kann man auch noch hübsche Icons entwerfen

LV ist nicht sooo schlimm. Es erfordert etwas Eingewöhnung und vor allem die Verinnerlichung des Datenfluß-Prinzips!

LabVIEW ist wesentlich einfacher und übersichtlicher als Textprogrammierung (mit der ich schon seit dem Studium auf Kriegsfuß stand ).
Also musst Du Dir deswegen keinen Kopf machen. Am besten machst Du ein paar Schulungen bei NI, damit Du die richtige Programmierung von Grund auf lernst, weil viele Leute, die von textorientierten Programmiersprachen kommen, bauen z.B. gerne viel zu viele lokale Variablen in ein Programm und machen auch sonst sehr seltsame Dinge. Wenn Du das von Grund auf richtig lernen möchtest, wäre es schon sinnvoll die Lehrgänge zu besuchen.

Gruß Markus

Ich denke ein paar Grundregeln und Tipps könnten dir den Umstieg erleichtern:
http://LabVIEWportal.eu/de/tipps-und-tricks

Hallo Gerd,

danke für die schnelle Antwort.

' schrieb:"Kunde hat angefragt" - prima, ein Kunde:)Und der verlangt LabVIEW

Ja, LabVIEW ist Voraussetzung. In dem Unternehmen sollen alle neuen Systeme mit LabVIEW programmiert werden um sie besser "wartbar" zu halten.

' schrieb:"COM-Port simuliert" - Wenn der COM-Port auch per Hyperterminal benutzbar ist, kann man ihn auch von LabVIEW aus benutzen, sowohl lesen als auch schreiben.

Der Port lässt sich wie jeder "normale" COM-Port ansprechen. Ich werde als erste Übung versuchen das COM-Handling zu einem VI zusammen zu fassen.

' schrieb:"Überblick" - ab LV8 gibt es Projekte. Dort kann man (virtuelle) Ordner verwenden. Außerdem kann man sich ein Namensschema für subVIs überlegen - bei anderen Programmiersprachen benennt man Funktionen ja auch nicht einfach so wild drauflos... Und wenn man Künstler ist, kann man auch noch hübsche Icons entwerfen

LV ist nicht sooo schlimm. Es erfordert etwas Eingewöhnung und vor allem die Verinnerlichung des Datenfluß-Prinzips!

Gut, werde die nächsten Tage how-to's und "first steps instructions" wälzen und versuchen mich mit dem Datenfluss-prinzip anzufreunden

Y-P:
Sie NI-Schulungen haben einen sehr guten Ruf. Habe mich schon mit mehreren Leuten die auf solchen Schulungen waren unterhalten und überwiegend Gutes gehört. Leider sind solche Schulungen für mich im Moment finanziell nicht möglich da ich sie komplett aus eigener Tasche bezahlen müsste.

' schrieb:Borland Delphi, C (AVR-Mikrocontroller),

Endlich mal einer, der was vom Programmieren versteht.

Zitat:Besonders das "Timing" macht mir Sorgen.

Das Timing funktioniert in LabVIEW komplett anders als in OOP, z.B. Delphi. Was natürlich nicht heißt, es es schlehter ist, nur eben anders.

Zitat:Bis jetzt konnte ich beim debuggen von Code (oder µCs per on-chip-debugger) zu jedem Zeitpunkt sehen in welchem Zustand sich das System befand und was "als nächstes" passiert.

Prinzipiell funktioniert dieser Wunsch auch in LabVIEW.

Zitat:Lässt sich dort mit akzeptablem Aufwand ein "Timing" im Programm realisieren ?

Ja, natürlich.
Was verstehst du denn unter "Timing"? Sequenzielles Abarbeiten?

Zitat:Die Messdatenerfassung soll mit einer selbst entwickelten USB-Hardware erfolgen die einen virtuellen COM-Port emuliert.

An welche Geschwindigkeit (Baudrate) hast du denn gedacht?

Zitat:Wie würdest ihr den Aufwand einschätzen Messdaten (verschiedene Kanäle) die entweder auf Anfrage oder zyklisch von der Messbox kommen so aufzubereiten daß sie nach Kanälen getrennt an VI's weiter gegeben werden können? Die Daten kommen "wie üblich" mit Trennzeichen versehen von der Hardware.

Kann man an einem Tag schaffen - wenn man LV kann. Hinterher gibt ea dann ein VI, das wie eine Klasse funktioniert.

Zitat:Wie behaltet ihr den Überblick über die vielen unterschiedlichen VI's ?

Genau so wie überall: Projektmanager und Benamungssystem.

Anzeige

Hallo Rabenflug,

programmier sonst auch eher textbasierend in C vorzugsweise auf AVR Controllern.

Nach etwa zwei Wochen LabVIEW, muss ich sagen man kann mit LabVIEW schon eine Menge machen, ist aber auch gewöhnungsbedürftig

Man kommt aber schon relativ flott voran

Gruß Flo

Vielen Dank für eure Antworten

' schrieb:Was verstehst du denn unter "Timing"? Sequenzielles Abarbeiten?

Genau, habe bis jetzt sehr "sequentiell" programmiert, z.B. mit State Machines. Bei Delphi natürlich ehr Event-orientiert.

' schrieb:An welche Geschwindigkeit (Baudrate) hast du denn gedacht?

Der Port läuft im Moment mit 38400 bps, allerdings OHNE Flow control. Effektiv soll alle 50 msec ein Datensatz mit Messwerten übertragen werden, also 20 Werte pro Sekunde. Ein Datensatz hat (je nach Kanalkonfiguration) ca. 43 Byte. Es werden also effektiv 860 Byte/sec übertragen. Ab und zu werden auch Steuerbefehle zur Messhardware geschickt um z.B. eine Stromquelle anzusteuern, einen Pulscounter zu reseten oder die Konfiguration eines ADC's zu ändern. Dadurch fallen auch noch ein paar Byte/sec an "Gegenverkehr" an.
Die Messkarte kann auch schneller Daten senden (in HyperTerm kann ich auch Datensätze im 10 msec Raster empfangen), bis jetzt war das Problem aber daß durch die zeitintensive Auswertung der Daten und das fehlende Flow Control oft bei höheren Übertragungsraten der Buffer des COM-Ports voll lief. Bin sehr gespannt wie "effektiv" LV den Comport anspricht.

stromfloh: Gut, das beruhigt mich

Hallo RabenFlug,

die Aufgabenbeschreibung schreit doch geradezu nach mind. 2 parallel laufenden Schleifen, zwischen denen Daten per Queue hin- und hergeschoben werden. Du schreibst ja nicht, was mit den Daten passiert ("zeitintensive Auswertung"), aber 1000Byte/s sind eigentlich kein Problem...

' schrieb:Genau, habe bis jetzt sehr "sequentiell" programmiert, z.B. mit State Machines.

Was glaubst du wohl, was LabVIEW macht: Sequenziell arbeiten - weil wegen des Datenflußprinzips (<= ganz wichtig) alles durch Drähte (nicht zuletzt durch den Errorcluster) verkabelt ist. Nächste wichtige Sache: Statemachine, abgeleitet aus einer "Fallunterscheidungs-Struktur" (IF-Case). Naja und eventgesteuert geht natürlich auch.

Zitat:Der Port läuft im Moment mit 38400 bps, allerdings OHNE Flow control. Effektiv soll alle 50 msec ein Datensatz mit Messwerten übertragen werden, also 20 Werte pro Sekunde.

Kleinigkeit.