Unstetiger Sinus Verlauf mit Analoger Eingabekarte

Hallo zusammen!

Ich arbeite mit LabVIEW 7.1 und der analogen Eingabekarte ACPI-3001 von Addi-Data, die maximal 100kS schafft. Der PC läuft mit 3GHz und hat 1GB Ram.

Nun möchte ich kontinuierlich Spannungswerte einlesen, die momentan noch nicht vom Prüfstand, sondern zum Test von einem Funktionsgenerator stammen.
Es sollen Sinus - Signale sein mit einer Frequenz von etwa 30Hz, mit 60 Messwerten pro Periode macht das etwa 2000 Messwerte pro Sekunde.

Momentan benutze ich eine Funktion "Read1AnalogInput", die in einer For-Schleife etwa 10.000 mal ausgeführt wird. Die Messwerte werden in einem Signalverlaufs-Diagramm angezeigt.

Nur weist dieses Diagramm in regelmäßigen Abständen Unstetigkeiten auf, das heißt ich bekomme etwa 100-150 Werte am Stück und dann fehlen einige und die Kurve beginnt am nächsten Messpunkt ein Stück höher oder niedriger, je nachdem in welcher Phase sich der Sinus befindet.

Meine Theorie darüber ist, dass die Karte die Daten im internen Speicher ablegt, LabVIEW die Daten nicht schnell genug ausliest und deswegen der Puffer geleert wird und erst beim Neubeschreiben neue Messwerte in den PC-RAM übermittelt werden

Was gäbe es für möglichste einfache / elegante Varianten, dies zu unterdrücken?

Danke für die Hilfe!

Mfg
mAcRiX

Anzeige

Die Karte sagt mir nichts, jedoch gehe ich davon aus, dass die DMA kann.
Somit ist Sie CPU unabhaengig was die Uebertragung vom FIFO der Karte in den RAM angeht.
Problem besteht nun in LV, dass es sich die Daten vom vordefinierten Bereich im RAM die Werte abholen muss und in den "LV-Speicherbereich im RAM" verschiebt.

Folgende theoretischen Sachen koennten Fruechte tragen:
- Empfangsbuffer um das x-fache erhoehen
- Evtl. mit der Option Defer Front Panel Updates arbeiten

Problem bei Graphen ist, dass das FP komplett neu gezeichnet werden muss - hier solltest dir evtl. ueberlegen, ob es net ausreicht, wenn das FP nur alle 2 oder 3 Iterationen upgedatet wird.
Dazu kommt noch, dass das Diagramm eine "stark" endliche Anzahl an Werte speichern bzw. aufnehmen kann - evtl. waere an dieser Stelle eine offline Datensichtung noch besser.

Danke für die schnelle Antwort!

Ja, die Karte unterstützt DMA.

Zu 2.
Wie könnte ich die Daten möglichst ohne Umwege vom FIFO in eine lesbare Datei schreiben, so dass ich überprüfen kann, ob vielleicht das Diagramm das Problem darstellt?
In LV müsste ich doch dann einen Array verwenden, der wiederum Verschiebungen im Speicher zur Folge hätte.

Zu 1.
Welchen Empfangsbuffer meinst du?
Den im RAM, in dem die Werte vom FIFO kommen? Hat das dann etwas mit DMA zu tun? Und könnte ich die Daten vielleicht packetweise übermitteln, wenn der FIFO voll ist, vielleicht über eine Interruptsteuerung?

Mfg
mAcRiX

wenn die Karte DMA unterstuetzt, kann sie auch auf alle Faelle IRQ, die Frage ist nur, wie du diesen aktivierst.
Bei NI Karten kannst du relativ einfach die Anzahl der Werte im FIFO abfragen und dann spezifiziert uebertragen...
Die Karte transferiert per DMA die Werte in einen vordefinierten Bereich im RAM, der von LV gelesen wird (aber nicht beschrieben werden kann!)
Du kannst dir relativ einfach per disk-streaming die werte in eine Datei schreiben.
vor der schleife die Referenz auf die Datei oeffnen -> innerhalb der Schleife nur schreiben und nachdem die Schleife feddich ist die Referenz wieder schließen.

