Hallo liebe LabVIEW-Entwickler,
ich arbeite gerade an einem Projekt, um von einem USB-6009 Daten anzuzeigen und ggf. zu speichern. Dafür habe ich zuerst den DAQ-Assistenten genommen, der sich doch ziemlich bequem einrichten lässt; weil der User aber selber konfigurieren können soll, welche physikalischen Kanäle überhaupt gelesen werden sollen (und später auch noch Sachen wie deren Skalierung, so weit bin ich aber noch nicht gekommen), bin ich auf ein manuelles Erzeugen des Tasks in einem SubVI und dem Lesen in meinem Haupt-VI ausgewichen.
Das Problem ist folgendes: Mein Signal möchte ich in einem Signalverlaufsgraphen ausgeben. Während das mit dem DAQ-Assistenten aber wunderbar funktioniert hat, läuft der Graph jetzt nicht mehr mit, sondern zeigt mir konstant einen Abschnitt auf der x-Achse von ca. 0 bis 0,05 an (Vielfaches von ms warten lässt grüßen). Meine Frage wäre jetzt: Wie kann ich mit der DAQmx - Lesen-Funktion ein kontinuierliches Signal, genau wie beim Assistenten, erhalten?
Ich hab schon probiert, Timing vor die Schleife zu ziehen, aber das hat nichts genützt. Vielleicht weiß ja jemand Rat.
Vielen Dank im Voraus und freundliche Grüße,
daxel
Ausschnitt aus meinem Hauptprogramm
[
attachment=45870]
SubVI zum Task erstellen
[
attachment=45871]
Achja: Ich benutze LabVIEW 2013 Student Version unter Windows 7.
Hallo daxel,
zum einen solltest du deine Ausgrauereien nicht in der Schleife machen und keine lokalen Variablen verwenden, wenn das entsprechende Terminal schon daneben liegt. Was deinen Graphen angeht, ist ein Verlaufsgraph wohl besser geeignet, um vortlaufend gelesene Daten darzustellen.
Gruß, Marko
Danke für deine Antwort. Da hast du Recht, das werde ich ändern; sind wohl ziemlich dumme Fehler..
Ich kann erst morgen wieder an den Rechner, ich muss mir die Anzeigeelemente wohl nochmal anschauen. Gibt es denn einen Unterschied zwischen Verlaufsgraph und Signalverlaufsgraph oder meinst du das Diagramm?
Allerdings würde mich trotzdem interessieren, ob ich nicht doch irgendwie das ganze Signal kontinuierlich machen kann, so wie es auch aus dem DAQ-Assistenten käme. Sonst sind ja wahrscheinlich auch die x-Werte der Messdaten falsch, wenn ich sie in die Datei schreibe, oder?
So, ich habe mal rumprobiert. Eine Umstellung auf das Signalverlaufsdiagramm funktioniert nicht (alleine), denn aktuell fangen meine Messdateien alle 50 Zeilen wieder etwa so an:
Code:
Channels 3
Samples 50 50 50
Date 2013/08/15 2013/08/15 2013/08/15
Time 07:49:13,0779958833531705163 07:49:13,0780167161078420899 07:49:13,0780375490953443072
Y_Unit_Label Volts Volts Volts
X_Dimension Time Time Time
X0 0,0000000000000000E+0 0,0000000000000000E+0 0,0000000000000000E+0
Delta_X 0,001000 0,001000 0,001000
***End_of_Header***
X_Value Plot 1 Plot 2 Plot 3 Comment
-0,000819 -0,002137 1,402531
-0,000819 0,001681 1,389805
-0,000183 -0,000864 1,399986
Das ist natürlich nicht sehr schön, ich würde eine durchgehende Reihe an Daten haben. Dafür werde ich das Signal wahrscheinlich irgendwie kontinuierlich hinbekommen müssen, oder? Gehört vielleicht das DAQmx-Lesen außerhalb der Schleife? Aber wie kann ich es dann abbrechen und dafür sorgen, dass Messwerte nur bei aktivierten Button in die Datei geschrieben werden? Ich habe leider gerade keien Idee, was genau ich anders machen muss.
Hier nochmal mein Programm in leicht geänderter Fassung:
[
attachment=45892]
Hallo Daxel,
das "Schöne" an ExpressVIs ist, dass sie alle wichtigen Einstellungen konsequent vor dem Auge des Betrachters
verbergen verstecken!
Ich würde einfach mal vermuten, du hast das ExpressVI "Messwerte schreiben" falsch konfiguriert! Man muss (glaube ich) nicht bei jedem Aufruf einen Header schreiben...
Zitat:Eine Umstellung auf das Signalverlaufsdiagramm funktioniert nicht (alleine), denn aktuell fangen meine Messdateien alle 50 Zeilen wieder etwa so an
- Die Darstellung im Graph oder Chart hat NICHTS mit dem Speichern in der Messdatei zu tun: der Draht verzweigt sich doch ganz klar vor den beiden Funktionen. THINK DATAFLOW!
Zitat:Gehört vielleicht das DAQmx-Lesen außerhalb der Schleife?
- Natürlich nicht. Wie willst du denn sonst in der Schleife an neue Messdaten kommen? THINK DATAFLOW!
- Ich würde dagegen das SampleRateSetting aus der Schleife herausnehmen. Oder willst du ständig die SampleRate ändern?
- Den Signalverlaufsgraph bitte löschen und neu erstellen. Dann ist er nicht mehr vom Typ DDT...
- Die Deaktiviert-Properties haben eigentlich schöne lesbare/selbstdokumentierende (!) Enums, mit denen sie verdrahtet werden können. Dann würden auch hier die roten CoercionDots wegfallen...
(15.08.2013 08:14 )GerdW schrieb: [ -> ]Ich würde einfach mal vermuten, du hast das ExpressVI "Messwerte schreiben" falsch konfiguriert! Man muss (glaube ich) nicht bei jedem Aufruf einen Header schreiben...
Da hast du vollkommen Recht. Ich musste das nur umstellen, und jetzt funktioniert es genauso wie es sollte. Danke!
(15.08.2013 08:14 )GerdW schrieb: [ -> ]- Die Darstellung im Graph oder Chart hat NICHTS mit dem Speichern in der Messdatei zu tun: der Draht verzweigt sich doch ganz klar vor den beiden Funktionen. THINK DATAFLOW!
Da hab ich mich schlecht ausgedrückt, das war darauf bezogen dass ich dachte "Messwerte schreiben" bräuchte einen anderen Datentyp (DDT) damit alles richtig funktioniert.. Am Dataflow-Denken muss ich aber wirklich noch arbeiten
(15.08.2013 08:14 )GerdW schrieb: [ -> ]Ich würde dagegen das SampleRateSetting aus der Schleife herausnehmen. Oder willst du ständig die SampleRate ändern?
Birgt das Nachteile in der Schleife? Die SampleRate soll ständig änderbar sein (zumindest, während keine Dateien eingestellt werden) - vielleicht muss ich mir dasd noch was schöneres mit einer Eventstruktur überlegen..
(15.08.2013 08:14 )GerdW schrieb: [ -> ]- Den Signalverlaufsgraph bitte löschen und neu erstellen. Dann ist er nicht mehr vom Typ DDT...
An einer anderen Stelle werden aber wieder solche Daten angezeigt (vom Express-Vi "Messwerte aus Datei lesen") - macht das denn was? Siehe hier:
[
attachment=45898]
Ich hoffe, ich gebe nicht zu viele Widerworte
- danke für die Hilfe!
Hallo daxel,
ich würde immer vom DDT abraten - ist aber keine "Pflicht". Der DDT hat halt auch Nachteile, und die sollte man kennen (oder sich dessen zumindest bewußt sein)!
Zur Samplerate:
- Nicht jeder DAQmxTask mag es, wenn die Samplerate zwischendrin geändert werden soll.
- Ich persönlich finde es unschön, wenn mitten in einer Messung die Samplerate geändert wird. Macht die Auswertung meist komplizierter... (Auch hier nur persönlicher Geschmack, dein Vorgehen mag begründet sein.)
(15.08.2013 09:31 )GerdW schrieb: [ -> ]ich würde immer vom DDT abraten - ist aber keine "Pflicht". Der DDT hat halt auch Nachteile, und die sollte man kennen (oder sich dessen zumindest bewußt sein)!
Sonst kann ich ja vom Express-VI auf das "manuelle" Lesen umsteigen. Um was für Nachteile geht es dir denn?
Selbst wenn es keine Pflicht ist, ich denke mal du kennst dich besser aus als ich
Zur Samplerate:
- Nicht jeder DAQmxTask mag es, wenn die Samplerate zwischendrin geändert werden soll.
- Ich persönlich finde es unschön, wenn mitten in einer Messung die Samplerate geändert wird. Macht die Auswertung meist komplizierter...
[/quote]
Dann gehe ich lieber auf Nummer sicher und mache die Samplerate nur von vornherein einstellbar.
Ich melde mich nochmal kurz, ich hab nämlich noch ein kleines Problem mit meinem Signalverlauf. Es hieß ja, für "meine Zwecke" (also fortlaufend die Daten anzeigen) sei das Signalverlaufsdiagramm besser als der -graph, wenn ich mich nicht irre.. Jetzt habe ich immer noch das kleine Problem, dass in den mir angezeigten Daten immer wieder Teile fehlen, siehe Bildschirmfoto. Ist in meinem VI noch ein grober Fehler, der das bedingt?
Danke
Hallo Daxel,
Zitat:Ist in meinem VI noch ein grober Fehler, der das bedingt?
Nicht unbedingt grobe Fehler, aber ein paar unfeine Stellen:
- Du hast deine DAQmxTasks mit Samplerate definiert. Das bedeutet: du legst beim DAQmxRead fest, wieviele Samples du pro Aufruf auslesen willst statt mit -1 alle vorhandenen anzufordern. Über die Anzahl der Sample und die Samplerate stellt sich automatisch ein Looptiming ein und du kannst deine eigene Wartezeit (50ms Metronom) aus der Schleife löschen!
- Du weißt nicht, wie lange das Speichern der Daten benötigt. Hier kann es zu unerwarteten Latenzen kommen. Kennst du das Producer-Consumer-Schema schon?
- Du benutzt InsertIntoArray, wo man auch ein einfaches BuildArray nutzen könnte...
- Du hast kein durchgängiges Errorhandling.
Kommt die Lücke im Chart während einer Messung oder wenn du schnell hintereinander Messungen startest?