Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Mittels LabVIEW soll das Auslesen eines AC Signals stattfinden. So weit, so gut. Das Signal wird auf einen Atmel Atmega16 Microcontroller gegeben, der mittels ADC und MAX232 die Daten über den Serialport an einen Rechner weitergibt. Dort soll LabVIEW die Ansteuerung des Microcontrollers sowie die Messung vornehmen und auswerten. Dabei gelingt es mir jedoch nicht, Signale (sinnvoll) zu messen, sobald deren Frequenz höher als etwa 3 Hz liegt.
Testweise wurde mit einem TTi 40MHz Funktionsgenerator ein Sinussignal bzw. Pulssignal auf einen Kanal gelegt und ausgelesen.
Das Auslesen geschieht ungepuffert direkt nach Aufforderung:
LabVIEW sendet ein "m", der Microcontroller führt die Messung durch und sendet das Ergebnis an LabVIEW zurück. Dort werden die Daten in einen Spannungswert skaliert und auf einem Graphen ausgegeben.
LabVIEW sollte doch in der Lage sein, bis auf etwa 1ms Schleifen durchzuführen, das entspräche aber einer Frequenz von 1 kHz - davon bin ich aber leider weit entfernt...
Im Anhang findet Ihr das komplette Programm (erstellt mit LabVIEW 7.1 Express), die Aufteilung ist
Atmel16.vi - User Interface und Messschleifen
Communication.llb - VISA Kommunikation
Conversion.llb - Konvertieren der Daten in Spannungen, Hex in ASCII, etc.
Functions.llb - Diverse kleinere Funktionen
Test.llb - (nicht benötigt)
Variables.llb - Globale Variablen
Sieht deine aufgenommene Kurve schlecht aus oder siehst du ganz was anderes auf dem Graphen?
Timing/Frequenz-Problem ist vom Betriebssystem vorgegeben und nicht vom LabVIEW.
Wenn du die Daten gleich schön darstellen willst, kannst du vom Atmel einen Zeitstempel zu jedem Datensatz mitausgeben lassen und dann die Daten auf einem XY-Plot richtig darstellen.
Sieht deine aufgenommene Kurve schlecht aus oder siehst du ganz was anderes auf dem Graphen?
Timing/Frequenz-Problem ist vom Betriebssystem vorgegeben und nicht vom LabVIEW.
Wenn du die Daten gleich schön darstellen willst, kannst du vom Atmel einen Zeitstempel zu jedem Datensatz mitausgeben lassen und dann die Daten auf einem XY-Plot richtig darstellen.
eg
Hi Eugen,
problematisch ist tatsächlich die Geschwindigkeit der Datenaufnahme. Natürlich sieht infolgedessen der Graph der ausgegebenen Kurve nicht mehr annähernd so aus, wie die vom Funktionsgenerator erstellte Funktion. Die Vorgabe des Timings durch das OS ist mir bekannt, jedoch sollten selbst bei einem Schleifen-Timing von 100ms noch folglich 10Hz möglich sein. Pulse oder Sinussignale bis etwa 3 Hz können zwar problemlos aufgezeichnet und wiedergegeben werden, aber natürlich ist die Zeitachse eher in "a.u." zu verstehen und gibt keine absolut definierten Werte wieder...
Dabei stellt sich mir ohnehin die Frage: Messungen im kHz-Bereich werden vermutlich nur durch Hardware gelöst? Immerhin sind, soweit mir bekannt, mit LabVIEW und der passenden DAQmx-Hardware derartige Messungen problemlos möglich. Ich vermute, dass dabei die Messung durch die Hardware in schnellem Speicher gebuffered und auf einen Schwung ebenfalls mit Timestamp versehen übertragen wird?
Die Vergabe des Timestamps durch den Atmel würde auf einen Schlag 1000 meiner Probleme lösen! Die Programmierung des Microcontrollers habe nicht ich vorgenommen, die geschieht durch einen Dritten. Ist Dir eventuell Näheres dazu bekannt (wann, wie, wo? - oder so ähnlich...)? Dennoch würde sich doch aber die Aufzeichnung schneller Signale nur mit einem schnellen Zwischenspeicher realisieren lassen, oder?
Wenn du keine Möglichkeit hast den Zeitstempel (es darf auch ein relativer 8-Bit-Samplecounter sein) vom uC zu bekommen, dann ne weitere Frage:
kannst du davon ausgehen, dass die Daten wirklich mit 3 Hz kommen? Wenn ja, benutze einen Waveform Graphen dazu, da kannst du DeltaT fest einstellen.
Ansonsten musst du dich wirklich "blind" auf Betriebssystemtiming verlassen, na ja das Resultat unbekannt. 3 Hz sollte aber noch einigermassen gut aussehen.
Wenn es doch VIIIIEEEL zu schlecht aussieht, dann hast du was falsch (besser gesagt suboptimal) programmiert. Lade dein VI hier hoch, mal schauen was man da machen kann.
' schrieb:Es stimmt, alles was du hier geschrieben hast.
Wenn du keine Möglichkeit hast den Zeitstempel (es darf auch ein relativer 8-Bit-Samplecounter sein) vom uC zu bekommen, dann ne weitere Frage:
kannst du davon ausgehen, dass die Daten wirklich mit 3 Hz kommen? Wenn ja, benutze einen Waveform Graphen dazu, da kannst du DeltaT fest einstellen.
Ansonsten musst du dich wirklich "blind" auf Betriebssystemtiming verlassen, na ja das Resultat unbekannt. 3 Hz sollte aber noch einigermassen gut aussehen.
Wenn es doch VIIIIEEEL zu schlecht aussieht, dann hast du was falsch (besser gesagt suboptimal) programmiert. Lade dein VI hier hoch, mal schauen was man da machen kann.
eg
Ob die Möglichkeit des Zeitstempels, welcher Art auch immer, besteht, muss ich erst herausfinden - schlimmstenfalls kann ich auch ein wenig C
Die Daten kommen vom Funktionsgenerator definitiv mit 3 Hz, ob das Einlesen jedoch exakt mit 3 Hz geschieht ist fraglich. Da jedoch die Ausgabe in "Realtime" (naja, so wie es das OS halt timed) erfolgt und der Sinus auch vollkommen reproduziert wird (keine Drops, die die Form wesentlich verunstalten), gehe ich davon aus, dass diese zumindest noch im Rahmen des Möglichen liegen.
Mein VI hatte ich im ersten Post bereits hochgeladen (Atmel Atmega16.zip), darin sind alle Dateien enthalten, da ich (natürlich) umfangreich in SubVIs ausgelagert habe.
