INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Problem mit schneller (!) Messung



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!

15.03.2011, 15:37
Beitrag #11

Kuki Offline
LVF-Neueinsteiger


Beiträge: 9
Registriert seit: Jun 2010

8.5
2009
de


Deutschland
RE: 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


Angehängte Datei(en)
8.5 .vi  FINAL_Mess-test-kontinuierlich_VÖ.vi (Größe: 91,69 KB / Downloads: 207)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
16.03.2011, 07:29
Beitrag #12

Achim Offline
*****
*****


Beiträge: 4.222
Registriert seit: Nov 2005

20xx
2000
EN

978xx
Deutschland
RE: Problem mit schneller (!) Messung
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

"Is there some mightier sage, of whom we have yet to learn?"

"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.03.2011, 10:17
Beitrag #13

Kuki Offline
LVF-Neueinsteiger


Beiträge: 9
Registriert seit: Jun 2010

8.5
2009
de


Deutschland
RE: Problem mit schneller (!) Messung
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.03.2011, 11:15 (Dieser Beitrag wurde zuletzt bearbeitet: 16.03.2011 11:46 von Lucki.)
Beitrag #14

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Problem mit schneller (!) Messung
(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?
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.03.2011, 11:37 (Dieser Beitrag wurde zuletzt bearbeitet: 16.03.2011 11:39 von Achim.)
Beitrag #15

Achim Offline
*****
*****


Beiträge: 4.222
Registriert seit: Nov 2005

20xx
2000
EN

978xx
Deutschland
RE: Problem mit schneller (!) Messung
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.

"Is there some mightier sage, of whom we have yet to learn?"

"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.03.2011, 12:04 (Dieser Beitrag wurde zuletzt bearbeitet: 16.03.2011 13:23 von Lucki.)
Beitrag #16

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Problem mit schneller (!) Messung
(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)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
16.03.2011, 12:26 (Dieser Beitrag wurde zuletzt bearbeitet: 16.03.2011 12:27 von Achim.)
Beitrag #17

Achim Offline
*****
*****


Beiträge: 4.222
Registriert seit: Nov 2005

20xx
2000
EN

978xx
Deutschland
RE: Problem mit schneller (!) Messung
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...

"Is there some mightier sage, of whom we have yet to learn?"

"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.03.2011, 13:52 (Dieser Beitrag wurde zuletzt bearbeitet: 16.03.2011 14:07 von Lucki.)
Beitrag #18

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Problem mit schneller (!) Messung
(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 Ahrg1
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.03.2011, 14:59
Beitrag #19

Kuki Offline
LVF-Neueinsteiger


Beiträge: 9
Registriert seit: Jun 2010

8.5
2009
de


Deutschland
RE: Problem mit schneller (!) Messung
(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!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.03.2011, 15:42 (Dieser Beitrag wurde zuletzt bearbeitet: 16.03.2011 15:42 von Achim.)
Beitrag #20

Achim Offline
*****
*****


Beiträge: 4.222
Registriert seit: Nov 2005

20xx
2000
EN

978xx
Deutschland
RE: Problem mit schneller (!) Messung
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

"Is there some mightier sage, of whom we have yet to learn?"

"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  DAQ-Assistant misst nicht schneller als 1 Hz. geo13 2 3.874 19.04.2013 14:03
Letzter Beitrag: geo13
  Vi Messung/Ausgabe schneller machen haipas 6 6.055 23.11.2010 09:03
Letzter Beitrag: haipas

Gehe zu: