LabVIEWForum.de

In meinem Projekt setze ich die Timer-Funktion (Get-Tick-Count) zur Synchronisierung von nicht so einfach zu synchronisierenden Prozessen ein.
Ich habe ine Datenquelle, die mit 32,045 ms Periode Werte generiert, diese puffert und DLL-gesteuert abliefert. Wie das nun bei Windows so ist, funktioniert das mit der Echtzeitfähigkeit überhaupt nicht und die Werte tauchen, je nach Systemauslastung, zu seltsamen Zeiten und in unterschiedlichen Packetgrößen auf. Doch, Hardwarepuffer sei dank, geht nichts verloren. Also hab ich ein VI geschrieben, das die Werte in ein Array packt und mit einem ms-Zeitstempel (Get-Tick-Count) der Übernahme versieht. So hab ich dann festgestellt, dass die Timerfunktion und meine externe Datenquelle sehr genau synchron laufen (ppm-Bereich).
Des weiteren habe ich eine Positionsberechnung mit der gleichen Funktion realisiert, da ich hier Startzeit und Geschwindigkeit kenne ...
Die unterschiedlichen Tasks sind in eigenen VI's untergebracht und tauschen über Notifiers und Queue die Daten aus.
Alles lief super bis ich noch eine Spannung über die PCI-6259 ausgeben wollte. Hab mir das Beispiel Gen Voltage Update.vi genommen, mit einer While-Schleife versehen, Wartezeit dazu, funktioniert. Doch wenn das VI zusammen mit den anderen VI's läuft, passen die Timerwerte nicht mehr. Die ursprünglich so genaue Datenquellenperiode von 32,045 ms ist ca. 0,5 ms kürzer.
Mein Rechner ist ein Dual-Core, die Systemlast liegt bei ca. 22%.
Eine timed loop hab ich auch schon probiert, gleiches Problem.
Da ich den Wert ca. 10-20 mal /s ändern will, bringt ein dauerndes neu erstellen und schließen des Tasks auch nichts.
Früher konnte man bei D/A-Karten einfach Werte in ein Register schreiben, aber das waren ja auch ISA-Karten (...und es hat auch öfters mal geknallt).
Kann man den DAQ-Manager irgendwie umgehen?

Vielen Dank

Joachim
[attachment=33264]

(13.04.2011 08:00 )JoBlau schrieb: [ -> ]Doch, Hardwarepuffer sei dank, geht nichts verloren. Also hab ich ein VI geschrieben, das die Werte in ein Array packt und mit einem ms-Zeitstempel (Get-Tick-Count) der Übernahme versieht. So hab ich dann festgestellt, dass die Timerfunktion und meine externe Datenquelle sehr genau synchron laufen (ppm-Bereich).

Wenn die Daten, die von extern kommen, doch im Raster von 32,045ms kommen, warum brauchst du dann einen Timestamp für jeden Datenwert?

Was willst du denn synchronisieren? Deine Datenquelle und die Timer-Funktion wohl kaum.

Eine Auslösung auf 0,001ms machen zu wollen in einer Windows-Umgebung ist utopisch. 32,045ms hat eine Auflösung von 0,001ms.

(13.04.2011 10:37 )IchSelbst schrieb: [ -> ]Was willst du denn synchronisieren? Deine Datenquelle und die Timer-Funktion wohl kaum.

Eine Auslösung auf 0,001ms machen zu wollen in einer Windows-Umgebung ist utopisch. 32,045 ms hat eine Auflösung von 0,001ms.

Weil ich davon ausgehe, dass mein Messsystem nicht irgendwelchen Launen (Windows, Multitasking, Temperaturdrift ...) ausgeliefert ist, ging ich hin und bestimmte die Zeit, bis ich einige 100*10^3 Werte hatte. So kommt man dann auf den Wert. Um das ganze noch abzusichern, habe ich noch die Schwankungsbreiten der Zeitabstände untersucht, bis ich dann sicher war dass ich mich auf die Frequenz verlassen kann.

Ich habe 3 Zeitbasen:
Computer
Messsystem (Interferrometer, T = 32,045 ms)
Lineareinheit (Stand allone über RS-232 gesteuert)

Alle 3 Zeitbasen stehen in einem linearen Zusammenhang zueinander.
Jetzt ist plötzlich die Zeitbasis Computer eine Variable, deren Verhalten ich nicht absehen kann.

Ich will die Werte des Messsystems mit Positionsdaten versehen.
Die Lineareinheit wird via RS232-Kommando auf den Weg geschickt. Sie liefert mir nur einen Bewegungsstatus (boolean). Mit Geschwindigkeit, Startzeit, Zeit und Startpunkt berechnet sich die zurückgelegte Wegstrecke zu jedem Messpunkt des Messystems, für den ich natürlich die Zeitstamp habe, da die Werte so wunderbar äquidistant kommen. Dass das in etwa passt, hab ich physikalisch ausprobiert. Es gibt da zwar noch ein paar kleine Probleme mit der t0 ... doch ich interessiere mich hauptsächlich für die Steigung.

Gruß

Joachim

(13.04.2011 13:16 )JoBlau schrieb: [ -> ]Weil ich davon ausgehe, dass mein Messsystem nicht irgendwelchen Launen (Windows, Multitasking, Temperaturdrift ...) ausgeliefert ist,

