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

' schrieb: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.

Kleinigkeit.

Ich bin gespannt, ich hatte schon öfters Probleme damit daß der Rechner die zyklisch ankommenden Daten nicht schnell genug verarbeiten konnte, besonders wenn Messwerte grafisch dargestellt werden sollten. LabVIEW ist bestimmt genau darauf hin optimiert.

Bald geht es los, ich muss jetzt noch die µC Software der Messkarte fertig machen und ein paar Platinen ätzen, dann ist der LabVIEW Part dran. Ein Kollege hat letztes Jahr ein LabVIEW Seminar bei National Instruments besucht und bringt mir die ganzen Schulungsunterlagen mit.

Anzeige

' schrieb:ich hatte schon öfters Probleme damit daß der Rechner die zyklisch ankommenden Daten nicht schnell genug verarbeiten konnte,

Die Lösung ist eigentlich ganz einfach: ein Zwischenpuffer verwenden.
Es gibt einen "Treiber", der die Daten so schnell empfängt, wie sie vom Endgerät geliefert werden können. Diese Daten werden in eine Queue geschrieben. Diese Queue dient somit als Zwischenspeicher und "Buffer-Vergrößerung". Da dieser Treiber nichts weiter macht als Daten zu puffern, ist der garantiert schnell genug.
Ein anderer Programmteil liest dann die Queue aus und verarbeitet die Daten weiter. Dieses Weiterverarbeiten ist nun von dem Datensampling entkoppelt, sodass das Weiterverarbeiten eigentlich langsam sein dürfte.

Hallo Leute,

jetzt wird's ernst:)Der Auftrag ist eingegangen und die Hardware "klebt" bereits am Prüfstand. Mittels HyperTerm lassen sich mittlerweile Analoge Sollwerte für einen Frequenzumrichter so wie Digitale I/O Werte senden, bzw. abfragen. So weit so gut. Nun habe ich auch angefangen mich intensiver mit LabVIEW zu beschäftigen. Im Moment kommt mir alles wie eine sehr aufwendige und unübersichtliche Version der "normalen" Programmierung vor;)Vielleicht kommt ja noch Licht ins Dunkel der gefühlten 1.000.000 VI's ?!

Ich habe mich inzwischen dazu entschlossen die Serielle I/O Box mit der LabVIEW kommunizieren soll nicht zyklisch Messdaten senden zu lassen sondern diese Daten in einer zeitgesteuerten Schleife von LV aus auzufragen. Dann bestimmt LV das Timing. Eine Echtzeituhr befindet sich sowieso in der Hardware, die Messdaten kommen also immer schön mit "echtem" Zeitstempel.

Nun hätte ich mal eine ganz allgemeine (Verständnis-) Frage. Wenn ich bisher (z.B. mit Delphi) GUIs programmier habe war meistens ein gewisser Teil der Arbeitsfläche mit Bedienelementen immer da, andere Teile der Oberfläche habe ich meist auf Panels gruppiert und diese dann "dynamisch" ein- bzw. aus geblendet, je nach dem welche Bedienelemente gerade benötigt wurden.

Wie lässt sich eine ähnliche "Gruppierung von Controls" realisieren die bei Bedarf angezeigt, bzw. ausgeblendet wird und noch viel wichtiger, ist das bei NI Programmen eine gute Vorgehensweise oder ehr exotisch? Ich möchte ungerne immer das ganze Fenster wechseln.

Habe bis jetzt SubPanel ausprobiert, das funktioniert auch ganz gut um unterschiedliche VI's im Fensterchen eine Haupt-VI's anzuzeigen. Trotzdem erschien mir das irgend wie etwas exotisch (und die Scrollbars ließen sich nicht entfernen).

Schöne Grüsse
RabenFlug

Entweder machst Du ein "Tab Control". Da kannst Du die Controls auf unterschiedlichen Seiten zusammenfassen und darstellen, wobei immer nur die Controls der "aktiven" Seite angezeigt werden.

Oder Du packst Deine Controls in einen Cluster und blendest ihn mit der Property "Visible" (davor Property Node erstellen) ein und aus.

EDIT: Hab' Dir noch schnell ein Bsp. dazu gemacht:

  Gruppierung.vi (Größe: 10,56 KB / Downloads: 206)



Gruß Markus

' schrieb:Wie lässt sich eine ähnliche "Gruppierung von Controls" realisieren die bei Bedarf angezeigt, bzw. ausgeblendet wird und noch viel wichtiger, ist das bei NI Programmen eine gute Vorgehensweise oder ehr exotisch? Ich möchte ungerne immer das ganze Fenster wechseln.

Habe bis jetzt SubPanel ausprobiert, das funktioniert auch ganz gut um unterschiedliche VI's im Fensterchen eine Haupt-VI's anzuzeigen. Trotzdem erschien mir das irgend wie etwas exotisch (und die Scrollbars ließen sich nicht entfernen).

' schrieb:Die Lösung ist eigentlich ganz einfach: ein Zwischenpuffer verwenden.

Das hatte ich in einem Programm auch mal so gemacht - bis ich dann gemerkt habe, daß es überflüssig ist. Für den Empfang hat gibt es bereits einen COM-eigenen Empfangspuffer, der ohne jeder Konfigurierung schon mal 1 kByte (oder so) groß ist. Weiß jetzt nicht, ob der dieser Puffer eine Errungenschaft von Windows oder von LabVIEW ist - auf jeden Fall läßt er sich mit LabVIEW konfigurieren.
Wenn also die Daten mal nicht sofort abgeholt werden, dann sind sie bereits in diesem Puffer gut aufgehoben.

