19.10.2009, 06:58
Beitrag #1
|
Spark
LVF-Grünschnabel
Beiträge: 39
Registriert seit: Sep 2009
8.6
-
de
30159
Deutschland
|
Messwertaufnahmetakt exakt?
Hallo Forum,
ich frage mich gerade ob das was ich mir so überlegt habe, und derzeit auch anwende, exakt ist.
wenn ich mit den daqmx Bausteinen 100samples/sekunde aufnehme, und das ganze in eine Zeitgesteuerte Schleife (delta t 1000ms = 1sekunde) packe, würde ich damit jede sekunde / pro schleifendurchlauf genau 100samples abgreifen?!
reicht die zeitgesteuerte Schleife und der daqmx timer als synchronisation?
ohne die zeitgesteuerte schleife hatte ich den eindruck das da was unrund lief.
jetzt siehts besser aus, aber wenn ich mitte der woche an der anlage messe, sollte da doch möglichst ein fester, synchroner timecode /zeitintervall stehen.
lg spark
|
|
|
19.10.2009, 07:32
(Dieser Beitrag wurde zuletzt bearbeitet: 19.10.2009 07:52 von rolfk.)
Beitrag #2
|
rolfk
LVF-Guru
Beiträge: 2.305
Registriert seit: Jun 2007
alle seit 6.0
1992
EN
2901GG
Niederlande
|
Messwertaufnahmetakt exakt?
' schrieb:Hallo Forum,
ich frage mich gerade ob das was ich mir so überlegt habe, und derzeit auch anwende, exakt ist.
wenn ich mit den daqmx Bausteinen 100samples/sekunde aufnehme, und das ganze in eine Zeitgesteuerte Schleife (delta t 1000ms = 1sekunde) packe, würde ich damit jede sekunde / pro schleifendurchlauf genau 100samples abgreifen?!
reicht die zeitgesteuerte Schleife und der daqmx timer als synchronisation?
ohne die zeitgesteuerte schleife hatte ich den eindruck das da was unrund lief.
jetzt siehts besser aus, aber wenn ich mitte der woche an der anlage messe, sollte da doch möglichst ein fester, synchroner timecode /zeitintervall stehen.
lg spark
Persönlich halte ich dass immer so, dass ich die softwaregesteurte Schleife ein etwas kürzeres Interval gebe als die Datenacquisition selbst hat. Den Rest der Zeit wartet DAQmx Read, bis die gewünschten Daten verfügbar sind. Der DAQ Timer ist dann im Prinzip alleine verantwortlich für das exacte Timing und der ist allemal genauer dann der Softwaretimer im PC (Aber genauer heisst nicht perfekt. Auch der Quartzoszillator auf der DAQ Karte hat schnell einmal 200ppm maximale Abweichung. Wesentlich genauer geht halt nur mit temperaturgesteurten Oscillatoren und die können durchaus teurer werden dann die ganze DAQ Karte heute ist.)
Und hier kommt ein weiteres Problem. Viele denken dann, dass sie bei langdauerenden Datenerfassungen ein Timingproblem auf der DAQ-Karte haben weil die Anzahl erfassten Samples dividiert durch die Samplerate eine andere Zeit ergibt dann wenn man die Differenz zwischen der Anfangszeit und Endzeit der Erfassung von der PC Uhr nimmt. Grund dafür ist zu einem kleinen Teil diese Ungenauigkeit des Quartzoszillators auf der DAQ Karte, aber zum grössten Teil die Ungenauigkeit des PC Timers, der eigentlich mehr ein Schätzometer ist dann eine Uhr.
Rolf Kalbermatter
|
|
|
19.10.2009, 07:42
Beitrag #3
|
Y-P
☻ᴥᴥᴥ☻ᴥᴥᴥ☻
Beiträge: 12.612
Registriert seit: Feb 2006
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
|
Messwertaufnahmetakt exakt?
Mach's doch so.
DAQmx_Getaktet_einlesen.vi (Größe: 28,5 KB / Downloads: 235)
So kannst Du mit DAQmx getaktet einlesen. Du musst halt noch die Rate und Samples per Channel entsprechend einstellen.
Gruß Markus
--------------------------------------------------------------------------
Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
|
|
|
19.10.2009, 09:03
Beitrag #4
|
IchSelbst
LVF-Guru
Beiträge: 3.695
Registriert seit: Feb 2005
11, 14, 15, 17, 18
-
DE
97437
Deutschland
|
Messwertaufnahmetakt exakt?
Also ich sehe das so:
Der DaqMX hat immer Recht. Will sagen: Wenn eine Task eingestellt ist auf einen Takt von 1.000kHz, dann haben die einzelnen Samplepakete einen zeitlichen Abstand von 1.000ms. Die Ungenauigkeiten, von denen rolfk gesprochen hat, gibt es natürlicherweise. Da diese Ungenauigkeiten aber systemimmanent sind werden sie vernachlässigt.
Die Annahme, dass bei ein kHz nach genau einer Sekunden ganz oben auf der Applikationsebene genau tausend Samples vorliegen - ist zwar rechnerisch richtig, praktisch aber völlig irrelevant. Zwischen dem per se richtigen Raster quasi auf Hardwareebene und einer z.B. Anzeige auf Bildschirmebene liegen so viele Ebenen mit jeweils spezifischen Verzögerungen, dass es völlig unmöglich und somit unsinnig ist, innerhalb einer Sekunde genau 1000 Sample zu erwarten. Ein Programm sollte so aufgebaut sein, dass es völlig unerheblich ist, wie groß diese Zwischenverzögerungen sind. Letztendlich muss zu einem bestimmten Zeitpunkt die Historie, nicht der Zustand zu genau diesem Zeitpunkt, konsistent sein.
Wichtig ist doch lediglich, dass irgendwann mal Daten im gewünschten Raster vorliegen. Dabei spielt die absolute Zeit für dieses Vorliegen keine Rolle. Wichtig ist nur, dass zu jedem Zeitpunkt die absolute Ungenauigkeit in der Anzahl der Messwerte einen bestimmten Wert nicht überschreitet. (Ob nach 10 Sekunden oder nach 10 Stunden, es darf lediglich eine Abweichung von z.B. 20 Samples bestehen. Diese Differenzanzahl resultiert aus den oben erwähnten Verzögerugen.)
Das praktische Problem ergibt sich dann aber doch zu dem Zeitpunkt, an dem z.B. der DaqMX ausgelesen werden soll. Wenn ich den DaqMX alle Sekunde (resultierend z.B. aus einem Metronom) auslese, muss ich halt meinen nachfolgenden Algorithmus so schreiben, dass es unerheblich ist, ob ich 990 oder 1100 Sample auslese. Oder ich schließe an den DaqMX-Rd eine feste Zahl (also 1000) an. Einmal habe ich eine feste Zeit, aber eine ungewisse Anzahl von Samples. Einmal eine feste Anzahl von Samples, aber eine ungewisse Zeit. Mit beiden kann ich leben.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
|
|
|
19.10.2009, 12:54
Beitrag #5
|
Spark
LVF-Grünschnabel
Beiträge: 39
Registriert seit: Sep 2009
8.6
-
de
30159
Deutschland
|
Messwertaufnahmetakt exakt?
danke euch vielmals!
mfg spark
|
|
|
| |