Wenn du ein Array vorinitialisierst und immer Teilarrays ersetzt, greifst du immer auf den gleichen Speicherbereich zurueck, sprich du machst keine Spiegelung oder sonstiges...

Ok, danke!

Dann werde ich es morgen gleich mal ausprobieren, wenn ich wieder in der Uni bin.

Zuerst werde ich versuchen, die Daten ohne Diagramm in eine Datei umzuleiten;
falls das keine Besserung bringt, werde ich mich an die blockweise Übertragung der Daten per DMA ranmachen!

Mfg
mAcRiX

aem bevor du auf IRQ umsteigst solltest evtl. noch etwas effektiveres ausprobieren -> hol groeßere Pakete im RAM ab, net direkt am FIFO!
Sprich, Emfpangsbuffer im RAM groeßer machen (x-fach der abgeholten Paketgroeßen) und dadurch hoehere Effektivitaet rein zu bringen.

wenn ich das in Post Nummer 1 richtig gelesen hab, dann benutzt du eine Funktion "Read1AnalogInput" und die läßt du in einer for Schleife laufen.

es ist nur eine Vermutung, aber ich vermute, dass Read1AnalogInput sowas wie EINEN Messwert erfassen bedeutet. Konkret: die Karte wird initialisiert, der Messwert wird aufgenommen, die Karte wird deinitialisiert. Und das machst du in einer For-Schleife 10.000 mal ... das quasi eine sofware-getimte erfassung, und es wundert mich nicht dass das hakt ...

Ich vermute, dass die Aussetzter daher kommen, dass Windows grade Zeit für irgendetwas anderes beansprucht und dein Programm halt eben mal warten muss.

Ich vermute auch stark, dass du keine "wait for next millisecond multiple" in deiner for-schleife hast? und ich vermute, dass deine Systemlast während der Erfassung auf 100% steht?

Wenn ich mit meiner Vermutung richtig liege, dann gibt es folgendes zur Abhilfe: lies dir das Handbuch deiner Messkarte durch und programmiere eine kontinuierliche Messdatenerfassung. Bei DAQmx ginge das ungefähr so: task anlegen, kanäle hinzufügen, samplerate auf z.B. 2000 Hz, continuierliche Datenerfassung, task starten, in einer while schleife softwaregetaktet die messwerte z.B. in 100 Samples blöcken abholen (= hardware-getimed), irgendwann schleife beenden, erfassung stoppen, task schließen.

vielleicht gibt es ja auf der Homepage des Herstelles ein Beispiel?

Grüße
CB

das mit 1 wert daacht ich mir am anfang auch, jedoch passt dann diese zeile absolut nicht dazu:

Zitat:Nur weist dieses Diagramm in regelmäßigen Abständen Unstetigkeiten auf, das heißt ich bekomme etwa 100-150 Werte am Stück und dann fehlen einige und die Kurve beginnt am nächsten Messpunkt ein Stück höher oder niedriger, je nachdem in welcher Phase sich der Sinus befindet.

freedive schrieb:das mit 1 wert daacht ich mir am anfang auch, jedoch passt dann diese zeile absolut nicht dazu:

Zitat:Nur weist dieses Diagramm in regelmäßigen Abständen Unstetigkeiten auf, das heißt ich bekomme etwa 100-150 Werte am Stück und dann fehlen einige und die Kurve beginnt am nächsten Messpunkt ein Stück höher oder niedriger, je nachdem in welcher Phase sich der Sinus befindet.

genau deswegen hatte ich die Vermutung: für einen bestimmten Zeitraum hat LabVIEW die höchste Priorität und sampelt mit der SinglePoint funktion, so schnell es kann. Dann gibt Windows einem anderen Thread die Prio und das Sampling wird so lange ausgesetzt, bis LabVIEW wieder Prio 1 hat. Da der reale Sinuns in der Zeit natürlich "weiterläuft", sieht man einen Absatz, weil man quasi eine "Sample-Pause" macht.

was aber per dma net passieren kann, weil er bei einem overflow sofort meckern wuerde...