LabVIEWForum.de - Measurements: Data was overwritten before it could be read by the system.

LabVIEWForum.de

Normale Version: Measurements: Data was overwritten before it could be read by the system.
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo,

mit zwei VIs aus dem Examplefinder habe ich eine Problemlösung gebaut. Eine Messung des Tastverhältnusses und der Frequenz und die Abgebe eines zeitversetzten Impulses. Das Ding funktioniert nur manchmal. Ich verende ein 6251 das TTL Signal liegt an J3 (PFI9) und J41 (PFI4) also die Gate Eingänge und DGND an J4, das Signal sehe ich am Scope und das steht!

Die untere Schleife geht immer, ich bekomme immer das signalverzögerte Signal.

Die komplette Fehlermeldung -200141
+++
Measurements: Data was overwritten before it could be read by the system.

If Data Transfer Mechanism is Interrupts, try using DMA. Otherwise, divide the input signal before taking the measurement.

Task Name: _unnamedTask<46F>
---

und das bei einem TTL Signal von 5Hz oder 0,5Hz. Beispiel mit 8.6

Es kommt noch besser. Wenn ich im MAX eine Frequenztaskerstelle bekomme och irrsinnig hohe Frequenzen - siehe Bild.

Bitte um einen Rat

Danke

Gottfried
Warum generierst und loescht du den Task bei jedem schleifendurchlauf?
Nachdem du beide ctrs verwendest, ist eine retriggerable app nicht moeglich, was du aber machen kannst ist, dass du den task nur stoppst und wieder startest. das stopp und das start schalten den trigger wieder aktiv. du sparst dir viel zeit durch diesen schritt. zudem kommt noch, dass du den # of samples to read nicht angeschlossen hast, obwohl du finite messung eingestellt hast.
verbinde samples per channel and den daqmx read eingang.

in der daqmx hilfe kannst du nachlesen, wieviele samples per configuration per default allokiert werden.
ich schlage vor, dass du mal den abschnitt durchliest und zusaetzlich ein daqmx property mit available samples in der schleife ausliest um zu sehen wie sich der counter verhaelt...

ich nehme stark an, dass dein ttl signal nicht sauber ist und dadurch extrem viele samples generiert, was auch den hohen wert im MAX erklaeren wuerde (viele samples, hohe frequenz)
' schrieb:Warum generierst und loescht du den Task bei jedem schleifendurchlauf?
weil ich es sonst nicht zusammengebracht habe, mit anderen worten - keine Ahnung wie ich das ohne mache
' schrieb:Nachdem du beide ctrs verwendest, ist eine retriggerable app nicht moeglich, was du aber machen kannst ist, dass du den task nur stoppst und wieder startest. das stopp und das start schalten den trigger wieder aktiv. du sparst dir viel zeit durch diesen schritt.
wo setze ich jetzt das start und stop?
' schrieb:zudem kommt noch, dass du den # of samples to read nicht angeschlossen hast, obwohl du finite messung eingestellt hast.
verbinde samples per channel and den daqmx read eingang.
das ändert nichts - sorry
' schrieb:in der daqmx hilfe kannst du nachlesen, wieviele samples per configuration per default allokiert werden.
ich schlage vor, dass du mal den abschnitt durchliest und zusaetzlich ein daqmx property mit available samples in der schleife ausliest um zu sehen wie sich der counter verhaelt...
das mache ich
' schrieb:ich nehme stark an, dass dein ttl signal nicht sauber ist und dadurch extrem viele samples generiert, was auch den hohen wert im MAX erklaeren wuerde (viele samples, hohe frequenz)
Hmm - am Scope schaut das aber sehr sauber aus, ich habe das Signal mit 680nF (von FPI9 auf DGND) geglättet - das macht keinen Unterschied. Wenn ich auf 1Hz gehe sehe ich am Digital In sehr schön die Imolse. Das TTL kammt aus dem Signalgenerator, die 11MHz Störung (mit TTL Niveau) müsste ich doch am Scope sehen

Danke jedenfalls

Gottfried
Entweder bin ich blind oder das STRG F feature funktioniert net -> ich sehe kein property available samples per channel


Wenns am oszi schoen aussieht, ueberpruef mal ob dein connector block oder das cable was hat.
Viel was anderes kanns ja net mehr sein...




das start und stop laesst du so wie du es aktuell drinnen hast, jedoch ziehst du das initialisieren vom task und das loeschen vom task ausserhalb der schleife.
Hallo,

so ein SCHEISS (sorry) - es war das Netzgerät, das hat (natürlich mit niedrigem Innenwiderstand) Mist auf die Leitung gebracht der mit einem Tiefpass an den Eingangsklemmen nicht zu beherrschen war. Und deswegen sucht man eine Woche ...

Klar die Samples per Channel habe ich jetzt auch verbunden.

ad freedive
+++
Nachdem du beide ctrs verwendest, ist eine retriggerable app nicht moeglich, was du aber machen kannst ist, dass du den task nur stoppst und wieder startest. das stopp und das start schalten den trigger wieder aktiv. du sparst dir viel zeit durch diesen schritt.
---
das verstehe ich nicht. Das Programm (modifiziert) funktioniert nun, aber wo soll ich stop und start einbauen

Danke

Gottfried
Hallo zusammen,
ich schreib hier in diesem vorhandenen Thema, da ich die selbe Fehlermeldung bekomme. Ich habe mit dem Assistenten eine Periodenmessung erstellt. Ziel ist es die exakte Dauer für eine bestimmte Anzahl von Impulsen zu bestimmen, darum N Samples. Mein Problem ist, wenn ich mehr als 100 Samples aufnehmen will, funktioniert das nur manchmal, häufiger wird mit dem Fehler -200141 abgebrochen. Hab ich irgendwo eine Einschränkung übersehen? Als Hardware kommt eine PCI-6221 zum Einsatz. Gemessen wird an Counter 1. Die selbe Messung, nur mit einer anderen Quelle und deutlich mehr Samples läuft an Counter 0 fehlerlos.
Bitte kann mir jemand helfen ich bin am verzweifeln.
Angehängt ist das VI.

Danke und Gruß
Sven

Lv85_img
Referenz-URLs