Problem mit schneller (!) Messung

Hallo nochmal!

Ich habe zwar nicht den Eindruck, als sei mein Problem - oder vielmehr dessen Lösung - interessant für besonders viele Leute, dennoch berichte ich mal fleissig weiter... Soviel vorweg: Ich denke ich habe eine akzeptable Lösung gefunden! Mein Verständnisproblem war (und ist) jedoch das folgende:
Ich möchte einen externen Sample-Takt verwenden (inkrementaler Drehgeber). Daher verbinde ich das "DAQmx Timing VI (Sample Takt)" mit der Taktquelle (PFI7 an NI PCI 6071E). Weiterhin erforderlich ist die Angabe einer Rate. Hierzu lese ich in der Hilfe "Wenn Sie den Sample-Takt von außen zuführen, stellen Sie hier die maximal erwartete Sample-Takt-Rate ein". Da denke ich mir doch, dass es sich nur noch um eine Art Richtwert handelt, da ja mein externer Takt vorliegt und angeschlossen ist. Wozu eine erwartete Rate angeben, wenn diese doch gleichermaßen angeschlossen ist?!
Der langen Rede kurzer Sinn: Ich messe nun vorher meine Frequenz und berechne daraus die gewünschte Samplerate (ich kenne ja die Taktung: 240 Sample-Impulse pro Haupt-Trigger). Diese gebe ich dann dem DAQmx Timing VI und erreiche (endlich) meine gewünschte Messgeschwindigkeit. Der Haken bei dieser Nummer: Ich bin auf eine konstant bleibende Haupttriggerfrequenz angewiesen. In meinem Fall ist aber davon auszugehen, insofern bin ich zufrieden.
Eine weitere Voraussetzung ist die Umstellung von "finite samples" auf "continuous samples". Trotzdem bleibe ich bei "number of samples" bei 240 (bei Timing und Read).

Ich hänge mein VI mal an, für den Fall, dass jemand eine ähnliche Lösung gebrauchen kann.
Ich würde mich jedoch über Kommentare, sowohl was meine Lösung als auch mein verbliebenes Verständnisproblem angeht, sehr freuen! Denn eigentlich wüsste ich halt gerne, WARUM es so klappt...
Habt Dank für Eure Teilnahme!

Viele Grüße,
Kuki

Hi,

das hier ist so ähnlich wie deine Lösung, es wird aber nur eine feste Zahl von Werten gelesen und dann neu getriggert, probiers halt mal aus!

http://decibel.ni.com/content/docs/DOC-11757


Man könnte evtl. auch ganz was anderes machen...das müsste halt mal einer probieren:

Anstelle des Haupttriggers könntest du auch den "240er-Takt" nehmen und mit jedem Trigger pro Kanal genau einen Wert aufnehmen! Ich hab sowas mal mit ner "Nicht-NI-Karte" (IK220 von Heidenhain) gemacht, die bietet allerdings auch den entsprechenden Modus bzw. Eingang...

Gruß
Achim

Hi Achim,
danke für die Antwort. Das Beispiel kannte ich nicht und ich verstehe auch nicht, was es mit dem Retrigger auf sich hat.

Diese Einzelwertaufnahme heißt wohl "Hardware timed single point" und wird tatsächlich von meiner 6071E unterstützt. Habe ich auch mal ausprobiert. Dieser Modus erschwert allerdings das weitere Vorgehen mit den Daten (Betriebsdatenüberwachung, Weiterverarbeitung, etc.). Außerdem erfolgt die Messung ungepuffert und praktisch wesentlich unzuverlässiger.

Ich bin einfach nur immernoch verwirrt, da man eine SampleRATE vorgeben muss, obwohl man einen (externen) TAKT vorgibt. Letztlich ist es eben auch NICHT dieser Takt, sondern die "von Hand" eingestellte Rate, die das dt des Signals festlegt. Dies erschüttert mein Verständnis der Samplerate. Oder mein Verständis von Rate bzw. Takt. Dazu kommt ja, dass die LV-Hilfe sagt, man solle die "maximal erwartete" Rate eintragen. Stattdessen wird EXAKT diese Rate verwendet. Wenn ich da nicht grundsätzlich was falsch verstanden habe (wovon ich allerdings ausgehe...), finde ich das untragbar!

