kein gewünschtes Signal bei Signalerfassung

Hallo Leute.

Habe eine DA zu erledigen und arbeite dabei mit LabVIEW 8.0. Ich habe noch nie einen Kurs belegt und habe auch sonst keine Ahnung, brauche es jetzt aber. Mit viel Hilfe bin ich auch schon sehr weit gekommen. Mein Problem ist das ich jetzt zwar Signale messbar vom DAQ abgreifen kann, dank eurer Mithilfe, diese aber im gleichen Atemzug noch nicht einfangen kann. Ich habe dafür an dem DAQPad-6015 den Ausgang (CH0) mit dem Eingang (CH0) verbunden. Mit einem externen Oszi kann ich auch nachweisen dass ein Signal raus geht. Nur beim Einlesen gelingt es mir nicht dieses in meinem Programm auf den virtuellen Graphen zu bringen. Kann mir jemand sagen was ich falsch mache?





Gruss Gunni

<div align="left">Hallo, Gunni,

erste Empfehlung: schau dir mal die Beispiele im NI Example Finder unter "Analog Generation" und "Analog Measurement" an (Sorry für die englischen Ausdrücke, habe "nur" englisches LV).

Zweiter Tip: Dir fehlen meiner Meinung nach die Sample-Clock Einstellungen.

Dritter Tip: Ich hab mal etwas quick & dirty gebastelt:

[attachment=29644:attachment]

Hoffe, es hilft ein wenig weiter.

MfG, Jens</div>

' schrieb:<div align="left">Hallo, Gunni,

erste Empfehlung: schau dir mal die Beispiele im NI Example Finder unter "Analog Generation" und "Analog Measurement" an (Sorry für die englischen Ausdrücke, habe "nur" englisches LV).

Zweiter Tip: Dir fehlen meiner Meinung nach die Sample-Clock Einstellungen.

Dritter Tip: Ich hab mal etwas quick & dirty gebastelt:


Hoffe, es hilft ein wenig weiter.

MfG, Jens</div>

Guten Morgen.

Danke Jens. Von den Sample-Clock-Einstellungen habe ich zwar noch keine Ahnung, aber jetzt werde ich mich in diese Richtung versuchen schlau zu machen. Deine "VI-Geschichte" konnte ich mir leider nicht ansehen, da mein LabVIEW es nicht geöffnet hat. Die Begründung war das ein Fehlercode 9 vorliegt - es wäre wohl mit Version 8.2 gecodet und ich besitze nur 8.0.


Bis denne...
Gunni

<div align="left">Hallo, Gunni,

war mir eigentlich sicher, dass ich für Version 8.0 gespeichert hätte. Hat wohl nicht funktioniert.

Hier der 2. Versuch (diesmal auch Öffnen unter LV8.01 getestet):


  Daten_bidirektional2.vi (Größe: 58,68 KB / Downloads: 267)


Wie gesagt, quick & dirty!!

Wenn es jetzt nicht mit dem Öffnen funktioniert, empfehle ich das Update auf Version 8.0.1! Das hat einige Bugs von Version 8.00 beseitigt.

MfG, Jens</div>

' schrieb:<div align="left">Hallo, Gunni,

war mir eigentlich sicher, dass ich für Version 8.0 gespeichert hätte. Hat wohl nicht funktioniert.

Hier der 2. Versuch (diesmal auch Öffnen unter LV8.01 getestet):


Wie gesagt, quick & dirty!!

Wenn es jetzt nicht mit dem Öffnen funktioniert, empfehle ich das Update auf Version 8.0.1! Das hat einige Bugs von Version 8.00 beseitigt.

MfG, Jens</div>

Jens,

danke dafür das du dir nochmal Zeit genommen hast. Ich sehe schon, auch wenn du es "quick and dirty" nennst - uns trennen Welten.

Ich werde mir dein Beispiel mal zur Brust nehmen und hoffe es mit der Zeit zu verstehen, um neue Kenntnisse zu gewinnen.
Funktionieren tut es auf jeden Fall schon mal, nur das ich dann mein Signaltyp während des Betriebs nicht mehr ändern kann - so müßte ich es jedes mal neu starten.


Gruss Gunni

Hallo Leute.

Also ich habe an meinem Programm ein paar Änderungen gemacht und bin dem Ziel vielleicht etwas näher gekommen.

Was ich festgestellt habe ist das bei den NI-Beispielen, sowie bei der Änderung durch Jens, immer dieses VI namens "DAQmx - Timing (Abtasttakt)" vor der Schleife mit den eigentlichen Messwertaufnahmen gebaut wurde. Ich verstehe den Zweck nicht ganz, bin mir aber sicher das es eine enorme Bedeutung bei meiner Aufgabe hat.