Genau. Das Messsystem ist unabhängig von jedweder Zeitungenauigkeit im PC.

Zitat:Ich habe drei Zeitbases:
Computer
Messsystem (Interferrometer, T = 32,045 ms)
Lineareinheit (Stand allone über RS-232 gesteuert)

Also mich interessiert die Zeitungenauigkeit es PCs nie.
Du willst also das Messsystem mit der Lineareinheit synchronisieren? Das funktioniert aber auch nicht, weil die RS232 alleine schon eine Zeitungenauigkeit hat.

Zitat:Alle 3 Zeitbasen stehen in einem linearen Zusammenhang zueinander.
Jetzt ist plötzlich die Zeitbasis Computer eine Variable, deren Verhalten ich nicht absehen kann.

Die Zeitbasis "Computer", solange es lediglich ein PC ist, kann man grundsätzlich nicht absehen. Auch ohne dem zusätzlichen DaqMX-Kanal würde ich mich nie auf die Zeitbasis Computer verlassen.

Zitat:Ich will die Werte des Messsystems mit Positionsdaten versehen.

Verstehe ich das wie folgt richtig?
Du machst eine mathematische Berechnung von Werten, die du dann den Messdaten zuordnest. Die Messdaten kommen alle 32,045ms. Also tust du praktisch auch alle 32,045ms einen neuen Wert berechnen. Bestimmt geht in die mathematische Formel die Zeit ein => die Zeit in der Formel und der Zeitpunkt des Messung, also der Timestamp, müssen identisch sein.

[*grübel*]

Ich sach mal: da brauchst du trotzdem keinen Timestamp. Wenn t0 für beide Kanäle (der mathematisch berechnete Wert und der gesampelte) gleich ist, dann verwendest du in der mathematischen Formel einfach den festen Wert 32,045. Weil die Samplerate des Messsystems nämlich genau 32,045 ist. Deine Messwerte kommen ja immer im selben Raster - dafür gibt es ja eben die diversen Zwischenpuffer. Diese Puffer bewirken ja, dass die Zeitungenauigkeit eliminiert wird.

Hallo IchSelbst!

Für mein Problem habe ich jetzt eine nicht befriedigende Lösung gefunden. In dem geposteten Beispiel wird ja alle x-ms die Schleife abgearbeitet die den Wert dem AnalogOut rüber schiebt. Da ich diese Schleife nur noch bei Wertänderung abarbeite, ist mein Timerfehler jetzt wesentlich kleiner geworden. Jeder Aufruf des DAQ-Tasks kostet einige µs (Werde das morgen mal nach checken). Durch diese Reduzierung der Taskaufrufe bleibt der Fehler im vertretbaren Bereich.

Zitat:Also mich interessiert die Zeitungenauigkeit es PCs nie.
Du willst also das Messsystem mit der Lineareinheit synchronisieren? Das funktioniert aber auch nicht, weil die RS232 alleine schon eine Zeitungenauigkeit hat.

Klar, das stimmt. Doch die Maschine die ich da einsetze arbeitet mit 115 kbaud und hat z.B. 1-Byte Statusbefehle, da ist nach 2 ms (Oszilloskopmessung) die Antwort schon da. Es gibt da noch einige Gründe, die die Genauigkeit beeinflussen, die Beschleunigungs- und Verzögerungszeiten. Doch spielen die paar ms für mein Projekt keine große Rolle. Doch der sich aufkumulierende Fehler mit dem ich da zu kämpfen habe liegt nach einigen Minuten im Sekundenbereich.

Zitat:Verstehe ich das wie folgt richtig?
Du machst eine mathematische Berechnung von Werten, die du dann den Messdaten zuordnest. Die Messdaten kommen alle 32,045ms. Also tust du praktisch auch alle 32,045ms einen neuen Wert berechnen. Bestimmt geht in die mathematische Formel die Zeit ein => die Zeit in der Formel und der Zeitpunkt des Messung, also der Timestamp, müssen identisch sein.

Ich sach mal: da brauchst du trotzdem keinen Timestamp. Wenn t0 für beide Kanäle (der mathematisch berechnete Wert und der gesampelte) gleich ist, dann verwendest du in der mathematischen Formel einfach den festen Wert 32,045. Weil die Samplerate des Messsystems nämlich genau 32,045 ist. Deine Messwerte kommen ja immer im selben Raster - dafür gibt es ja eben die diversen Zwischenpuffer. Diese Puffer bewirken ja, dass die Zeitungenauigkeit eliminiert wird.

Den Timestamp brauch ich zur Bestimmung der Start- und Stoppzeit der Lineareinheit. Die Zeitpunkte des Eintreffens der Messwerte sind sehr willkürlich, abhängig von den anderen laufenden Prozessen. Ich sammele Messwerte, versehe sie mit der berechneten Zeitmarke und berechne die passende Position der Lineareinheit dazu, darum muss die Timestamp natürlich passen.

Gruß

Joachim


Nachtrag: Habe es mal getestet. Jeder Aufruf des DAQMX Write erzeugt einen Fehler im Timer von ca. 8µs.