Wie dem auch sei. Ich bin mit dieser Lösung zufrieden. Ich wollte das nur zur Diskussion stellen und freue mich über jeden input diesbezüglich!

Gruß,
Kuki

(15.03.2011 15:37 )Kuki schrieb:  Eine weitere Voraussetzung ist die Umstellung von "finite samples" auf "continuous samples". Trotzdem bleibe ich bei "number of samples" bei 240 (bei Timing und Read).

Habe mich jetzt nicht mit dem ganzen Thread und Deinem Problem beschäftigt, nur dazu etwas:
Hilfe zu Sample-Takt lesen! Der Eingang "Number of Samples" wird bei Messart "kontinuierlich" umfunktioniert zu etwas ganz anderem (Puffergröße), der Inputname ist dann irreführend und falsch. Wegen der automatischen Verwaltung der Puffergröße fährt man hier fast immer gut, wenn man den Eingang einfach nicht anschließt.
Bei dem Read-VI ist das etwas ganz anderes, es ist die Anzahl von Werten, die aus dem Puffer gelesen werden. Hier bei 240 Samples: Es wird immer gewartet, bis 1 Umdrehung erfolgt ist, dann werden alle 240 Samples auf einmal gelesen.

Anderes Beispiel für Modus endliche Messung: Einstellung Sample-Takt: 10000 Samples, Einstellung bei Read: 1000. Es werden dann von den insgesmt 10000 erzeugten Samples mit Read immer 1000 Samples ausgelesen. Read muß dann 10 Mal aufgerufen werden, damit alle Samples aus dem Puffer gelesen werden.


Edit, weitere Amerkungen:
1.) Wozu brauchst Du denn überhaupt den Task CI-Frequenz? Die Zeit für 1 Umdrehung erhälst Du doch aus der Schleifen-Durchlaufzeit, und die Abtastfrequenz aus dem 240-fachen der Drehfrequenz?
2.) Warum nimmst Du als Ausgansformat die Waveform? Da die Triggerung extern und nicht mit streng konstantem dt erfolgt, die Wavefom aber ein konstantes dt voraussetzt, kann doch das dt der Waveform überhaupt keine sinnvolle Information enthalten. Was steht denn jetzt in dem dt der Waveform drin?

Zitat:Das Beispiel kannte ich nicht und ich verstehe auch nicht, was es mit dem Retrigger auf sich hat.

Ich habs jetzt nicht getestet, aber ich gehe von folgendem Verhalten aus:

Es gibt grundsätzlich mal zwei verschiedene Arten Messwerte zu erfassen, nämlich einmalig oder kontinuierlich. Bei einmaliger Erfassung (Finite Samples) kommt ein Trigger und ab diesem Trigger werden N Messwerte mit einer Abtastrate S/s gelesen...dann ist schluss! Es erfolgt keine weitere Abtastung! Das geht nur, wenn das steuernde VI wieder aufgerufen wird und den Triggereingang "manuell" wieder scharf macht!

Im Gegensatz dazu läuft bei der kontinuierlichen Abtastung genau einmal der Trigger rein, und dann wird (theoretisch unendlich lange) mit S/s abgetastet...bis irgendeiner oder irgendetwas das wieder stoppt.

