Datenerfassung mit Feedback-Schleife

Hi!

Ich möchte mit LabVIEW (2016) und einem NI USB-6343 Gerät eine mechanische Schwingung auslesen und gleichzeitig erzwingen.
Genauer möchte ich folgendes umsetzen:

• Ich möchte eine Sinusspannung einer bestimmter Frequenz(en) ausgeben, um die Resonanzmoden meines mechanischen Oszillators zu ermitteln. Die Details zum Aufbau sind denk ich nicht relevant für mein Problem.
• Neben der angelegten Sinusspannung möchte ich einen Dämpfungsterm realisieren, der von µ*dx/dt abhängt, wobei µ eine Dämpfungskonstante ist, und x der gemessenen Amplitude bzw. Auslenkung meines Oszillators entspricht. Dieser Term soll also auf den Sinus draufaddiert werden (Vorzeichen der Dämpfung beliebig). Die Resonanzfrequenzen sollen also in Abhängigkeit der Dämpfung ermittelt werden.
• Das Produkt der Ableitung und der Dämpfung soll dann als Spannung ausgegeben werden.
  

Ich habe nun Probleme bei der Umsetzung. Der Code besteht natürlich aus einem While Loop, in dem die Datenverarbeitung stattfindet. Meine Fragen wären die folgenden, und sie beziehen sich auf zwei verschiedene Ansätze:

