LabVIEWForum.de

Hallo zusammen,

ich nehme in absehbarer Zeit an mind. 2 NI-Schulungen teil. Da ich seit Ende April tagtäglich mit LabVIEW arbeite, haben wir beschlossen, dass ich mit Core 2 beginne.

Nun möchte ich natürlich nicht, dass ich dort sitze und nicht mitkomme, doch bei Null anzufangen wäre bei meinem Kenntnisstand "verschwendete" Zeit (die ich natürlich nicht habe). Ich kann sicher viel, das in Core 1 gezeigt wird und manches davon nicht. Core 2 möchte ich auf jedenfall besuchen.

Die Kursinhalte von Core 1 habe ich grob überflogen und zeige kurz auf, wie mein aktueller Stand ist. Es wäre nett, wenn ihr mir dann grob aufzeigen könnt, was in den Punkten durch genommen wird, die mir unbekannt sind. Also einfach ein paar Stichworte, damit ich mir das Wissen noch aneignen kann über Webcasts, Tutorials oder Bücher.

Zitat:* Bedienung von LabVIEW
o Bestandteile eines Virtuellen Instruments (VI)
o Projektexplorer
o Datenflussmodell

Ist mir bekannt.

Zitat:* Suchen und Beheben von Fehlern in VIs

Dieses "Debug-Tool" (die Glühbirne) o.ä. kenne ich.

Zitat:* Erstellen von VIs
o Designempfehlungen
o LabVIEW Datentypen
o Schleifen und Schieberegister
o Case-Struktur
o Zeitliche Steuerung
o Darstellung von Daten in Diagrammen
o Zusammenfassen von Daten mit Arrays und Clustern
o Erfassen, Analysieren und Darstellen von Messwerten

Das habe ich alles schon mehrfach angewendet bzw. in fast allen Projekten.

Zitat:* Überblick zu Hardware-Technologien:
o Datenerfassungshardware (DAQ)
o IEEE 488.2 (GPIB)
o Kommunikation über serielle Schnittstelle (RS232)

DAQmx nutze ich hoch und runter, GPIB und RS232 habe ich bisher nicht verwendet. Wird dieses Wissen in Core 2 benötigt? Ich kann's mir nicht vorstellen, lasse mich aber eines besseren belehren.

Zitat:* Verwalten von Ressourcen
o Lesen und Schreiben von Dateien
o Erfassen von analogen Messwerten mittels DAQ
o Gerätesteuerung mit NI-VISA
o Einbinden von Instrumententreibern

Die letzten beiden Punkte sind mir hier neu.

Zitat:* Modulares Programmieren

Was versteht NI darunter? Das Erstellen möglichst mehrfach bzw. allgemein einsetzbarer SubVIs mit allem, was dazugehört (Error Cluster, Icons, Kontexthilfentext, ...)?
Wenn ja, mache ich das täglich. Wenn es jedoch um DLLs o.ä. geht, wäre das neu für mich.

Zitat:* Verwenden von Entwurfsmethoden
o Sequentielles Programmieren
o Zustandsautomat

Das verwende ich auch oft.

Zitat:* Einsatz von Variablen
o Kommunikation zwischen parallelen Schleifen
o Erzeugen von Variablen in LabVIEW
o Laufzeitprobleme

Lokale und gobale Variablen habe ich bisher nie verwendet, aber ich weiß, wie man diese erstellt. Was ich öfters verwende sind Eigenschaftsknoten (Wert etc). Das sind zwar auch sowas wie lokale Variablen, nur kann ich hier die Ablaufreihenfolge über den Error Cluster vorgeben. Daher nehme ich diese lieber, auch wenn sie etwas langsamer sind.

Naja, das war's eigentlich. FInge wie Ereignisstrukturen, Erzeuger-/Verbrauchersystem habe ich auch schon verwendet. Die obigen Punkte geben nur einen Teil meiner Kenntnisse wieder.
Natürlich könnt ihr auf die Ferne nicht sagen, was ich kann und was nicht. Aber könnt ihr anhand der Punkte grob sagen, was ich mir auf jedenfall noch anschauen muss, um bei Core 2 alles verstehen zu können?

