Zickzack-Muster (aber nur bei 2 Mikros gleichzeitig?)

Hi Leute,

ich hoffe, ihr könnt mir bei meinem Problem helfen. Vielen Dank!

Mein Messaufbau:
2 Mal das NI-cDAQ-9181 Chassis mit jeweils einem NI 9232 Modul + LabVIEW 2013 (Version 13.0f2 (32-Bit)). AM NI 9232 hängt ein Mikrofon, dass ich mit 0,004 A intern anrege. Im Anhang befindet sich das Minimalbeispiel "test_2Tasks_2Mikros.vi" meines Problems. Es finden sich darin auch paar Bestandteile aus dem Originalprogramm.

Mein Problem:
Wenn ich nur einen Task mit nur einem virtuellen Mikrofon-Kanal aufmache und dann mein Programm starte, passt alles perfekt und es wird alles richtig gemessen (siehe Bild 1). Wenn ich allerdings 2 Tasks mit jeweils einem virtuellen Mikrofon-Kanal aufmache, dann krieg ich ins Messsignal von beiden Mikrofonen ein Zickzack-Muster rein, das unmöglich stimmen kann! (siehe Bild 3). Interessanterweise sieht dieses "Zickzackmuster" genauso aus, als würde ich bei nur einem Mikrofon die "restart average"-Funktion aktivieren, siehe Bild 2. Keine Ahnung, ob das was mit meinem Problem zu tun hat, aber die Ähnlichkeit ist schon groß!

Was ich bisher probiert habe:
- Nur einen Task mit 2 virtuellen Kanälen, trotzdem selbes Problem
- Verschiedene Sample/Rate-Verhältnisse ausprobiert, hat leider auch nichts bewirkt
- Die Rohdaten als Ascii exportiert und in Excel mal geplottet, um zu überprüfen, ob vielleicht nur ein Fehler in der Datendarstellung besteht, aber auch im Excel-Diagramm ergab sich für ein Mikro eine normale Kurve und für 2 Mikros Zickzackmuster

Irgendwas mit meiner DAQmx-Datenerfassung läuft also falsch, aber was? Hat jemand von euch eine Idee?

Hallo mmmm,
in der FOR Schleife ist ein Taster Restart... wann der genau reagiert kann man nicht feststellen. Den würde ich vor die FOR Schleife legen damit kann man den Startpunkt des Restart Befehls auf den ersten Schleifendurchlauf festlegen.

Gruß Freddy

Hallo 4m,

Zitat:Irgendwas mit meiner DAQmx-Datenerfassung läuft also falsch, aber was? Hat jemand von euch eine Idee?

- Wieso arbeitest du mit einem Array of DAQmxTasks? Warum nicht einfach ein (1) Task mit 2 Kanälen?
- Wieso diese ganzen lokalen Variablen "Array (Tasks)"? Warum kein Draht?
- Wozu die Sequenzstruktur? THINK DATAFLOW!
- Warum immer InsertIntoArray statt eines einfachen BuildArray? (Wobei das bei einem Task mit 2 Kanälen hinfällig wäre!)
- Die Angabe "Samples pro Kanal" im Modus "Kontinuierlich" ist selten notwendig (und noch seltener hilfreich) - LabVIEW-Hilfe lesen!
- Warum keine durchgehende Fehlerbehandlung?
- Das schon genannte "restart averaging" kann mit deinem Problem zu tun haben - ich habe das SV-Toolkit nicht installiert…
- Warum 3 FOR-Loops in der letzten While-Loop?

Wie sehen deine "Rohdaten" aus, bevor sie durch deine Gewichtungs- und Mittelwert-Funktionen bearbeitet werden?
Im zweiten Bild sieht man doch, dass anscheinend das "restart averaging" dieses "Sägen" beeinflusst: was sagt die LabVIEW-Hilfe zu der von dir verwendeten Funktion?

Hi Freddy!

Vielen Dank für deine Antwort. Da hast du Recht, das ist unschönes Programmieren. Habe den Taster in die While-Schleife gezogen, hat leider auch nichts bewirkt. Dennoch danke für deinen Hinweis.

Hi GerdW!

Auch dir vielen Dank für deine Antwort.

Zitat:Wieso arbeitest du mit einem Array of DAQmxTasks? Warum nicht einfach ein (1) Task mit 2 Kanälen?