Gunni

Anzeige

<div align="left">Hallo, Gunni,

ein klein wenig zum Verständnis (nur bezogen auf Analog In/gilt aber auch übertragen für AO): Die DAQ-Karten nehmen natürlich nicht kontinuierlich irgendwelche Daten auf. Das ganze läuft schließlich digital, d.h. zu gewissen Zeiten wandelt die Karten den anliegenden analogen Spannungswert über seinen AD-Wandler in eine digitale Zahl.

Jetzt muß man der Karte natürlich sagen, wann dies geschehen soll. Hier gibt es eine Reihe von Vorgehensweisen:
- Einlesen mit fester Frequenz (intern)
- Einlesen auf Grund eines externen Triggersignals
- Software-Trigger
...

Das macht u.a. das VI DAQmxTiming. Deshalb war das auch recht wichtig, es einzubauen.

Wenn du dann mal weiter einsteigst, kommen dann bestimmt Fragen auf wie: Wann und wie soll die Datenerfassung gestartet und/oder beendet werden (interne Trigger, externe Trigger, Software-getriggert ...).

Aber da helfen die Beispiele im NI-ExampleFinder definitiv weiter. Zumindest war es so bei mir. Ich habe mir aus diesen Beispielen eine Menge rausgezogen.

MfG, Jens.

P.S.: Habe erst mal keine Zeit, dein VI anzuschauen, vielleicht heute abend?!</div>

' schrieb:<div align="left">Hallo, Gunni,

ein klein wenig zum Verständnis (nur bezogen auf Analog In/gilt aber auch übertragen für AO): Die DAQ-Karten nehmen natürlich nicht kontinuierlich irgendwelche Daten auf. Das ganze läuft schließlich digital, d.h. zu gewissen Zeiten wandelt die Karten den anliegenden analogen Spannungswert über seinen AD-Wandler in eine digitale Zahl.

Jetzt muß man der Karte natürlich sagen, wann dies geschehen soll. Hier gibt es eine Reihe von Vorgehensweisen:
- Einlesen mit fester Frequenz (intern)
- Einlesen auf Grund eines externen Triggersignals
- Software-Trigger
...

Das macht u.a. das VI DAQmxTiming. Deshalb war das auch recht wichtig, es einzubauen.

Wenn du dann mal weiter einsteigst, kommen dann bestimmt Fragen auf wie: Wann und wie soll die Datenerfassung gestartet und/oder beendet werden (interne Trigger, externe Trigger, Software-getriggert ...).

Aber da helfen die Beispiele im NI-ExampleFinder definitiv weiter. Zumindest war es so bei mir. Ich habe mir aus diesen Beispielen eine Menge rausgezogen.

MfG, Jens.

P.S.: Habe erst mal keine Zeit, dein VI anzuschauen, vielleicht heute abend?!</div>

Hallo.

Okay an meiner vorigen Änderung war ja nicht viel geschehen, also habe ich dieses DAQmx Timing mal mit eingebaut. Ich habe es so verstanden das damit meine Karte oder Gerät sozusagen vorkonfiguriert wird, mit welcher Sampel-Rate mein Signal abgetastet wird. Wenn ich an dem VI "DAQ -Lesen" beim "Anzahl der Samples" -1 als Konstante dran setze greift er immer auf die zuvor bei "DAQmx - Timing" eingestellte Sample-Rate zurück.

Sollte dies alles stimmen und ich hoffe das tut's, denn mein Beispieldurchlauf funktioniert irgendwie, bin ich jetzt wahrscheinlich schon auf dem richtigen Weg. Nun habe ich aber festgestellt das ich ja beim Programmdurchlauf stets das Signal verändern kann in Form, Frequenz usw., aber damit auch die Anzahl der Samples.
Wenn ich jetzt beim Einlesen aber vor der Schleife eine feste Einstellung getroffen habe für die Sample-Rate , die dann nicht während des Betriebs geändert werden kann, habe ich nicht viel gekonnt.

Das muss sich dann doch beim Einlesen auch noch verändern lassen, oder?


Gunni

<div align="left">Hallo, Gunni,

ich habe das Gefühl, du hast noch einige Probleme mit den Namen/Begrifflichkeiten der Variablen. Vielleicht liege ich aber auch falsch, dann ignoriere einfach das Folgende:

