Zeitversatz zwischen Drehzahl- und Winkelmessung

Hi,

und danke für Deine Antwort!

(31.05.2011 10:56 )Achim schrieb:  ich versteh jetzt nicht wirklich, warum du den Positionswert "hintenrum" durch Berechnung erfasst...wo du doch den Winkelwert offenbar direkt messen kannst...

Das direkte Mesen des Winkels per Counter ist ja auch der Plan. Allerdings hat der so gewonnene Winkel einen nicht konstanten Zeitverzug zu den anderen gemessenen Kanälen.
Die Berechnung "hinten rum" (per Integration der Drehzahl) habe ich dann mal experimentell durchgeführt, um nachzuprüfen, ob evtl. beide Counter-Tasks von diesem Versatz betroffen sind (es ist nur der Winkel-Task betroffen, die Drehzahlmessung erfolgt ohne Zeitverzug gegeüber den Analogkanälen).

Einer der Analogkanäle liefert z.B. ein periodisches Signal mit 5 Perioden pro Umdrehung (das ist so durch die Konstruktion des Prüflings vorgegeben); das Signal sollte sich also - gegen den Winkel geplottet - alle 0,2 Umdrehungen wiederholen, und zwar unabhängig von der Drehzahl.
Fahre ich den Aufbau jetzt bei konstanter Drehzahl und schließe daran unmittelbar eine fallende Drehzahlrampe an, dann wiederholt sich das Analogsignal - gegen den direkt gemessenen Winkel geplottet - während der konstanten Drehzahl alle 0,2 Umdrehungen; sobald die Drehzahl sich ändert, wird der Plot jedoch entlang der Winkelachse gedehnt.
Mit dem per Integration bestimmten Winkel tritt dieses Verhalten nicht auf, hier wiederhot sich das Analogsignal tatsächlich alle 0,2 Umdrehungen, egal, wie schnell der Aufbau dreht.
Plottet man den gemessenen Winkel dann zusammen mit dem berechneten Winkel gegen die Zeit, so wird deutlich, daß der gemessene Winkel nacheilt (Plots zur Verdeutlichung reiche ich ggf. nach).

Wie schon geschrieben, bin ich auch auf eine direkte Winkelmessung angewiesen, da bei der Bestimmung "hinten rum" die Drehrichtung nicht berücksichtigt wird - die von der 6221 gemessene Drehzahl/Frequenz ist ein Absolutwert, natürlich ohen Richtungsinformation (wie es sich für eine Frequenz gehört... ;-) ).

Zitat:Hat es in deinem Aufbau (Blockdiagramm) einen speziellen Grund, warum du dir einen Messtakt erzeugst, diesen dann aber nur für einen den beiden Countertasks (Winkel) verwendest? Sollten für eine synchrone Messwertaufnahme nicht auch beide Counter gleich getaktet werden?

Sollten schon - allerdings kann die 6221 scheinbar keine gepufferte Frequenzmessung. Alle Versuche, eine solche einzuführen, werden mit einer Fehlermeldung quittiert, daß für diesen Task kein Sample-Takt-Timing möglich sei.
Beim Filtern der Beispiele nach Messhardware sagt mir der Example Finder auch, daß die Beispiele für gepufferte Frequenzmessungen nicht auf der 6221 laufen; hier scheint also die 6221 nicht die optimale Lösung zu sein (ich habe allerdings keine Möglichkeit, eine andere Karte zu nutzen).
Das, was da im Frequenz-Kanal nach dem DAXmx Read kommt, bestimmt mir jetzt die mittlere Drehzahl aus dem letzten Schleifendurchlauf, erstellt daraus ein Array von 20 Elementen (1 kHz "Schleifentakt", 20 kHz Abtastrate -> 20 Samples/Loop), und gibt dieses dann weiter - oder gibt alternativ die Frequenz aus dem letzten Schleifendurchlauf weiter, falls es kein Update gab (bei sehr niedrigen Drehzahlen). Neue Drehzahlwerte bekomme ich also nur 1x pro Loop - was auch die recht kurze Loop-Dauer von 1 ms erklärt; so bekomme ich eben möglichst viele Updates. Aufgrund der Trägheit der Mechanik kann ich damit aber sogar leben... ;-)
Das nur zur Erklärung, mein eigentliches Problem ist ja der Zeitverzug beim direkt gemessenen Winkel.