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!
ich benutze eine PCI-6123 um analog Spannung zu messen.
Ich messe dabei 6123/Ai0:7 mit einer Frequenz von 20kHz.
Danach benutze ich das WritetoSpreadheet.vi um die Daten abzuspeichern.
Wenn ich das ganze zur vereinfachung mit einer Virtual6123 mache, dann sehe ich, dass ich immer wieder Werte aufnehme, die nicht zu der eigentlichen Sinuskurve passen und dass in mehr oder weniger großen Abständen. Daher meine Frage:
Wann spuckt die Karten Nullen aus? Wenn der Speicher schneller abgefragt wird, als neue Daten gemessen wurden? Hoffe, mein Problem ist einigermaßen verständlich und würde mich über Ratschläge wirklich sehr freuen.
Im Normalfalle macht die simulierte Karte wie auch die physikalisch-vorhandene alles richtig. D.h. solche Nullen, wie du bekommst, können nicht von funktionierenden Karte/Simulation kommen.
Zitat:Wenn der Speicher schneller abgefragt wird, als neue Daten gemessen wurden?
Dann liefert die Task (also nicht die Karte/Simulation) ein leeres Array, aber keinen Nuller-Wert.
Ich tippe auf ein leeres Array - das du natürlich richtig weiter verarbeiten musst.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Im Normalfalle macht die simulierte Karte wie auch die physikalisch-vorhandene alles richtig. D.h. solche Nullen, wie du bekommst, können nicht von funktionierenden Karte/Simulation kommen.
Dann liefert die Task (also nicht die Karte/Simulation) ein leeres Array, aber keinen Nuller-Wert.
Ich tippe auf ein leeres Array - das du natürlich richtig weiter verarbeiten musst.
Erstmal vielen Dank.
Dann weiter gefragt:
Wann liefert eine Task, die an eine virtuelle Karte angeschlossen ist, anstatt von Messwerten Nullen zurück? was könnte ich da falsch gemacht haben?
Diesen Gedanken, dass ich (also du) was falsch gemacht haben, würde ich gar nicht so verfolgen.
Ich würde es eher als gegeben hinnehmen, dass bei der Task auch leere Array herauskommen können und meinen Algorithmus entsprechend anpassen. Ich hab das nämlich genau so gehabt: Ein Kundenrechner war wohl etwas komisch und hat gelegentlich, obwohl die Abtastrate mit 1kHz weit über dem Bearbeitungsraster von 50ms liegt, manchmal leere Arrays geliefert.
Wenn beim Simulator Nuller-Werte herauskommen, tippe ich auf einen Fehler in deinem Programm. Dass hier der MAX einen "Fehler" macht, ist zwar denkbar, das schließe ich aber aus. Bei einer physikalisch vorhandenen Karte kann ein leeres Array herauskommen, weil eben aus unerfindlichen Gründen die MAX-Task in der Rasterzeit von 50ms noch nichts neues auf die Reihe gebracht hat. Das liegt dann aber eher an der Rechner-HW/SW. Ob hier eine Neuinstallation des MAX was bringt, ist ungewiss.
Kannst du mal das VI, von dem die oben das FP gepostet hast, hier einstellen? Dann sieht man, wie du das mit der Task gemacht hast, und ob da was optimiert werden kann.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Erstmal vielen Dank.
Dann weiter gefragt:
Wann liefert eine Task, die an eine virtuelle Karte angeschlossen ist, anstatt von Messwerten Nullen zurück? was könnte ich da falsch gemacht haben?
wenn es eine simulierte Karte ist würde ich auf 2 Möglichkeiten Tippen:
- du läßt deine Erfassung durch die Hardware timen und hast kein "wait for next ms multiple" in der Schleife, das ist zwar in Verbindung mit Hardware-Timing genau richtig, ich hab aber schon beobachtet, dass ältere DAQmx-Versionen damit ein Problem haben und die Schleife ungebremst läuft => dann kann es schonmal vorkommen, dass der Treiber "durcheinander" kommt ...
- es ist tatsächlich ein Bug in dem Code der die Messwerte Simuliert
wenn es eine "echte" Karte ist kann es sein, dass dein Rechner ausgelastet ist? Ich hatte schonmal das Vergnügen mit einer 6602, die bei einem relativ stark ausgelasteten PXI nämlich KEINEN Timeout-Fehler zurückgegeben hat, sondern nur ein leeres Array (bei einer Encoder-Messung) ... das war ein Spass diesen Bug zu finden ...
ich muss erstmal mit meinem Betreuer sprechen, ob ich das VI online stellen darf.
Zitat:- du läßt deine Erfassung durch die Hardware timen und hast kein "wait for next ms multiple" in der Schleife, das ist zwar in Verbindung mit Hardware-Timing genau richtig, ich hab aber schon beobachtet, dass ältere DAQmx-Versionen damit ein Problem haben und die Schleife ungebremst läuft => dann kann es schonmal vorkommen, dass der Treiber "durcheinander" kommt ...
Zitat:wenn es eine "echte" Karte ist kann es sein, dass dein Rechner ausgelastet ist?
Das habe ich wirklich nicht drin. Meine While-Schlife läuft so schnell sie kann. Das Problem kann sein, dass ich in der While-Schleife noch andere Dinge mache, z.B. die Waveforms untereinander zu subtrahieren und in nem File abzuspeichern. Evtl. lastet das den Rechner zu sehr aus, das erklärt trotzdem nicht, warum da Nullen stehen. Ich hätte es verstanden, wenn da Lücken wären, wo überhaupt nichts steht... Ich habe in meinem Rechner eine 6123 und eine 6143 die über RTSI gekoppelt sind, der Fehler tritt (meiner Meinung nach) sowohl bei den virtuellen als auch bei den echten Karten auf, wobei sich das bei den echten Karten nicht so schön sehen lässt. Bei den Virtuellen fällt das halt eher auf, wenn in der Sinuskurve so Hänger drin sind
Ansonsten hätte ich noch eine allgemeine Frage an euch:
Die NI-Examples zum Thema Daten aufnehmen setzen das DAQMx Read.vi immer in eine While-Schleife. Macht ihr das auch so, oder benutzt ihr einen Timed Loop?
Und noch etwas (ich hoffe ihr seid noch nicht genervt ). Wenn ich mir den Speicher, den mein Programm beim laufen belegt im Task-Manager anschaue, dann sehe ich, dass der belegte Speicherplatz während der Aufnahme immer größer wird. Allerdings wird er bei Beenden des Programms nicht geleert sondern erst, wenn ich LabVIEW komplett beende. Dabei habe ich hinter alle Tasks ein Clear Task gesetzt.
Gibt es sowas wie eine "Mach den Speicher frei".vi?
' schrieb:ich muss erstmal mit meinem Betreuer sprechen, ob ich das VI online stellen darf.
Tue dies. Ohne VI ist die Hilfe schwierig.
Zitat:Die NI-Examples zum Thema Daten aufnehmen setzen das DAQMx Read.vi immer in eine While-Schleife. Macht ihr das auch so, oder benutzt ihr einen Timed Loop?
Ich verwende nur Reads in normalen While-Schleifen mit eigenem 50ms-Wait.
Zitat:Wenn ich mir den Speicher, den mein Programm beim laufen belegt im Task-Manager anschaue, dann sehe ich, dass der belegte Speicherplatz während der Aufnahme immer größer wird. Allerdings wird er bei Beenden des Programms nicht geleert sondern erst, wenn ich LabVIEW komplett beende. Dabei habe ich hinter alle Tasks ein Clear Task gesetzt.
Das sieht sehr nach Fehler bzw. unglücklich gewähltem Algorithmus im Programm aus.
Zitat:Gibt es sowas wie eine "Mach den Speicher frei".vi?
Gibt es. Ob das hier was nützt, möchte ich bezweifeln.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
19.02.2009, 13:36 (Dieser Beitrag wurde zuletzt bearbeitet: 20.02.2009 20:26 von jg.)
Mich würde vor allem wirklich interessieren, warum der Speicher immer voller wird...
Das kann ich Dir sagen ohne das VI zu sehen. Ein in 99 von 100 Fällen zu beobachtender Anfängerfehler ist nämlich die Einfügung einer Wait-Funktion in die While-Schleife für DAQmxRead.
Das ist fast immer falsch, denn DAQmxRead wartet von selbst, bis die voreingestellt Anzahl von Daten im Buffer sind, und synchronisiert damit Schleife und Datenerfassung.
Aber z. B. bei einem Wait von 10ms, Aulesen von nur 1 Sample ist die Entleerungsrate aus dem Buffer 100Hz. Wenn die Samplerate der Karte höher ist, dann füllt sich der Buffer immer mehr.
Zum Ausgangsthema: Nullen. bzw. Lerre Arrays werden von DAQmrRead eigentlich nur bei Timeout übergeben. Schließe doch da mal eine Probe an, um zu sehen, ob es diesen Fehler gibt.