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!
20.02.2009, 11:19 (Dieser Beitrag wurde zuletzt bearbeitet: 20.02.2009 11:22 von Toste.)
' schrieb: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.
Schau bitte mal in meine VI, da ist keine Wait drin
' schrieb: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.
Also bei Timeout kommt doch normalerweise diese Fehlermeldung: -200279:
Measurements: Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.
Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.
' schrieb:Schau bitte mal in meine VI, da ist keine Wait drin
Also bei Timeout kommt doch normalerweise diese Fehlermeldung: -200279:
Ja schon, aber die Frage ist ob die Fehlermeldung angezeigt wird oder nicht. Sie wird angezeigt, wenn an dem betreffenden VI der Fehlerdraht nicht angeschlossen ist. Bei Dir ist aber ein Draht dran, und der Fehler wird nicht ausgewertet (Bzw. erst nach Stop) . Der Fehlerdraht läuft am rechten Schleifenrand in Leere, solang die Schleife nicht beendet wird.
So wie Du würde ich es nie machen, das ist genau der Fall, wo ein Wartefunktion sinnvoll wäre:
Bei jedem Durchlauf wird der Buffer geleert, das wird jedesmal eine etwas unterschiedliche Anzahl sein, und die Schleife dreht sich mit maximaler Geschwindigkeit.
Daß der Buffer überläuft kann so so nicht sein Es sei denn: Das DAQmxRead gibt einen Fehler aus (Den Du hier gar nicht bemerken würdest).
Die bessere Methode ist: Sampleanzahl vorgeben, die auszulesen ist (am DAQmxRead, nicht am SanpleClock!) . Vom Visuellen her genügt es, wenn die Diagramme mit 5 Hz upgedated werden. D.H bei 20kHz Samplerate imme 4000 Samples auf einmal lesen.
Also: Unmittelbar am Fehlerausgang von DAQmxRead mal einen Probe oder Anzeige anzuschließen lohnt sich auf alle Fälle!
Was mir noch auffällt: Warum verknüpfst Du die beiden Arrays nicht einfach mit der Funktion "Array erstellen (Eingäng verknüpfen"
Und noch was: So wie Du es machst, gibt es keine Garantie, daß die Anzahl der gelesenen Samples in beiden Karten immer gleich ist. (Es gibt keinen gemeinsamen Mastertakt) Die Anzahl wird ab und zu um 1 unterscheidlich sein. Wenn dann daraus ein einheitliches Waveform-Array gemacht wird, dann muß LabVIEW improvisieren. Vielleicht sieht das Ergebnis dann mit Deinen komischen Nullstellen genau so aus.
Was sich auch noch gut macht, wenn in einer Schlaufe gelesen wird, den Errorcluster in ein Shiftregister zu machen, und die Schlaufe zu beenden bei Fehler.
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
' schrieb:Weil die Historenlänge auf 1024 steht. Stell sie auf 10 (siehe im Kontextmenü des Graphen) und der Speicher hört sofort auf voller zu werden.
Und bevor du dich um den volllaufenden Speicher kümmerst, solltest du das Samplen und Anzeigen so umstellen, wie von Lucki beschrieben.
Das Refreshen des Graphen sollte nicht schneller als 250ms sein. Wenn du den Graphen schneller mit neuen Daten beaufschlagst, als er sie verarbeiten kann, treten plötzlich Lücken auf, die genauso plötzlich verschwinden, wenn das Programm beendet wird.
Hinweis:
Ich hab's ausprobiert, mit dem Simulator.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Erstmal wieder vielen Dank für eure Antworten! Schön, dass ihr euch für mein Problem Zeit nehmt!
Allerdings stehe ich, was die Umsetzung eurer Vorschläge angeht ziemlich auf dem Schlauch
a) Fehlermanagment: Okay, das habe ich in die Schleife verlagert
b) Anzahl Samples am DAQmxRead: Ich soll also an die Sample Clock eine Rate von 20000 anschließen und an die DAQmxRead 4000. Wenn ich das mache, dann werden die Lücken in meiner Aufnahme noch größer bzw. die Messung bricht ab und produziert Fehler-200279. Soll ich jetzt da ein Metronom in die Schleife machen oder nicht und wenn ja, wie lange (ms) sollte die Wartezeit sein?
c) Master Timebase: Okay, ich habe mich am Beispiel das geändert und jetzt bricht die Messung nach kürzester Zeit mit Fehler -200278 ab: Measurements: Attempted to read a sample beyond the final sample acquired. The acquisition has stopped, therefore the sample specified by the combination of position and offset will never be available. Die Beispiel selbst funktioniert einwandfrei. Ich bin jetzt ziemlich gefrustet, weil ich zwischen meiner VI und dem Beispiel keinen Unterschied sehe. Was mache ich denn falsch?
Im Anhang
testinloop8.2.rar (Größe: 81,7 KB / Downloads: 157)
(LV 8.2) ist jetzt mal die aktuelle Version, bei der ich versucht habe, die Synchronisation zu implementieren. Würde mich freuen, wenn ihr da nochmal drüber schauen könntet
Ha, jetzt hab ich einfach das Beispiel genommen und abgeändert und schon gehts. Vielen Dank für eure Vorschläge . Würde mich trotzdem interessieren, warum das obige VI abgestürzt ist, mein neues sieht genauso aus und geht
Habe jetzt keine Zeit, das genau zu analysieren. Wenn mehrere Karten mitreinander synchronisiert werden sollen, dann brauchst Du eine direkte Kabelverbindung zwischen den Karten. Hast Du dieses Teil überhaupt?
Außerdem: Der Rat, einen gemeinsamen Masterclock für die Karten zu haben, war nicht ganz richtig. Daruf kommt es gar nicht an, denn die Slavekarte sollte überhaupt keinen eigenen Sampletakt vewenden. Die Karten müssen synchron gestartet werden. Du hast das versucht, ich denke aber, daß es so nicht funktioniert Der Sampletakt selbst sollte von der Slavekarte gar nicht selbst erzeugt werden, sondern sollte von der Masterkarte kommen. Das Starten funktioniert dann so: Es wird zuerst der Slave gestartet, der wartet aber erst mal nur auf den Sampletakt der Masterkarte. Wenn dann der Master gestartet wird, läuft der Slave genau synchron zum Master.
Schau Dich mal in diesen Beispielen genau um:
Signalerfassung mit Hardware - DAQmx - Synchronisation - Mehrere Geräte.
Es ist nicht ganz einfach. Am besten kommst Du, wenn Du das geeignetste Beispiel suchst, keine gewagten Alleingänge machst, sondern Dich höllisch genau an die Vorlage hälst.
' schrieb:Habe jetzt keine Zeit, das genau zu analysieren. Wenn mehrere Karten mitreinander synchronisiert werden sollen, dann brauchst Du eine direkte Kabelverbindung zwischen den Karten. Hast Du dieses Teil überhaupt?
Außerdem: Der Rat, einen gemeinsamen Masterclock für die Karten zu haben, war nicht ganz richtig. Daruf kommt es gar nicht an, denn die Slavekarte sollte überhaupt keinen eigenen Sampletakt vewenden. Die Karten müssen synchron gestartet werden. Du hast das versucht, ich denke aber, daß es so nicht funktioniert Der Sampletakt selbst sollte von der Slavekarte gar nicht selbst erzeugt werden, sondern sollte von der Masterkarte kommen. Das Starten funktioniert dann so: Es wird zuerst der Slave gestartet, der wartet aber erst mal nur auf den Sampletakt der Masterkarte. Wenn dann der Master gestartet wird, läuft der Slave genau synchron zum Master.
Schau Dich mal in diesen Beispielen genau um:
Signalerfassung mit Hardware - DAQmx - Synchronisation - Mehrere Geräte.
Es ist nicht ganz einfach. Am besten kommst Du, wenn Du das geeignetste Beispiel suchst, keine gewagten Alleingänge machst, sondern Dich höllisch genau an die Vorlage hälst.
Hi Lucki,
ja, ich habe ein RTSI Kabel.
Ich habe für meine Version das Beispiel Multi-Device Synch-Analog Input-Cont Acquisition verwendet und da ausserhalb der While-Schleife nichts verändert. Wenn da jetzt noch etwas falsch ist, dann ist auch das Beispiel falsch.
Das mit dem Aufnehmen funktioniert soweit gut - dafür klappt (wie sollte es anders sein) ein anderer Teil meines Programmes jetzt nicht mehr.
Ich gebe während des Programms nach dem Klick des Benutzers eine Digitale Waveform aus. Als Clock Source benutze ich dabei den Counter der Karte 6123. Seitdem ich die Karten über die Timebase gekoppelt habe, wird die Task zwar gestartet, es wird aber nichts mehr ausgegeben - mal schaun, woran das liegt. Falls ichs nicht alleine hinbekomme, behellige ich euch nochmal mit dem Problem
. Würde mich trotzdem interessieren, warum das obige VI abgestürzt ist, mein neues sieht genauso aus und geht