Im gezeigten Beispiel wird das ganze kombiniert: Es werden ab dem Trigger N Messwerte mit S/s gelesen...und dann wird mit dem nächsten (und nächsten...und nächsten...) Trigger wieder genau das gleiche gemacht. D.h. es wird mit jedem Trigger ein endliches Paket von Messwerten erfasst! Du musst halt aufpassen, dass die Erfassung der X angeschlossenen Kanäle mit jeweils N Messwerten fertig ist, bis der nächste Triggerimpuls kommt! Das Problem ist ja, dass man für die N Werte eine Abtastrate angeben muss...und damit es sinnvoll für deine Anwendung ist, müsstest du VOR dem Start der Abtastung schon die Drehzahl (d.h. die Triggerfrequenz) kennen, damit jeder der N gelesenen Werte (näherungsweise) jeweils einem Impuls des "240er-Takts" entsprechen.

Dazu auch folgende Frage: Da du die erfassten Messwerte abhängig von der Umdrehung einer Welle machst: Wäre es da nicht geboten, alle Kanäle simultan zu erfassen? Momentan werden ja die Signale ab dem Trigger zeitversetzt zueinander gelesen, d.h. du hast eigentlich keine direkte Zuordnung der Kanalwerte zur tatsächlichen Position. Das ginge nur, wenn du wirklich bei jedem "240er-Impuls" einen Wert lesen würdest. Oder ist der Zeitversatz für dich vernachlässigbar?

A.

(16.03.2011 11:37 )Achim schrieb:  Im gezeigten Beispiel wird das ganze kombiniert: Es werden ab dem Trigger N Messwerte mit S/s gelesen...und dann wird mit dem nächsten (und nächsten...und nächsten...) Trigger wieder genau das gleiche gemacht. D.h. es wird mit jedem Trigger ein endliches Paket von Messwerten erfasst! Du musst halt aufpassen, dass die Erfassung der X angeschlossenen Kanäle mit jeweils N Messwerten fertig ist, bis der nächste Triggerimpuls kommt! Das Problem ist ja, dass man für die N Werte eine Abtastrate angeben muss...und damit es sinnvoll für deine Anwendung ist, müsstest du VOR dem Start der Abtastung schon die Drehzahl (d.h. die Triggerfrequenz) kennen, damit jeder der N gelesenen Werte (näherungsweise) jeweils einem Impuls des "240er-Takts" entsprechen.

Das siehst Du falsch, hier wird nichts kombiniert, es handelt sich hier um kontinuierliche Messung in Reinkultur. (Beziehe mich auf das VI FINAL_Mess-test-kontinuierlich_VÖ).
Die kontinuierliche Messung wird nicht immer wieder gestartet, sondern nur ein einziges Mal durch eine fallende Flanke an PFI9. Die weiteren Impulse nach Start an diesem Pin werden ignoriert, solange der Task läuft. (Also hier heißt das: erst nach Stop und Neustart dieses VI würde wieder ein Startimpuls zur Kenntnis genommen)

Zitat:Das siehst Du falsch, hier nichts kombiniert, es handelt sich hier um kontinuierliche Messung in Reinkultur. (Beziehe mich auf das VI FINAL_Mess-test-kontinuierlich_VÖ).

Ich nicht...

(16.03.2011 12:26 )Achim schrieb:  Ich nicht...

Ja dann kann ich nur noch auf meine aktuelle Fußzeile verweisen - was aber nicht heißen soll, daß ich das individuelle Aussterben wünsche

(16.03.2011 11:37 )Achim schrieb:  Das Problem ist ja, dass man für die N Werte eine Abtastrate angeben muss...und damit es sinnvoll für deine Anwendung ist, müsstest du VOR dem Start der Abtastung schon die Drehzahl (d.h. die Triggerfrequenz) kennen, damit jeder der N gelesenen Werte (näherungsweise) jeweils einem Impuls des "240er-Takts" entsprechen.

Ja. Genau das mache ich ja auch in meinem Beispiel. Bei annähernd konstanter Drehzahl ist die Zuordnung zum vorher angegebenen Sampletakt und die Verzögerung zwischen der Abfrgae der einzelnen Kanäle wohl vertretbar. Die Drehzahl gebe ich ja auch vor. Sie ist keine "echte" Messgröße.
Die Hilfe habe ich ürbigens mittlerweile ziemlich oft schon gelesen... Dass ich meine Puffergröße unnötiger Weise angebe war mir sogar bewusst.