Grüße

' schrieb:Was versteht NI darunter? Das Erstellen möglichst mehrfach bzw. allgemein einsetzbarer SubVIs mit allem, was dazugehört (Error Cluster, Icons, Kontexthilfentext, ...)?
Wenn ja, mache ich das täglich. Wenn es jedoch um DLLs o.ä. geht, wäre das neu für mich.

Modular zu programmieren ist Programmiersprachen-unabhängig. SUBVIs, Gruppen von SubVIs, Aufrufbarkeit über VI-Server etc. und nicht zuletzt Klassen gehört alles dazu. DLLs alleine macht keine Modularität aus.

Zitat:Lokale und gobale Variablen habe ich bisher nie verwendet, aber ich weiß, wie man diese erstellt. Was ich öfters verwende sind Eigenschaftsknoten (Wert etc). Das sind zwar auch sowas wie lokale Variablen, nur kann ich hier die Ablaufreihenfolge über den Error Cluster vorgeben. Daher nehme ich diese lieber, auch wenn sie etwas langsamer sind.

Würde ich nicht machen. Propertys sind extrem langsam.
Wenn du Propertys brauchst wegen der Seqenzierung (Vermeidung von RaceConditions), dann hast du einen Fehler im allgemeinen Programmaufbau.

Zitat:Aber könnt ihr anhand der Punkte grob sagen, was ich mir auf jedenfall noch anschauen muss, um bei Core 2 alles verstehen zu können?

Keine Ahnung. Hab nie einen Core mitgemacht.
Sieh es einfach so: Stellt sich heraus, dass in Core 2 auch nicht mehr erklärt wurde, als du bereits weist, war die ganze Unruhe zuvor umsonst. Stellt sich heraus, dass neue, unbekannte Sachen erklärt (oder gar vorausgesetzt) wurden, was machts? Da werden Basics erklärt, die hast du in einer Woche intus.

Programmieren kann man nicht lernen, das muss man im Blut haben. Ist wie mit Journalismus. Die Programmiersprache ist nur das Hilfsmittel zum Programmieren.

Hallo IchSelbst (nein, ich führe keine Selbstgespräche )

' schrieb:Keine Ahnung. Hab nie einen Core mitgemacht.
Sieh es einfach so: Stellt sich heraus, dass in Core 2 auch nicht mehr erklärt wurde, als du bereits weist, war die ganze Unruhe zuvor umsonst. Stellt sich heraus, dass neue, unbekannte Sachen erklärt (oder gar vorausgesetzt) wurden, was machts? Da werden Basics erklärt, die hast du in einer Woche intus.

Stimmt eigentlich. Wenn man sieht, dass etwas vorausgesetzt wird, das man nicht kann, weiß man genau, was noch zu lernen ist. So habe ich das noch gar nicht betrachtet.

' schrieb:Würde ich nicht machen. Propertys sind extrem langsam.
Wenn du Propertys brauchst wegen der Seqenzierung (Vermeidung von RaceConditions), dann hast du einen Fehler im allgemeinen Programmaufbau.

Ich habe einige Situationen, da weiß ich nicht, wie ich es anders lösen soll.

Beispiele:
Parallele und verschachtelte Schleifen, die per Klick auf "Stopp" beendet werden sollen. Gut, das ist vielleicht der einzige Fall, bei dem lokale Variablen noch ok wären. Aber wie man das sonst einfach machen könnte, habe ich bisher nicht heraus bekommen. Da nutze ich immer den Eigenschaftsknoten "Wert".
Und über eine Ereignisstruktur und Queues o.ä. finde ich das viel zu umständlich (Ereignisstruktur mit "Wertänderung Stopp" als Erzeuger und die Schleifen als Verbraucher).

