LabVIEWForum.de - Messfenster mit DAQmx?

LabVIEWForum.de

Normale Version: Messfenster mit DAQmx?
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hiho,

ist es möglich mit dem DAQ (ung geeigneter A/D hardware, in meinem Fall eine PCIe-6321) eine art "gegatete" Messung durchzuführen? Oder andersrum: Man kann alle möglichen Signale als Referenz-Trigger nutzen, aber wie genau sieht dabei die eigentliche Messung aus? Wird dabei genau 1 Sample mit der höchstmöglichen Samplerate aufgenommen (wenn der Trigger kommt) oder wird bis zum nächsten Triggersignal alles aufgenommen und gemittelt? Ich würde da gern die Kontrolle drüber haben, was das Timing angeht...

Beispielsweise eine Anweisung wie:
1. Warte auf Trigger (z.B. digitale Flanke)
2. Warte nach dem Trigger noch 30µs
3. Miss das Signal für 20µs
4. Warte auf den nächsten Trigger usw.

Man könnte natürlich mit der höchsten Samplerate einfach alles aufnehmen (inkl. dem Triggersignal, das dann an einen weiteren Analogeingang kommt) und dann eine Postprocessing-Routine schreiben, die genau das macht. Allerdings wäre das sicher sehr ineffizient und für zeitkritische Sachen wohl ungeeignet (weil in Software). Ich dachte das DAQmx ist recht schlau bei sowas, aber ich hab bislang keine Möglichkeit gefunden... Und noch viel schlimmer: ich weiß nicht welchen Teil des Signals er misst, wenn er einen externen Sample-Trigger bekommt (eine Software-Samplerate wird dabei ja ignoriert) - also ob er bis zum nächsten Triggerpuls mittelt oder nur ein "kurzes" Sample aufnimmt...
Du kannst mit den DAQVis soweit alles einstellen, sprich Samplerate, Anzahl der Samples usw.

Auch Triggersignale und anschließende Verzögerung bis zur Messung kann man vorgeben. Da müsste es aber im Examplefinder auch Beispiele für geben.

Grüßle
S.
Du sprichst vom Starttrigger, ich spreche vom Sampletrigger (oder auch Referenztrigger genannt)...
In meinem Fall misst ein Sensor einen Parameter mit ~10kHz und gibt den Messwert als Spannungslevel aus. Zwischen 2 Ereignissen liegen ~0.1ms und während dieser Zeit baut sich besagter Spannungslevel erst für ca. 30µs auf bis er dann "stabil" (konstant) bleibt bis die 0.1ms vorbei sind und die nächste Messung kommt.
Ich muss also ein "Fenster" messen, das wesentlich kürzer ist als die 0.1ms, mit einer Rate von ~10kHz.

Der Sensor gibt auch eine Triggerflanke (mit ~10kHz) aus, die den Moment definiert, wo die Messung fertig "aufgebaut" ist und gesamplet werden soll. Ein zusätzliches Triggerdelay ist daher erstmal nicht so wichtig, wäre nur gut zu wissen ob das geht. Wichtiger ist, dass genau in dem Moment wo der Trigger kommt für eine definierbare Zeit (Fenster) integriert bzw. mit der höchsten Rate gesamplet wird und sonst eben nicht.
Schließe ich das ~10kHz Triggersignal als Sample- (oder Referenz-) Trigger an, wird die Samplerate ignoriert (man gibt sie ja extern vor) und man kann ebenfalls kein Messfenster definieren. Ich habe den Verdacht, dass er dann einfach bis zum nächsten Triggerpuls (also die ganzen 0.1ms lang) mittelt und das macht die Messung natürlich wertlos.

Du sprichst offenbar davon, das Triggersignal (~10kHz) als Starttrigger zu benutzen - dann kann man natürlich eine Samplerate (z.B. 100kHz) und die Messdauer (als Anzahl der Samples geteilt durch Samplerate) definieren. Ich sehe es allerdings als problematisch, damit eine kontinuierliche (d.h. "lückenlose") Messung zu machen. Die Messung muss ja dann softwaremäßig in einer Schleife sofort immer wieder neugestartet werden, und zwar schnell genug bevor der nächste Triggerpuls kommt (zwischen Messfenster-Ende und dem nächsten Triggerpuls liegt nur ein Bruchteil der 0.1ms). Und die Daten müssen ja auch noch zumindest in ein Array o.ä. rauskopiert werden. Man müsste evtl. einen Triggercounter oder sowas mitlaufen lassen, damit man weiß ob und welche der Messungen ausgelassen wurden...
Hier hätte der Sampletrigger eben den Vorteil, dass sich die Hardware um alles kümmert (aber leider nicht ums Messfenster)..
Jupp, stimmt, ich meinte eher den Starttrigger, den anderen hab ich auch noch nicht benutzt.

Softwaremäßig ist es dann wohl tatsächlich so, dass das retriggern zu langsam ist, du also Daten verlierst. Wenn du dir die Daten als Waveform anzeigen lässt, weißt du ja welcher Abstand zwischen den einzelnen Messpunkten ist (dt). Dann könntest du bestimmen wieviele Messungen dir verloren gegangen sind. Oder du nimmst doch alle Daten auf und schmeißt anschließend die unwichtigen raus, je nachdem wie lang die Messung insgesamt dauert.
Ja, es wird wohl auf letzteres hinauslaufen - also kontinuierlich für ein paar Sekunden mit 125kS/s aufnehmen und gleich danach postprocessen. Das 10kHz Triggersignal (TTL) muss man aber ebenfalls aufnehmen (z.B. als digital in), um fürs postprocessen die genauen Zeiten für das echte Messsignal zu bekommen. Aus dem Messsignal selbst kann man das nämlich nicht zuverlässig ermitteln (z.B. wenn 2 aufeinanderfolgende Werte gleich oder sehr ähnlich sind) und ein festes delta-t ist nicht robust gegen kleine Schwankungen der 10kHz Messrate, die auftreten können...
Referenz-URLs