Würde ich ja gerne machen, aber es ist leider nicht möglich mehrere cDAQ-9181-Chassis mit nur einem Task zu betreiben. Da ich am Ende 2 Stück cDAQ-9181-Chassis mit insgesamt 6 Mikros betreiben will, muss ich mindestens 2 Tasks machen, alles andere bringt mich nicht weiter. Ich habe bereits probiert 1 Task für beide Chassis und somit für insgesamt 6 Kanäle zu verwenden, das ging leider nicht. Siehe auch http://digital.ni.com/public.nsf/allkb/5...C50062B2D2

Zitat:Wieso diese ganzen lokalen Variablen "Array (Tasks)"? Warum kein Draht?

Mir persönlich fällt es da leichter den Überblick zu bewahren. Vor allem möchte ich gerade bei einem Minimalbeispiel alle Variablen im Überblick behalten können, deswegen auch das Anzeigeelement Array (Tasks). Ich glaube aber nicht, dass der Fehler hierdurch verursacht wird, oder?

Zitat:Wozu die Sequenzstruktur? THINK DATAFLOW!

Auch das hab ich gemacht, um sicherzugehen, dass auch alles ganz genauso ausgewertet wird wie ich es will. Es verhindert, dass ich etwas übersehe. Ich glaube aber, dass auch hierdurch nicht der Fehler verursacht wird.

Zitat:Warum immer InsertIntoArray statt eines einfachen BuildArray? (Wobei das bei einem Task mit 2 Kanälen hinfällig wäre!)

Jo, das habe ich ausgebessert.

Zitat:Die Angabe "Samples pro Kanal" im Modus "Kontinuierlich" ist selten notwendig (und noch seltener hilfreich) - LabVIEW-Hilfe lesen!

Alles klar. Hab ich weggelassen, Problem besteht leider immer noch.

Zitat:Warum keine durchgehende Fehlerbehandlung?

Wie gesagt, es ist nur ein Minimalbeispiel. Wenn ich es da irgendwann zum Laufen kriege, dass auf beiden Chassis jeweils ein Mikro gemessen wird, dann mach ich ein schönes Programm drauß mit ordentlicher Fehlerbehandlung. Aber für mein eigentliches Problem ist es doch glaub ich egal, ob er abstürzt und mir den Fehler anzeigt oder ob ich den Fehler in ner Fehlerbox bekomme und dafür das Programm weiterläuft, oder?

Zitat:Das schon genannte "restart averaging" kann mit deinem Problem zu tun haben - ich habe das SV-Toolkit nicht installiert…Im zweiten Bild sieht man doch, dass anscheinend das "restart averaging" dieses "Sägen" beeinflusst

Habe auch mal probiert, den Knopf abzutrennen, dann sollte er "by default" auf FALSE sein. Habe auch mal eine FALSE Konstante angeschlossen. Hat leider bisher alles nichts geändert.

Zitat:Warum 3 FOR-Loops in der letzten While-Loop?

Habe gerade einen überflüssigen vernichtet, aber 2 brauche ich mindestens. Ich hab ja zwei Tasks nach denen ich die erste For-Schleife indiziere und jeder dieser Tasks kann ja nochmal bis zu 3 virtuelle Kanäle haben (geht ja nicht anders mit 2 x NI cDAQ-9181, hatten wir ja oben schon das Thema). Und jetzt muss ich ja aus 2 Arrays mit 3 Elementen 1 Array mit 6 Elementen machen, damit ich das richtig in mein Cluster mit den Signalverläufen einfügen kann. Dazu brauche ich glaube ich mindestens 2 For-Schleifen, oder?

Zitat:Wie sehen deine "Rohdaten" aus, bevor sie durch deine Gewichtungs- und Mittelwert-Funktionen bearbeitet werden?

Ich habe mal die Messdaten direkt abgegriffen noch vor der Gewichtung. Leider kann ich aus diesen Diagrammen keine sinnvollen Rückschlüsse ziehen. Ihr vielleicht? Bild 1 sind die Messwerte von Mikro 1 bei nur 1 Mikrokanal und Bild 2 sind die Messwerte von Mikro 1 bei 2 aktiven Mikrokanälen. (x-Achse = Zeitachse, y-Achse = Spannung).
Außerdem hab ich im Anhang nochmal mein korrigiertes VI hochgeladen, mit alle euren Verbesserungsvorschlägen.

Hoffe, ihr könnt mir bei meinem Problem weiterhelfen!
Vielen Dank schon mal für euer Feedback!

Hi Leute,

