kontinuierliches Schreiben mit Regeneration

Hallo Zusammen,

ich möchte gerne mit der cDAQ Signale mit einer kontinuierlichen Samplerate schreiben.

Allgemein funktioniert es auch prima, wenn die Zykluszeit annähernd stabil läuft. Jedoch musste ich feststellen, dass ich innerhalb von 12h mindestes einen erheblichen Ausreißer drin ist und meinen effektiven FIFO-Buffer von 20 Sample aufbraucht. Bei kleineren Ausreisern der Zykluszeit kompensiere ich es, indem ich zusätzliche Arrayelemente in den Buffer schreibe, um wieder meine gewünschte Buffergröße zu erreichen. Vorher verwendete keine Regeneration, um möglichst schnell reagieren zu können.

Da ich mit meinem Schreibsignal innerhalb von 200 ms reagieren möchte und trotzdem Ausreißer bis zu 900ms wegpuffern möchte, darf die Differenz zwischen aktueller Schreibposition und Anzahl der generierten Samples nicht zu groß und nicht zu klein sein.

Aus diesem Grund möchte ich gerne die Regenerationsmethode verwenden. Jedoch macht diese Methode den Buffer voll, womit die Differenz zwischen aktueller Schreibposition und Anzahl der generierten Samples weit über 1000 geht. Dadurch vergrößert sich meine Reaktionszeit.

Mein Wunsch wäre es, wenn ich mithilfe der Regenerationsmethode den Buffer nie leer laufen lassen kann, jedoch meine Sollgröße von 20 Samples nicht wesentlich überschreite. Im Falle einer automatischen Auffüllung soll immer mit dem letzten Wert aufgefüllt werden.

Geht das überhaupt mit der NI-cDAQ 9188 und wenn ja was müsste ich tun?

Danke im Voraus und viele Grüße
Christian

Anzeige

Hallo Christian,

Zitat:llgemein funktioniert es auch prima, wenn die Zykluszeit annähernd stabil läuft. Jedoch musste ich feststellen, dass ich innerhalb von 12h mindestes einen erheblichen Ausreißer drin ist und meinen effektiven FIFO-Buffer von 20 Sample aufbraucht. Bei kleineren Ausreisern der Zykluszeit kompensiere ich es, indem ich zusätzliche Arrayelemente in den Buffer schreibe, um wieder meine gewünschte Buffergröße zu erreichen. Vorher verwendete keine Regeneration, um möglichst schnell reagieren zu können.

Allgemeine Anmerkung: Wenn du Realtime-Fähigkeiten velangst, solltest du auch ein Realtime-Target verwenden. Windows sichert keine Realtime-Fähigkeiten zu…

Ansonsten:
- Wozu die zusätzliche Wartezeit in der Schleife? Üblicherweise sollte man das Timing den DAQmx-Funktionen überlassen.
- Warum die Angabe "1 Sample" am DAQmxTiming? Hast du die Hilfe zur Funktion gelesen, und insbesondere darauf geachtet, was eben dieser Wert im "Continuous"-Modus bedeutet?
- Warum fummelst du so viel an den DAQmx-Buffern rum? Fast immer kann DAQmx das selbst am besten…
- Die FOR-Loop zum Erstellen des Samplearrays ließe sich komplett durch InitArray ersetzen…

Hallo Gerd,

danke für deine Hinweise.

Zitat:- Wozu die zusätzliche Wartezeit in der Schleife? Üblicherweise sollte man das Timing den DAQmx-Funktionen überlassen.
- Die FOR-Loop zum Erstellen des Samplearrays ließe sich komplett durch InitArray ersetzen…

Darüber regele ich wieviel Samples im FIFO drin sind. Je größer die Differenz zwischen "CurrWritePos" und "TotalSampPerChanGenerated", desto größer ist die Reaktionszeit. Klar könnte ich den FIFO-Buffer vollhauen, dann würde nie der Puffer leerlaufen, aber dann hätte ich eine Reaktionszeit von ca. 20s (FIFO_size + PC-Buffer_size) * Samplerate.

Zitat:- Warum die Angabe "1 Sample" am DAQmxTiming? Hast du die Hilfe zur Funktion gelesen, und insbesondere darauf geachtet, was eben dieser Wert im "Continuous"-Modus bedeutet?
- Warum fummelst du so viel an den DAQmx-Buffern rum? Fast immer kann DAQmx das selbst am besten…

Ja das stimmt, da ist einiges überflüssig.

Aber gibt es aus deiner Sicht eine Möglichkeit mit meiner vorhandenen Hardware, die Ausreiser zu kompensieren und trotzdem die Reaktionszeit möglichst niedrig zu halten? Oder hilft da wirklich nur ein RealTime-System? Mir würde es reichen, wenn automatisch Samples nur generiert werden, bevor der Puffer leer läuft. Für 1-2 Zyklen kann auch mal die Reaktionszeit 1s sein, jedoch nicht dauerhaft.

Grüße
Christian