Anderes Beispiel: Ich habe einen XY-Graphen mit mehreren Plots und möchte Plot 0 durch einen anderen ersetzen. Hier wird's richtig langsam, aber ich wüsste nicht, wie's anders geht: Eigenschaftsknoten "Wert" (lesen), Array Indizieren, Element 0 ersetzen und "Wert" (schreiben) wieder zuweisen.

Dann nutze ich sie noch, wenn ich mit der GUI arbeite, doch da kann man ja nicht anders lösen (Elemente, deaktivieren, Achsskalierungen von Graphen anpassen etc).

' schrieb:Parallele und verschachtelte Schleifen, die per Klick auf "Stopp" beendet werden sollen. Gut, das ist vielleicht der einzige Fall, bei dem lokale Variablen noch ok wären.

Klassischer Fall, für den ich auf jeden Fall Lokale Variablen erlaube.

Zitat:Aber wie man das sonst einfach machen könnte, habe ich bisher nicht heraus bekommen. Da nutze ich immer den Eigenschaftsknoten "Wert".

Das Property WERT verwende ich eigentlich nur dann, wenn gleichzeitig sowieso ein Eigenschaftsknoten z.B. für Visible notwendig wäre.

Zitat:Und über eine Ereignisstruktur und Queues o.ä. finde ich das viel zu umständlich (Ereignisstruktur mit "Wertänderung Stopp" als Erzeuger und die Schleifen als Verbraucher).

Geht es noch um die Stop-Funktion? Da gebe ich dir Recht. SubVI-intern halte ich das für übertrieben. (Ja, auch Queues und Melder kann man sinnloserweise einsetzen.)

Zitat:Anderes Beispiel: Ich habe einen XY-Graphen mit mehreren Plots und möchte Plot 0 durch einen anderen ersetzen. Hier wird's richtig langsam, aber ich wüsste nicht, wie's anders geht: Eigenschaftsknoten "Wert" (lesen), Array Indizieren, Element 0 ersetzen und "Wert" (schreiben) wieder zuweisen.

Graphen, also Anzeigeelemente, sind bei mir immer nur Datensenken. Die Daten, mit denen auch überall anders im Programm gerechnet wird, liegen in einer FGV. Wenn also ein Kanal geändert werden soll, dann werden die Daten aus der FGV einfach in einer anderen Reihenfolge zusammengesetzt.

Zitat:Dann nutze ich sie noch, wenn ich mit der GUI arbeite, doch da kann man ja nicht anders lösen (Elemente, deaktivieren, Achsskalierungen von Graphen anpassen etc).

Das steht außer Frage, natürlich.

Jetzt, da ich dein Waveform-Thema lese, fällt es mir wieder ein: Interessant sind eher spezifische Veranstaltungen(!), wie Datenübertragung (RS232 .. TCP/IP), Datenspeicherung (txt ... tdms), Bildverarbeitung, FPGA etc. etc.

"Schulungen" wie Basics und gewisse Fortgeschritte wage ich aus der Ferne für dich nur als Bestätigung deines Kenntnisstandes zu sehen. Das ist der Grund, warum du diese Veranstaltung besuchen solltest.

Core 2 werde ich besuchen, um nochmals richtig gezeigt zu bekommen, wie man programmiert. Ich habe hier übers Forum und aus Büchern sehr viel diesbezüglich gelernt, dennoch ist etwas "offizielles" sicherlich sinnvoll, zumal dort auch neue Themen angesprochen werden.

Die zweite Schulung wird vermutlich "Real Time" sein und je nach Anforderung folgt eine FPGA-Schulung.
Beide setzen meines Wissens Core 1 und Core 2 voraus.

Im Endeffekt also das, was du auch empfiehlst.
Datenübertragung selbst bringt mir persönlich nicht sonderlich viel, da es um die Kommunikation mit einer S7 geht und dafür gibt es keine Schulung. Siemens legt da die Protokolle nicht offen. Ich muss dann wohl auf Low-Level-Ebene das Protokoll zusammen friemeln bzw. die Beispiele der NI-Website nutzen, die andere Entwickler dort veröffentlicht haben.
Aber irgendwie werde ich das schon schaffen, hoffe ich.