Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich arbeite derzeit an meinem ersten LabVIEW-Projekt und ich würde mich freuen, wenn ich von eurer Seite etwas Feedback zu meinem VI und evtl. Antworten zu so manchen Fragen bekommen würde.
In dem Projekt geht es darum, Leistung bei Gleichstrom zu berechnen, sprich also Spannung und Strom zu messen und diese zu multiplizieren. Dazu verwende ich ein DAQ USB-6001 Device. Nach einigen Stunden von YT-Videos gucken, über Beispiel-VIs abarbeiten, bis zu Forumsbeiträgen und -links durchlesen, hab ich mir jetzt mal ein kleines VI gebastelt, mit dem ich 2 Sinusspannungen von Funktionsgeneratoren in AI0 und AI1 differenziell mit jeweils 1kHz Abtastrate kontinuierlich einlese und die beiden dann einfach multipliziere, um die "Leistung" zu berechnen. "Samples pro Kanal" hab ich dabei auf 100 gesetzt - so wie ich das verstanden hab, ist das im kontinuierlichen Betrieb der Buffer vom Gerät bevor es die Daten zum PC schickt. Oder?
Mir stellen sich nun einige Fragen:
1. Ich habe versucht meine gemessenen und berechneten Daten nach Anleitung eines BeispielVIs(Grundlagen - Signalverlauf - Signalverläufe in Datei schreiben) erst in ein .dat-File zu speichern und dann in ein .txt-File zu exportieren. Dabei mach ich scheinbar irgendetwas falsch, denn im .txt-File sind eigentlich keine Messdaten, sondern lediglich "Header"-Beschriftungen wie Kanalnamen, delta t, etc. wiederholt zu finden.
Wenn ich den Express-Block "Messdaten in Datei schreiben" verwende, komme ich zu zufriedenstellenden Ergebnissen, allerdings wollte ich gleich (wie so oft in diesem Forum gelesen) Abstand von Express Möglichkeiten nehmen und es gleich "gescheit" lernen.
2. Könnt ihr euch vorstellen, dass ich mit dem jetzigen Aufbau und der Methode von Abtasten, Buffern, Speichern Probleme mit längeren Messungen bekommen werde? Geplant sind Messungen von Spannung und Strom eines Lampenofens in einem Dilatometer, die können gut und gerne mal 24 Stunden und länger dauern.
In früheren Versuchen, immer unter Verwendung des DAQ-Assistenten, lief ich in einen, so kam es mir zumindest vor, Overflow. Das zeigte sich erst durch langsameres Aktualisieren der Graphen bis hin zum Programmabsturz. Die genaue Fehlermeldung fällt mir jetzt leider nicht mehr ein, jedenfalls wurde mir unter anderem empfohlen den Bufferspeicher, also Rate im kontinuierlichen Betrieb, zu erhöhen.
3. Also grundsätzlich läuft die Messung stabil und das Problem aus Frage 2 kam auch bei einer 60 Minuten Messung nicht mehr zum Vorschein. Allerdings kommt es nun in der Darstellung der berechneten "Leistung" zu einem mir nicht erklärbarem Phänomen: Ab und an werden im Signalverlaufsdiagramm die "älteren" Werte des Signals abgeschnitten - ich hab euch einen Screenshot angehängt. Ist nur eine Kleinigkeit und nicht weiter schlimm, würde mich nur interessieren, woher das kommt.
4. Einfach ein kleines Feedback zu meiner Herangehensweise wäre nett. Ich hab mir das alles im Selbstudium durch Lesen, Videos schauen und herumprobieren angeeignet - ich hab also keine Ahnung, ob ich wirklich effizient und sorgfältig arbeite oder ob das absoluter Schwachsinn ist, was ich hier betreibe.
So, danke schonmal an jeden, der bis hierhin gelesen hat. Ich hab mein VI in der 2018 angehängt, das selbe auch in 2010 gespeichert, hoffe ihr könnt zumindest eines davon öffnen.
Danke.
Liebe Grüße
Christoph
Anzeige
28.02.2019, 08:35 (Dieser Beitrag wurde zuletzt bearbeitet: 28.02.2019 08:39 von GerdW.)
1. Es ist im Allgemeinen Blödsinn, Daten erst in eine Datei zu schreiben und dann sofort wieder auszulesen und in eine zweite Datei zu schreiben. Schreibe sie lieber direkt in die zweite Datei!
(Die Endung "dat" beschreibt kein allgemein normiertes Dateiformat, wie txt oder csv, und ist daher nicht wirklich hilfreich bei der Problembeschreibung.)
2. Ja, kann ich mir vorstellen.
Das Problem ist aber nicht DAQmx, sondern deine Datei-Operationen. Diese öffnen und schließen die Dateien in jeder Iteration erneut, was eben Zeit kostet. Besser ist es, Dateien nur einmal vor der Schleife zu öffnen, in der Schleife zu schreiben und nach der Schleife zu schließen. (Oder man verwendet eine Consumer-Producer-Struktur zum Buffern der Daten, muss dann aber bei langen Messungen auf den möglichen Speicherbedarf achten.)
3. Programmabsturz? Der sich wie äußert?
4. Im Großen und Ganzen ist dein VI ok. Aber ich hätte folgende Anmerkungen:
- Um Elemente aus Arrays zu indizieren, sollte man IndexArray verwenden. Kein Grund, hier ExpressVIs zu nehmen!
- Um ein Array zu erstellen, sollte man BuildArray verwenden. Kein Grund, hier ExpressVIs zu verwenden!
- Kanalnamen kann man schon direkt beim DAQmxCreateChannel festlegen. Kein Grund, dies in jeder Schleifeniteration erneut nachträglich durchzuführen!
- Die boolschen Funktionen können direkt mit dem ErrorCluster umgehen, da muss man nicht erst den Status unbundlen. (Zumindest im LV2010-VI.)
- Ich würde immer eine feste Anzahl Samples beim DAQmxRead abfragen…
Ich kann deine Anmerkungen aus Punkt 1 und 2 nachvollziehen und werde sie nach Möglichkeit umsetzen.
In Punkt 3 wollte ich nicht auf einen Programmabsturz eingehen, ist vermutlich falsch rüber gekommen. Dabei ging es mir um das Signalverlaufsdiagramm des berechneten Signals und dessen, mir scheint so, Überschreiben des Buffers mit neuen Daten.
Das würde man vermutlich mit einem kleiner aufgespannten Bereich der x-Achse abfangen können, allerdings werde ich mich mit dem Problem erst später verfassen, da ich das berechnete Signal evtl. noch mitteln möchte und sich damit nach meinem Verständnis die Menge an Datenpunkten pro Zeit verringern sollte.
Zitat:4. Im Großen und Ganzen ist dein VI ok. Aber ich hätte folgende Anmerkungen:
- Um Elemente aus Arrays zu indizieren, sollte man IndexArray verwenden. Kein Grund, hier ExpressVIs zu nehmen!
- Um ein Array zu erstellen, sollte man BuildArray verwenden. Kein Grund, hier ExpressVIs zu verwenden!
Mit den Arrays sollte ich keine Probleme haben, damit hab ich schon herumgespielt. Werde versuchen es anhand deines angehängten Vorschlags umzusetzen.
Zitat:- Kanalnamen kann man schon direkt beim DAQmxCreateChannel festlegen. Kein Grund, dies in jeder Schleifeniteration erneut nachträglich durchzuführen!
Dass man Kanalnamen direkt bei DAQmxCreateChannel mitgeben kann ist an mir scheinbar vorbei gegangen, ist eigentlich aber auch nur logisch. Weiß nicht wie ich das übersehen konnte, das werde ich mir noch genauer ansehen.
Zitat:- Die boolschen Funktionen können direkt mit dem ErrorCluster umgehen, da muss man nicht erst den Status unbundlen. (Zumindest im LV2010-VI.)
Ich glaube zu wissen, was du mit "Status unbundlen" meinst - nämlich den Status TRUE oder FALSE manuell aus dem ErrorCluster auszulesen. Das mach ich eigentlich nicht, zumindest nicht absichtlich und nicht in der LV2018-VI. Klär mich bitte auf, wenn ich mich hier irre.
Zitat:- Ich würde immer eine feste Anzahl Samples beim DAQmxRead abfragen…
Meinst du hier, dass du im endlichen Betrieb mit N Samples arbeiten würdest oder gehst du hier auf die von mir freigelassene Verknüpfung zu "number of samples per channel" von DAQmxRead ein und würdest im kontinuierlichen Betrieb bleiben?
Ich dachte, diesen Input frei lassen zu können, da ich "Samples pro Kanal" schon vorher festgelegt habe und ich die Beschreibung auf der ni.com Support Seite eventuell falsch interpretiert habe.
Nun nochmal zum Speichern der Daten.
Zitat:(Oder man verwendet eine Consumer-Producer-Struktur zum Buffern der Daten, muss dann aber bei langen Messungen auf den möglichen Speicherbedarf achten.)
Empfiehlst du in meinem Fall die Verwendung einer Producer-Consumer-Struktur? Würde es bzgl. Speicherbedarf helfen, die Daten in mehrere Textfiles zu splitten?
Noch eine kleine Frage, sorry: Reicht es in meinem Fall nun den Task nur zu stoppen oder sollte ich ihn anschließend auch löschen?
Zu 3. Wie ist die Historie der beiden Charts konfiguriert?
Zitat:Meinst du hier, dass du im endlichen Betrieb mit N Samples arbeiten würdest
Nein, bei "kontinuierlich" bleiben, aber bei DAQmxRead eine feste Anzahl Samples abfragen.
Zitat:Ich dachte, diesen Input frei lassen zu können,
Dann macht DAQmxRead aber etwas anderes, als du denkst. Steht in der Hilfe zur Funktion…
Zitat: da ich "Samples pro Kanal" schon vorher festgelegt habe und ich die Beschreibung auf der ni.com Support Seite eventuell falsch interpretiert habe.
Du hast beim DAQmxTiming einen Wert vorgegeben, am Input namens "Samples pro Kanal".
Hast du dir die Hilfe zu dieser Funktion durchgelesen? Auch den Eintrag speziell für diesen Input - und seine unterschiedlichen Bedeutungen?
Im "kontinuierlich"-Modus macht dieser Input nämlich etwas anderes - und das brauchst du nur sehr selten…
ich danke dir für diesen Hinweis. Ich hab mir die Einträge nochmal durchgelesen.
Hast du eventuell noch Tipps zum Speichern der Daten?
Am Ende sollen zwei gemessene Spannungen (jeweils 1 kHz) und ein daraus berechnetes Signal gespeichert werden.
Die Messungen können gut und gerne 24 Stunden und länger dauern.
Wird dazu das einfache "vor der Schleife öffnen, in der Schleife schreiben, nach der Schleife schließen" in ein oder mehrere Textfiles reichen?
Oder werde ich eine Producer-Consumer-Struktur benötigen?
EDIT: Bzgl. der Historien der Charts: Ich hab diese nicht bearbeitet, sind also gänzlich auf Standardeinstellungen - wenn man das denn so sagen kann. Leider hab ich gerade keinen Zugriff auf mein VI, kann dir also derzeit nichts genaueres sagen.
Zitat:Die Messungen können gut und gerne 24 Stunden und länger dauern. Wird dazu das einfache "vor der Schleife öffnen, in der Schleife schreiben, nach der Schleife schließen" in ein oder mehrere Textfiles reichen?
Das sollte eigentlich passen…
Du bekommst also Dateien der Größe 24*3600*1000*2 Samples *10Byte/Sample ~= 1.7GB. Hast du passende Software zur Auswertung dieser Datenhalden?
Auch, wenn ich die Berechnung direkt in LabVIEW mache und mit aufzeichne? Mein Wunsch wäre nämlich, den berechneten Wert direkt im Chart anzeigen zu lassen. Es geht um kurzzeitige Leistungsabfälle und -zunahmen, wäre schön, diese direkt beobachten zu können.
Die anschließende, genaue Auswertung wird in Matlab erfolgen. Das passiert schon mit ähnlich großen Datenmengen, ich nehme Temperatur- und Längenänderungen mit anderer Hard- und Software auf.
mit dem 3. berechneten Signal landest du dann eben bei 2.6GB.
Pro Sekunde sind das aber trotzdem nur 3*1000*10Bytes ~= 30kB, das ist üblicherweise kein Problem.
/
DAQ Support/Feedback/Debugging
Noch eine kleine Frage, sorry: Reicht es in meinem Fall nun den Task nur zu stoppen oder sollte ich ihn anschließend auch löschen?