• Ansatz 1: Ich messe nur 1 Messwert pro Iteration und berechne meine Ableitung "manuell", indem ich A[i]-A[i-1] rechne. Mache ich das so, vergeht allerdings zu viel Zeit zwischen dem Lesen von Sample 1 und Sample 2, denn bevor ich Sample 2 messe, kommt die oben genannte Berechnung der Ableitung etc. – Hinzu kommt, dass ich die vorherigen Messdaten alle mitschleppen muss, um auch visuell was ausgeben zu können. Ich möchte den berechneten Wert ja dann als "Dämpfung" in meinen Oszillator "füttern" und ihn bremsen/beschleunigen. Bis ich die passende Spannung zu Messwert 1 ausgebe, ist mein Oszillator längst Phasenverschoben, und die Spannung, die ich ausgeben würde, ist "veraltet". Im Prinzip legt also die Geschwindigkeit meiner While-Schleife meine Abtastrate fest. Das scheint mir bei so einer Applikation einfach zu langsam zu sein. Was ich bisher gemessen habe, liegt die Dauer einer Iteration bei 0,00015–0,0015. Ich habe also hier auch keine konstante zeitliche Differenz zwischen meinen Samples. Ist die Idee, pro Schleifendurchgang einen Messwert zu ermitteln, damit durchgefallen? Oder gibt's da Möglichkeiten, das alles zu beschleunigen? Das Plotten meiner Daten beispielsweise geschieht außerhalb des Loops. An anderen Stellen weiß ich nicht, wie ich deutlich schneller werden könnte.
• Ansatz 2: Ich messe pro Iteration N Samples als Waveform. Ich hätte dann beispielsweise "schnell" N samples gemessen, und dt sollte konstant sein. (Meine Hardware hat laut Spezifikationen eine Samplerate von 500.000 Samples pro Sekunde). Im Code kann ich dann bequem mit den vorhandenen VIs eine Ableitung meiner Waveform ermitteln, mit einer Dämpfungskonstante multiplizieren und ein Sinussignal generieren (gleiche Samplerate und #Samples wie mein "DAQ-mx Read"), das ich dann auf meine Waveform der Ableitungen addiere. Das klingt ja alles sehr schön. Aber da bleibt im Grunde das gleiche Problem wie oben. Ich müsste also auch hier beispielsweise Messwert 2 aufnehmen, Ableitung bilden, berechneten Wert als Spannung ausgeben und DANN erst Messwert 3 aufnehmen. Meine aufgenommenen Samples sollen ja alle meinen Dämpfungsterm "enthalten" bzw meine an den Oszillator angelegte elektrische Kraft widerspiegeln.
• Kriege ich irgendwie diese Phasenverschiebungen in den Griff?
  

Ich hoffe, dass ihr ein oder zwei Ideen/Vorschläge habt und bedanke mich schonmal dafür und wünsche eine gesunde Zeit

Ich fasse mal zusammen, was ich verstanden habe: Du möchtest möglichst einen Messwert aufnehmen, umrechnen und das Ergebnis ausgeben - natürlich wiederholt in einer Schleife. Also schon dein Ansatz 1, nur eben zeitlich zuverlässig und um ein vielfaches schneller. Also eher so mit 50k Samples pro Sekunde oder noch schneller.

Antwort: Mit der verwendeten Hardware geht das nicht. So etwas wäre ein Fall für einen FPGA wobei dort die AD- und DA-Wandler schnell genug sein müssen und auch mit einem FPGA gibt es eine zeitliche Verzögerung (Takte für AD-Wandlung + Rechnung + DA-Wandlung).

Erstmal vielen Dank für deine Antwort.

Wie gesagt, hat mein Multifunktionsgerät folgende Spezifikationen:

"USB-Multifunktions-I/O-Gerät mit 32 AI (16 bit, 500 kS/s), 4 AO (900 kS/s), 48 DIO".

Ich denke nicht, dass es die Hardware ist, die zu langsam ist, bei 500 kS/s.

Ich vermute mal, dass ich Ansatz 1 zusammen mit einer ms-wait Funktion verwenden könnte, um zumindest die zeitlichen Abstände zwischen den einzelnen Messwerten einigermaßen konstant zu halten.

Es war für mich auf jeden Fall wichtig, eine zweite Meinung bezüglich "Ansatz 1 vs. Ansatz 2" zu hören. Da das mehr oder weniger das Erste ist, was ich mit LabVIEW mache, ist mir nicht ganz klar, ob der Ansatz so vom Prinzip her Sinn macht, dass ich pro Schleifeniteration nur einen Messwert ermittle. Es sei gesagt, dass mein mechanisches System so um die 170 Hz schwingt, also relativ schnell. Das wäre natürlich bei einer Samplerate von 500 kS/s kein Problem, allerdings scheine ich ja meinen Code nicht sonderlich schnell zu kriegen.

Nehme ich aus 10 Schleifeniterationen die durchschnittliche Zeit, die pro Iteration vergeht, erhalte ich ungefähr 0,65ms pro Iteration bzw Messwert.

Das Aufnehmen eines Messwertes dauert also 0,65ms. Die Periodendauer meines Oszillators liegt bei T=0,0059s. Damit erhalte ich ungefähr 9 Messwerte pro Periode.

Das ist mir leider ein bisschen zu wenig, da ich ja Ableitungen berechne und diese dann an bestimmten Punkten bei nur 9 Messwerten pro Periode das falsche Vorzeichen liefern könnten. Ein falsches Vorzeichen in der Ableitung bedeutet, dass ich möglicherweise meine Schwingung beschleunige, anstatt sie zu bremsen. Oder eben umgekehrt.

Hallo holdsworthy,

Zitat:Wie gesagt, hat mein Multifunktionsgerät folgende Spezifikationen:
"USB-Multifunktions-I/O-Gerät mit 32 AI (16 bit, 500 kS/s), 4 AO (900 kS/s), 48 DIO".
Ich denke nicht, dass es die Hardware ist, die zu langsam ist, bei 500 kS/s.

Ich denke schon, dass diese Hardware ein stark limitierender Faktor ist!

Über USB wirst du NIEMALS einzelne Samples mit 500kS/s einlesen und parallel dann auch noch einzelne Samples per AO (ebenfalls 500kS/s) ausgeben!
Du darfst dich glücklich schätzen, wenn du diesen Ansatz mit 1kS/s halbwegs zuverlässig hinbekommen solltest!

USB ist nicht dafür ausgelegt, konkurrierende Zugriffe auf den Bus mit Taktraten von 1ms (oder noch weniger) zu bedienen…

Wenn du Schleifenraten von >1kHz zuverlässig (d.h. geringer Jitter) erreichen willst, musst du ein potentes RT-Target verwenden.
Für Schleifenraten von (ca.) >10kHz bist du dann ganz schnell bei einem FPGA-Target gelandet!

Hallo,

die Specs deiner Karte lesen sich sicherlich schön, aber du darfst dich nicht davon verleiten lassen. Diese Update-Raten erreichst du bei blockweisen Lesen/Schreiben, aber nicht im Einzel-Sample-Modus. Das schafft Windows nicht, das schafft der USB-Bus nicht.

Martin hat Recht, eine Regelung im kHz-Bereich, das ist in LabVIEW eine Sache für eine Umsetzung per FPGA (z.B. auf einem cRIO), aber nicht per Windows und USB-DAQ-Karte.

Gruß, Jens

Wie schnell muss den die Regelung sein?
Sind die Einschwingprozesse wichtig?

Reicht auch eine langsame Regelung, so alle 10-20 Perioden?
SR auf >=50kSPS , DAC und ADC auf unterschiedliche Flanken der Clock wenn gleiche SR verwendet wird!
10-20 Perioden lesen, Tonedetection um Amplitude (und Frequenz/Phase) zu messen, Anregung anpassen

Da Dein ADC multiplexing verwendet, nur einen Kanal verwenden oder sicherstellen das alle Quellen niederohmig sind , siehe Spec 'Settle time error'
Um den Effekt selber zu erleben, mal den AO konfigurieren und 2 Channels lesen , einmal den AO und dann den anderen offen, kurzgeschlossen und mit verschiedenen Widerständen kurzgeschlossen. Beide Channels ansehen!