jetzt muss ich nochmal einen Nachtrag machen. Ich hab es zum Laufen gebracht! Und zwar läuft mein Minimalbeispiel wenn ich zwei komplett voneinander getrennte Auswertungen für beide Kanäle mache und danach dann beides zusammenfüge. (Siehe VI im Anhang, ist nicht schön geworden, aber hab ich auf die schnelle so zamgedeichselt).

Jetzt ist aber das Problem das ich nicht 6 einzelne Auswertungen schreiben will, nur damit es dann auch für 6 Mikros klappt... Eine Möglichkeit wäre natürlich ein SubVI erstellen und das dann 6 Mal ausführen für jeden virtuellen Channel einmal. Hat vielleicht noch jemand eine bessere Idee? Es muss doch auch irgendwie mit diesen For-Loops klappen oder? Kann einer beim Vergleich der funktionierenden und der nicht funktionieren Version den Fehler finden?

Danke euch und schönes Wochenende!
m^4

Hallo 4m,

Zitat:Ich habe mal die Messdaten direkt abgegriffen noch vor der Gewichtung. Leider kann ich aus diesen Diagrammen keine sinnvollen Rückschlüsse ziehen. Ihr vielleicht?

Nicht wirklich!
Es ist auch nicht hilfreich, die Daten mit Excel zu plotten und dabei den Pointstyle auf "riesig" zu setzen: da sieht man dann nur noch eine Punktwolke. Und wo mal gerade kein Punkt ist, schmieren dicke Linien den Rest der Diagrammfläche zu…

Ich hatte eher folgendes im Sinn: So wie bei den Bildern im ersten Post bitte die LabVIEW-Darstellung zeigen für ein und zwei Mikrofone - aber eben ohne die Nachbearbeitung mit SVT-Funktionen!

Habe gerade dein Update bemerkt: ich wollte dir auch gerade vorschlagen, die beiden Tasks parallel abzuarbeiten!
Wenn du jetzt noch die unnötigen InsertIntoArray durch BuildArray-Funktionen ersetzen würdest. Und auf die Array of DAQmxTask in der letzten Whileloop verzichten würdest: jedes Array enthält doch nur einen Task, wozu also die FOR-Loops!?

Zitat:Jetzt ist aber das Problem das ich nicht 6 einzelne Auswertungen schreiben will, nur damit es dann auch für 6 Mikros klappt...

Du benötigst 2 Task, je einen pro cDAQ-Chassis…
Und du bekommst jeweils 3 Kanäle pro Task - und da sollten wir/du nochmal prüfen, ob dein "Säge"-Problem dann immer noch besteht bzw. wie man das Problem lösen kann!

Hi Leute, hi GerdW,

ich habe es nun endlich alles zum Laufen bekommen, wie ich es brauche. Danke nochmal für eure Hilfe!
Eine Sache ist mir noch aufgefallen:

Wenn man in einem While-Loop mit DAQmx von zwei verschiedenen Kanälen Daten ausliest und diese dann mit demselben SubVI auswertet, dann tritt auch wieder das Zickzack-Muster im Diagramm auf. Scheinbar kann LabVIEW nicht zeitgleich zwei Instanzen von einem SubVI starten ohne dass es dabei zu Problemen kommt. Im Screenshot meiner funktionierenden Lösung seht ihr deshalb auch das SubVI "Auswertung 1" und "Auswertung 2" die zwar die gleiche Funktion haben, aber zwei unterschiedliche *.vi-Dateien sind. Nur falls mal jemand anders auch das Problem hat und hier per Google oder Forumsuche draufstößt

P.S.: Diagrammdeaktivierungsstrukturen, weil ich hab vor, das ganze Mal für 9 Kanäle zum Laufen zu bringen. Aber 6 Kanäle reicht mir als "proof of principle", somit gehe ich davon aus, dass 9 auch kein Problem sind.

Hallo 4m,

Zitat:Scheinbar kann LabVIEW nicht zeitgleich zwei Instanzen von einem SubVI starten ohne dass es dabei zu Problemen kommt.

Doch, das kann LabVIEW!
Man (bzw. DU/der Programmierer) muss es LabVIEW aber auch mitteilen, dass es das machen soll!

Stichwort: "reentrancy"/"ablaufinvariante Ausführung"…

Hi GerdW,

danke! Habs auf "Ablaufinvariante Ausführung mit vorbelegter Kopie" eingestellt jetzt klappts, auch mit einem SubVI.