Zur Frage: Was leistet eine COM-Schnittstelle unter LabVIEW? Genau das, was sie unter Windows auch leistet. Also im Windows-Gerätemanager mal nachschauen, welche Baudraten sich dort einstellen lasssen - dasselbe sollte dann auch mit LabVIEW möglich sein. Bei USB-Adaptern kann es sogar sein, daß deutlich höhere Baudraten als üblich möglich sind, z.B hier mit einem FTDI-Chip:
   

' schrieb:Habe bis jetzt SubPanel ausprobiert, das funktioniert auch ganz gut um unterschiedliche VI's im Fensterchen eine Haupt-VI's anzuzeigen. Trotzdem erschien mir das irgend wie etwas exotisch (und die Scrollbars ließen sich nicht entfernen).

SubPanels haben den Vorteil, dass das MainVI klein bleibt - weil ja eben diverse BD-Teile (Software) in SubVIs ausgelagert sind. Ein TabControl ist zwar vom Handling einfacher - dafür wird halt das BD (theoretisch) größer und unübersichtlicher.

Die Scrollbalken kann man ausschalten. Guckst du entsprechenden Methodenknoten (VI-Referenz).

@Lucki: Der Puffer ist eine Errungenschaft von Windows, liegt also auf Betriebssystemebene.

Anzeige

Vielen Dank für die guten Tips und das Beispiel, das hat mir sehr geholfen. Ein Beispiel sagt oft mehr als 1000 Worte.

Lucki: Meiner Messbox habe ich auch einen FTDI FT232RL Chip verpasst der die Umsetzung von USB nach Seriell (µC) übernimmt. Das funktioniert zum Glück auch sehr gut und zuverlässig.

Mitlerwele empfängt mein Programm schon Messdaten und dröselt den String in einzelne Werte auf die sich auch schön darstellen lassen. Habe das zwar etwas aufwändiger (mit search/split string) gemacht da ich kein VI gefunden habe das einen String "automatisch" durch ein Trennzeichen in einzelne Arrayelemente aufteilt. Aber es geht!

Eine zeitgesteuerte Schleife fragt dazu zyklisch Messdaten bei der Hardware an und bekommt einen Ergebnisstring der mit einem CR endet. Der Klassiker eben;)Dadurch wird auch die Buffer Problematik etwas entschärft da das Programm bestimmt wann Daten angefragt werden und nicht anders herum.

Jetzt soll das VI so erweitert werde daß Werte an die Hardware geschickt werden und während dessen das Abfragen von Messwerten unterbrochen wird. Dann möchte ich das VI "Blatt"?? in ein Einzel-VI packen das sich eben nur um die Kommunikation kümmert (umständlich ausgedrück, sorry). Bin gespannt ob das klappt.

Hallo RabenFlug,

"da ich kein VI gefunden habe"

Das gesuchte nennt sich SpreadsheetStringToArray...

' schrieb:Jetzt soll das VI so erweitert werde daß Werte an die Hardware geschickt werden und während dessen das Abfragen von Messwerten unterbrochen wird.

Rein von der Schnittstelle betrachtet wäre die Unterbrechnung aber nicht erforderlich. Sie ist voll bidirektional, man kann empfangen und gleichzeitig etwas anderes senden.

"Da ich kein VI gefunden habe" (zum Zweiten)
Deine Anmerkung "...mehr all 1000 Worte" gilt auch für Dich selbst. Es gibt kaum kein anders Thema, bei dem sich die hier versammelten Experten mehr um schnelle Antworten bemühen als bei String-Conversion. Also poste Deinen String und Du bist geholfen.

Moin zusammen,

hier mal mein erstes "Program" - Seriell Daten empfangen und aufteilen und Befehle zur Hardware schicken. Die Box verwendet folgenden Syntax:
Datensatz anfordern: nr
(liefert einen String <value0>(tab 09)<value1>(tab 09)<value2>(tab 09)<value3>(tab 09)<value4>(tab 09)<value5>(tab 09)<value6>(tab 09)<value7> )
Ausgang setzen: set <channel 0..7> <value 0..4096>r
(Die Box antowortet mit * für Okay und # für fail)

Solange keine Befehle (set) an die Box geschickt werden und sie Bedingung "Messen" auf "True" steht werden zyklisch Daten angefragt. Der Intervall kann eingestellt werden. Sobald ein Befehl geschickt wird wird das Anfragen von Messdaten ausgesetzt und der Befehl wird gesendet.
Kommt in einem Ergebnis String ein * oder # vor wird der String nicht wie messdaten verarbeitet, ansonsten wird er aufgedröselt und an jedem Tab (09) getrennt.

Das Ganze ist sicher noch nicht optimal und erst recht nicht effizient programmiert, mir geht es im Moment darum in die Programmiersprache zu finden, die "Vereinfachungen" kommen später. Da ich den letzten Messwert im Ergebnisfeld stehen lassen möchte wenn statt Messdaten ein * oder # ankommt habe ich die Hauptbedingung mit einem Schieberegister versehen um den "letzten" Wert zu übernehmen. Das war eine ganz schöne Verdrahterei, gibt es eventuell eine Möglichkeit mehrere Leitungen zu einer Art "Bus" zusammenzufassen wie in der Layoutsoftware "Eagle" ?

Diesen ganzen "Block" möchte ich als Nächstes in ein Sub-VI packen das dann nur noch 8 (integer) Eingänge, 8 Ausgänge, 1 Boolschen "Messen" Eingang, so wie einen Error-Ausgang und einen Eingang zum senden spezifischer Strings hat.

Die Eingänge/Ausgänge hier sind nat. nur Dummies zum testen

Nun dürft ihr mich in der Luft zerreißen