Das mit der Waveform ist mir allerdings neu. Ich dachte, ich hätte einen Informationsgewinn, wenn ich das dt "mitmessen" würde. Dass es als konstant vorrausgesetzt wird, war mir nicht klar. Als dt wird immer genau der Reziprokwert der vorgegebenen Samplerate ausgegeben. Wenn ich z.B. eine Sampletaktquelle (PFI7) angebe und die Samplerate (lt. Hilfe wie gesagt dann die maximal erwartete Rate) auf 240*60 Hz = 14400 Hz einstelle, erhalte ich ein dt = 1/14400 s = 6,94e-5 s. Wenn ich mit der erwarteten Samplerate weiter "übertreibe" im Vergleich zu tatsächlich anliegenden Haupttriggertakt (Wellenumdrehung), dann werden die Werte nicht gleichmäßig über eine Umdrehung, sondern schneller gelesen.

(16.03.2011 11:37 )Achim schrieb:  Dazu auch folgende Frage: Da du die erfassten Messwerte abhängig von der Umdrehung einer Welle machst: Wäre es da nicht geboten, alle Kanäle simultan zu erfassen? Momentan werden ja die Signale ab dem Trigger zeitversetzt zueinander gelesen, d.h. du hast eigentlich keine direkte Zuordnung der Kanalwerte zur tatsächlichen Position. Das ginge nur, wenn du wirklich bei jedem "240er-Impuls" einen Wert lesen würdest. Oder ist der Zeitversatz für dich vernachlässigbar?

Richtig. Die simultane Erfassung aller Kanäle bei jedem 240er Impuls ist exakt das, was ich will. Genau dafür - dachte ich... - sei der Sampletakt. Der Zeitversatz bei der momentanen Lösung von wenigen µs ist nicht schön, aber vertretbar. Wäre die Alternative die "hardware timed single point"-Lösung?

So langsam habe ich das Gefühl, auf dem Weg dahin zu sein, zu wissen, was ich tu. Danke für Eure Hilfe dabei!

Zitat:Wäre die Alternative die "hardware timed single point"-Lösung?

Allein vom "Titel" her würde ich sagen: Ja!

Dich interessiert ja das dt nicht, weil du keine zeitlich zuordenbare Messung anstrebst sondern eine auf den Drehwinkel bezogene Erfassung willst. (Von "dt" spricht man auch nur bei zeitlich äquidistanten Messwerten, d.h. bei konstanter Samplerate...bei dir ist daher "dphi" angebracht!)

Alles was du bisher gemacht hast (und auch das von mir verlinkte Beispiel) bringen dir näherungsweise solange das gewünschte winkelabhängige Ergebnis, wie du mit konstanter Drehzahl die Welle antreibst! Wenn du aber "Dellen" im Drehzahlverhalten hast, kannst du deine Messwerte vergessen! Du wirst nur unabhängig von der Drehzahl, wenn du eine Einzelwerttriggerung machst!


Genau so was hab ich auch schon gemacht: Ich musste ein Drehmoment (Analogwert) über dem Drehwinkel (Sin-Cos-Geber) aufzeichen. Dazu hab ich einen Heidenhain-Drehgeber mittels einer passenden Heidenhain IK220-Karte aus meiner NI-Multi-IO-Karte heraus mit einem Taktsignal (Pulse train) über einen PFI getriggert...den gleichen Takt habe ich intern auf einen anderen PFI geroutet, der als Clock für die Analogwerterfassung diente (anstelle des internen Oszillators). Beim "Read" habe ich dann immer genau so viele Werte aus dem AI-Puffer gelesen, wie ich auch aus dem RAM der Heidenhain-Karte erhalten habe. Somit hatte ich zu jedem Winkelwert genau einen Momentenwert!

Hm...vielleicht ein bisschen Off-Topic...

Gruß
Achim