Anzahl Samples im Waveform Graph

Hi LVF,

ich lese mit DAQmx Read (Analog Wfm 1Chan NSamp).vi Messwerte aus.

Ich hab bei Anzahl Samples "-1" eingestellt, damit werden also immer alle verfügbaren Werte eingelesen. Das minimiert das Risiko eines Pufferüberlaufs, weil beim Auslesen nix im Puffer übrig bleibt, im Gegensatz zu ner fest eingestellten Menge an Messpunkten.

Leider ist es dabei aber ganz klar so, das bei "-1" die Anzahl der Punkte schwankt...und daraus resultiert, dass die Anzeige der Daten im Waveform Graph "zuckt", einfach weil bei jedem Schleifendurchlauf = Lesevorgang unterschiedlich viele Daten in den Graph geschrieben werden. Im Graph sieht das dann so aus, das der sichtbare Zeitraum im Graph nicht ganz "ausgefüllt" ist (siehe Screenshot).
   

Wie kriegt man das am besten hin, dass man ein schönes "stehendes" Bild (bei gleichbleibender Signalfrequenz) auf den Bildschirm kriegt? Bei nem Oszi kann man das mit der Triggerschwelle meistens hinbiegen...wenn man hier die X-Achse auf "Autoscale" stellt, wirds noch "unruhiger" auf dem Bildschirm, weil die Achse dann auch noch ständig geändert wird! Muss man wirklich immer ne feste Anzahl Punkte dafür einlesen?

Für ein paar Tips wäre ich dankbar, diese Thema hat mich schon immer genervt...

Gruß
Achim

Hallo, Achim,

zur Puffergröße, da hab ich kürzlich was verstecktes in der LV-Hilfe gefunden, der Puffer ist nämlich (deutlich) größer, als du ihn angibst:

http://www.LabVIEWforum.de/index.php?s=&am...ost&p=43731

Oder wie wäre es mit Event-gesteuerter Datenerfassung?

http://www.LabVIEWforum.de/index.php?s=&am...ost&p=42886

MfG, Jens

Mal so ne Idee von mir. Ich gehe mal davon aus dass das dt zwischen
den Samples gleich ist. Ich weiß nicht ob die Daten als "Signalverlauf" vorliegen.
Wenn nicht kann man aber ja mit dem dt einen draus erstellen.

1. Schritt wäre Baustein "Signalverlaufsdauer ermitteln"
2. Schritt der Triggerbaustein, am besten den 1. Nulldurchgang suchen
3. Die Zeit die der Triggerbaustein ermittelt ziehst du von der Gesamtdauer ab
4. X-Achse Maximum über EIgenschaftsknoten setzen auf Dauer aus Schritt 3
5. Baustein "Signalverlaufsabschnitt lesen ab Triggerzeit mit der Dauer aus Schritt 3
6. Signal anzeigen

Keine Ahnung ob dir das was hilft, aber ich mache es zum Beispiel
so mit einem Soundkartensignal wobei ich eigentlich keinen Variablen
Puffer habe, aber ansonsten müsste das doch so gehen denke ich.

Die Frage ist eher wie dein Signal aussehen kann, wenns nur wildes
Gezuppel ist, ist der Triggerbaustein meist wenig hilfreich für sowas..

' schrieb:Oder wie wäre es mit Event-gesteuerter Datenerfassung?

Das hab ich noch nie probiert, sollte ich mal versuchen. Kann man da ganz allgemein Vor- und Nachteile nennen?

A.

Zitat:Ich gehe mal davon aus dass das dt zwischen
den Samples gleich ist. Ich weiß nicht ob die Daten als "Signalverlauf" vorliegen.

Ja und Ja!

Zitat:2. Schritt der Triggerbaustein, am besten den 1. Nulldurchgang suchen

Hab keinen Nulldurchgang!

Ich werd's aber mal probieren!

Zitat:Die Frage ist eher wie dein Signal aussehen kann, wenns nur wildes
Gezuppel ist, ist der Triggerbaustein meist wenig hilfreich für sowas..

Siehe Screenshot im ersten Beitrag! Es ändert sich nur die Frequenz!

Ist mir eben so eingefallen: Daten einzeln in Queue schreiben und mit 10% schneller als Sampletask auslesen und anzeigen. [*denk*] Oder warten, bis 10 Samples in Queue und dann anzeigen.

Außerdem: Hab ich da in LV8.5 nicht was gelesen von "Anzeige verzögern"?

Anzeige

Du kannst ja anstatt Pegel 0 halt 2 oder 1000000 nehmen und steigende Flanke
oder fallende, je nachdem was die lieber ist. Dann müsste das eigentlich so gehen
wie ichs geschrieben habe.

Mit Nulldurchgang wollte ich eigentlich sagen den Wechsel von negativer zu
positiver Steigung. Ausser dem Pegel am Triggerbaustein ändert sich halt nix
an der Vorgehensweise.

' schrieb:Das hab ich noch nie probiert, sollte ich mal versuchen. Kann man da ganz allgemein Vor- und Nachteile nennen?

A.

Na der Vorteil wäre, das du mit der Event-Struktur einfach warten kannst, bis z.B. 1000 Messwerte im Datenpuffer liegen, erst dann erfolgt auslesen und Darstellung. Somit hast du deine feste Anzahl von Werten, die du immer darstellen willst.

Dann noch eine andere Frage/Vorschlag: Brauchst du eigentlich den TimeStamp und die weiteren Infos, die dir die Waveform liefert? Das feste Delta-t hast du ja. Dann würde ich eher die Daten nur als Array zurückgeben und mir dann per Build-Cluster eine Waveform-Cluster zusammenbauen. Das reine Array lässt sich doch wesentlich besser weiterverarbeiten und dann meinetwegen immer so auseinandernehmen, wenn du wieder (z.B.) 1000 Messwerte in deinem (dann selbstprogrammierten) Ringpuffer hast.

MfG, Jens

Hast du eigentlich eine Lösung wie du jetzt den Graphen quasi
ruckelfrei gemacht hast?

Vielleicht kann ich das nämlich auch bei mir verwenden

' schrieb:Hast du eigentlich eine Lösung wie du jetzt den Graphen quasi
ruckelfrei gemacht hast?

Vielleicht kann ich das nämlich auch bei mir verwenden

Nö...noch nicht...ich hab deine Vorschläge mal getestet, aber das hat irgendwie nicht funktioniert und ich hatte bisher keine Zeit, da weiter zu machen...mal sehen...