Analoge Ausgabe - Puffer - DAQWrite

Hallo Jungs,

ich spiel grad ein bisschen mit AO (Regeneration aus, 50er Blöcke werden pro Zyklus geschrieben) rum. Folgendes kapier ich nicht: Das DAQ-Write VI fängt erst an zu warten, wenn der Kartenpuffer von 8191 Samples voll ist - vorher hab ich 'ne ungebremste Schleife. Das blöde ist dann, wenn ich meine Amplitude ändere, habe ich 8 Sekunden (1kHz Samplingrate) Verzögerung bis die neuen Werte am AO ankommen. Ist doch ziemlich unpraktisch, oder?

Wenn ich nun mit dem Metronom entsprechend selbst für das Warten sorge (50ms), reagiert der AO wie gewünscht instantan. Aber so richtig gefällt mir das auch nicht. Der Treiber hat das zu erledigen ...

Wenn ich die Wartezeit auf ein bisschen länger stelle als "nötig", bleibt der Wert "DAQmx Eigenschaft - AktSchreibPos" brav auf Null (gut!), aber der Treiber meckert natürlich direkt, dass er zu langsam Werte bekommt ... verständlich.
(EDIT: Bleibt auf Null, weil er sich der DAQ Treiber direkt verabschiedet - also doch nicht gut.)

Wie konfiguriere ich jetzt die ganze Geschichte, dass
1) der Treiber die Schleife bremst - wie das beim AI wunderbar funktioniert
2) der PC Pufferinhalt nicht kontinuierlich wächst
3) ich eine möglichst geringe Verzögerung habe?

   


Beste Grüße

Edit:
Mir ist aufgefallen, dass der AO selbst nach Beendigung des Tasks immernoch die zuletzt angegebene Spannung ausgibt. Daraufhin hab ich mein BD auf folgendes reduziert und schon scheint alles zu fluppen - ohne irgendwelche Puffer scheint mir.
   

Bin jetzt zu dem Schluss gekommen, dass die "DAQmx Eigenschaft - AktSchreibPos" kein Indikator dafür ist, dass sich Daten im RAM stauen. Ist einfach ne seltsame Info das Ding.

Ansonsten, um konstante Pegel instantan auszugeben, benutze ich die Variante 2 aus meinem ersten Posting, also "on Demand".

Die einzige Möglichkeit die Verzögerung beim blockweise-schreiben zu verkleinern, ist es die Sampling Rate zu erhöhen.

Warum macht Du überhaupt keinen Versuch, die Puffergröße enstprechend Deinen Bedürnissen einzustellen und beläßt sie im Modus "Auto"?
Hilefeanleitung zu DAQ Sample Takt --> Eingang "Samples pro Kanal" :

Samples pro Kanal gibt die Anzahl der an jedem Kanal im Task zu erfassenden bzw. generierenden Samples an, wenn der Sample-Modus auf Endliche Anzahl eingestellt ist. Wenn der Sample-Modus auf kontinuierlich eingestellt ist, verwendet NI-DAQmx diesen Wert zur Bestimmung der Puffergröße.

Danke für das Lebenszeichen Lucki. Immer blöd so Monologe.

(11.08.2011 09:55 )Lucki schrieb:  Warum macht Du überhaupt keinen Versuch, die Puffergröße enstprechend Deinen Bedürnissen einzustellen und beläßt sie im Modus "Auto"?
Hilefeanleitung zu DAQ Sample Takt --> Eingang "Samples pro Kanal" :

Samples pro Kanal gibt die Anzahl der an jedem Kanal im Task zu erfassenden bzw. generierenden Samples an, wenn der Sample-Modus auf Endliche Anzahl eingestellt ist. Wenn der Sample-Modus auf kontinuierlich eingestellt ist, verwendet NI-DAQmx diesen Wert zur Bestimmung der Puffergröße.

Soweit gilt das für Erfassungs-Tasks. Und selbst dort ist diese Vorgabe nur ein Mindestwert und LV behält sich das Recht vor, einen größeren Puffer zu erstellen, soforn die Vorgabe die Vorstellungen von NI unterbietet. Bei Ausgabe-Tasks hat dieser Wert wieder eine andere Bedeutung: "Gesamtanzahl der zu erzeugenden Samples"; siehe Anhang.
   

Alles Konfigurieren wird aber hier trotzdem nichts nutzen, denn die ganzen VIs und Einstellmöglichkeiten beziehen sich alle samt auf den Puffer im RAM. Was mir aber die unerwünschte Verzögerung beschert, ist der recht großzügige karteneigene Puffer der x-Serie (8191 Samples). An dem kann man nicht rumschrauben.

Zum Glück muss ich nur Pegel ausgeben (das funktioniert "on Demand" ganz toll) und das ganze wird so zu einer akademischen Diskussion. Sobalb man aber irgendwelche nicht-periodischen Figuren zaubern möchte und diese auch noch recht zügig am Ausgang anliegen haben möchte, steht man vor besagtem Problem.

Edit:
"DAQmx Eigenschaft - AktSchreibPos" = Anzahl an Samples die DAQwrite geschluckt hat
"DAQmx Eigenschaft - GesamtanzahlAusgegSampProKanal" = "DAQmx Eigenschaft - AktSchreibPos" minus Kartenpuffergröße
Eine Node, die zeigt wie viele Samples grad im RAM Puffer sind (fände ich viel interessanter), ist mir nicht über den Weg gelaufen ...

(11.08.2011 11:03 )dimitri84 schrieb:  Edit:

Eine Node, die zeigt wie viele Samples grad im RAM Puffer sind (fände ich viel interessanter), ist mir nicht über den Weg gelaufen ...

Moin Dimitri.

Wie sieht das mit den Eigentschaftsknoten für das DAQ aus? Wenn du unter "DAQ-schreiben" den Wert "Relativ zu" auf das erste Sample legst und dir nach dem Schreiben den Wert für "offset" ausgeben lässt, dann solltest du doch genau den gesuchten Wert haben. Zumindest habe ich das so verstanden.

Wenn du "on demand" nur mit dem WRITE Vi Werte ausgibst, dann wird das so nicht funktionieren. "Relativ-zu" muss initialisiert werden.

Gruß, Ralf

(12.08.2011 06:31 )RMR schrieb:  Wie sieht das mit den Eigentschaftsknoten für das DAQ aus? Wenn du unter "DAQ-schreiben" den Wert "Relativ zu" auf das erste Sample legst und dir nach dem Schreiben den Wert für "offset" ausgeben lässt, dann solltest du doch genau den gesuchten Wert haben. Zumindest habe ich das so verstanden.

Der Wert für Offset ändert sich nicht. Den gibt man selbst an oder lässt ihn auf Null und auf diesem Wert bleibt der auch während der Ausgabe. Da würd ich Finger von lassen. (Es geht hier um das Schreiben von NSamples, klar oder?)

Zitat:Wenn du "on demand" nur mit dem WRITE Vi Werte ausgibst, dann wird das so nicht funktionieren. "Relativ-zu" muss initialisiert werden.

Was funktioniert da nicht? Hast du das überhaupt ausprobiert?