Die Variable "Samples per Channel" ist vollkommen unabhängig von der Variable "Rate".
Das erste ist im Normalfall die Anzahl der Messungen, die du machen willst.
Das zweite ist bei Verwendung der internen Zeitbasis der DAQ-Karte die Frequenz, mit der diese Messwerte aufgezeichnet werden.
Das hat jetzt erst mal gar nichts mit der Variable "Anzahl der Samples" beim VI DAQmx-Lesen zu tun. Der Eingang hier besagt nur, wieviel Werte mindestens auf einmal eingelesen werden sollen. Und das ist vollkommen unabhängig von der Einlesefrequenz. Denn die Messung kann z.B. so aufgebaut werden, dass quasi-kontinuierlich Messwerte eingelesen werden und auch angezeigt werden, s. hierzu mein zuletzt gepostetes VI.

Noch mal mein dringender Rat:
Schau dir die Beispiele im NI Example Finder an (Über Pulldownmenü Hilfe->Finde Beispiele bzw. Find Examples). Zieh dir da erstmal einzeln die Beispiele von Analog In und Analog Out rein. Arbeite so ziemlich alles durch. Lies dir die Online-Hilfen zu den DAQmx-VI's an, die verwendet werden. Da müsstest du eine ganze Menge lernen. Und nicht vergessen, auch den Source-Code der DAQmx-VI's anschauen!

Und dann als nächste Empfehlung: Mach erst mal Tests mit Analog Out allein und Analog In allein. Und füge erst dann alles mal zusammen. Denn meiner Meinung nach willst du zu viel auf einmal und gleichzeitig machen, das muss zwangsläufig zu Problemen führen.

Ich will jetzt gar keine neue Version deines/meines VI's posten, sondern nur ein paar Hinweise/Fragen:
Wo ist das Timing für das AO, das hatte ich doch schon eingebaut?
Beim Analog In langt dir auch SingleChannel-MultipleSamples-Modus.
Und das mit den zwei While-Loops war ganz bewusst von mir angelegt, da AO und AI ja völlig unabhängig parallel laufen können. Du könntest sogar für deine ersten Versuche AO und AI in zwei verschiedenen VI's machen.

Dann noch zu einer deiner Fragen:
Also Sample-Rate während des Messung ändern, das habe ich auch noch nicht gemacht, weiss nicht ob das mit den internen Countern als Basis geht. Wenn du ein externe Zeitbasis als Trigger verwendest, dann schon eher. Musst du halt alles irgendwann mal ausprobieren, aber erarbeite dir doch erst mal die Grundlagen. Wie schon gesagt, du willst zu viel auf einmal, und das geht auch in LabVIEW schief.

MfG, Jens</div>

' schrieb:Hallo, Gunni,

ich habe das Gefühl, du hast noch einige Probleme mit den Namen/Begrifflichkeiten der Variablen. Vielleicht liege ich aber auch falsch, dann ignoriere einfach das Folgende:

Die Variable "Samples per Channel" ist vollkommen unabhängig von der Variable "Rate".
Das erste ist im Normalfall die Anzahl der Messungen, die du machen willst.
Das zweite ist bei Verwendung der internen Zeitbasis der DAQ-Karte die Frequenz, mit der diese Messwerte aufgezeichnet werden.
Das hat jetzt erst mal gar nichts mit der Variable "Anzahl der Samples" beim VI DAQmx-Lesen zu tun. Der Eingang hier besagt nur, wieviel Werte mindestens auf einmal eingelesen werden sollen. Und das ist vollkommen unabhängig von der Einlesefrequenz. Denn die Messung kann z.B. so aufgebaut werden, dass quasi-kontinuierlich Messwerte eingelesen werden und auch angezeigt werden, s. hierzu mein zuletzt gepostetes VI.

das ist nicht ganz korrekt. Der Eingang Samples per Channel legt fest wieviel Werte GENAU pro Schleifendurchlauf (meistens bei einer kontinuierlichen Messung) aus dem Buffer gelesen werden. Schließt man ein "-1" an, werden ALLE Werte die sich beim Funktionsaufruf im Buffer befinden abgeholt.

Wenn mann "-1" anschließt muss man die Schleife mit z.B. "wait for next ms multiple" bremsen -> man hat eine Software getimete (scheiss denglisch - sorry) Erfassung Programmiert. Legt man die Anzahl der Werte genau fest, wartet die Funktion so lange, bis entweder der Timeout erreicht wurde oder die entsprechende Anzahl Samples im Buffer liegt und gibt diese zurück. Das nennt mann dann Hardware getimete Erfassung.

Vielleicht trägt dieses Beispiel etwas zum besseren Verständnis von hardware- / software-getimeter Erfassung bei ...

Grüße
CB