Task verschwindet bei Fensterwechsel im SoundVI

Na da bin ich ja schonmal froh dass das nicht nur bei mir auftritt so,
ich dachte nämlich schon an ein rechnerspezifisches Problem.

Ich werde das SoundVI dann mal lieber nicht mehr so nutzen..
Ich habe aktuell einen Baustein eingesetzt aus LV 7.1 mit dem ich das
mache, der ist aber nicht so komfortabel wie dies neue hier, da man
nicht die Möglichkeit hat den Continuous laufen zu lassen. Den muss
man also jeden Schleifendurchlauf wieder neu anstoßen, ABER der läuft
zu 100% stabil.

Und das hier bei euch jetzt der Fehler auch auftritt ist in sofern gut, da ihr
ja garantiert auch fast tagtäglich mit DAQ arbeitet (auch Tasks) und
die Sachen ja sicherlich nicht alle 2 Minuten abschmieren, was jetzt
dann bei mir auch wohl nicht auftreten wird.

Das beruhigt mich schon ziemlich!

Trotzdem bin ich für die ein oder andere Idee zu diesem Soundproblem
noch dankbar, weils das kanns ja irgendwie auch nicht sein, dass man
das nicht stabil lauffähig bekommt...

mfG
Robert

' schrieb:Trotzdem bin ich für die ein oder andere Idee zu diesem Soundproblem
noch dankbar, weils das kanns ja irgendwie auch nicht sein, dass man
das nicht stabil lauffähig bekommt...

Also, der Fehler 4823 tritt auf, wenn der Task nicht mehr aktiv ist.
Der Task ist z.Bsp nicht mehr aktiv, wenn der Input Buffer überläuft.
Typische Ursache dafür, wenn die Daten nicht schnell genug aus dem Buffer gelesen werden.

Im Glühbirnnenmodus, kann das durchaus sein

' schrieb:Also, der Fehler 4823 tritt auf, wenn der Task nicht mehr aktiv ist.
Der Task ist z.Bsp nicht mehr aktiv, wenn der Input Buffer überläuft.
Typische Ursache dafür, wenn die Daten nicht schnell genug aus dem Buffer gelesen werden.

Im Glühbirnnenmodus, kann das durchaus sein

Guten Morgen,
dabei verstehe ich aber eines nicht.
Wie kann es denn sein, dass der Input Buffer einen Überlauf hat?
Ich habe doch genau festgelegt, wie viele Samples mit welcher
Taktfrequenz eingelesen werden sollen.

Das darauf folgende Samplen wird doch erst ausgeführt, wenn der
restliche Programmteil abgearbeitet wurde. Wie spielt denn da die
Geschwindigkeit eine Rolle? Auch im Highlightmodus muss ja der eigentliche
Einleseprozess doch die gleiche Geschwindigkeit haben wie bei normaler
Ausführung.

So wie Jens geschrieben hatte tritt das ja auch auf bei einer Schleifenverzögerung
von beispielsweise 1s. Wenn ich aber eingelesen habe, liegt das halt ne Sekunde
im Puffer, beim nächsten Durchlauf wird dann halt der Puffer geleert und es kommt
was neues rein..

Sorry für die blöden Fragen, aber mir leuchtet das nicht ein.

mfG
Robert

' schrieb:Wie kann es denn sein, dass der Input Buffer einen Überlauf hat?
Ich habe doch genau festgelegt, wie viele Samples mit welcher
Taktfrequenz eingelesen werden sollen.

Wenn du die Anzahl Sample/ch grösser machst, wird der Buffer grösser.
Mit dem Sound Input Configure.vi sagst du, schreibe alles was vom Micro kommt in den Buffer.
Wenn jetzt der Buffer zu klein ist, und du nicht schnell genug aus dem Buffer die Daten ausliest, mit dem SoundInputRead , wird er überlaufen.
Das ist beim DAQ in etwa das selbe.

' schrieb:Wenn du die Anzahl Sample/ch grösser machst, wird der Buffer grösser.
Mit dem Sound Input Configure.vi sagst du, schreibe alles was vom Micro kommt in den Buffer.
Wenn jetzt der Buffer zu klein ist, und du nicht schnell genug aus dem Buffer die Daten ausliest, mit dem SoundInputRead , wird er überlaufen.
Das ist beim DAQ in etwa das selbe.

Hmm ok, habe ich denn die Möglichkeit den Buffer
zu vergrößern um das System stabil zu machen?