LabVIEWForum.de

Hallo,

mein Aufbau besteht aus einer NI-6221, die in einem PXI-Chassis unter LabVIEW RT von einem Controller 8184 angesteuert wird. Über einen Analogausgang wird einem Servo eine Solldrehzahl vorgegeben; Position und Drehzahl des Servos werden dann über die beiden Counter der 6221 eingelesen (Zweispur-Encoder; dazu kommen noch ein paar Analog-Eingänge). Die Daten werden nach Abschluss der Messung an den angeschlossenen PC geschickt und da weiter ausgewertet.

[attachment=34032]

Dabei habe ich ein Problem mit dem Timing der Signale: Vergleiche ich die direkt über den Counter gemessene Position mit einem zweiten Positionswert, den ich durch Integration der Drehzahl erzeuge, dann eilt der per Counter gemessene Winkel dem per Integration bestimmten Wert nach (wenn also der Servo z.B. aus dem Stillstand anläuft, dann dauert es nach dem Erfassen der Drehzahländerung noch einige Zeit, bis auch eine Winkeländerung aufgezeichnet wird). Der Zeitversatz ist dabei nicht konstant; ich habe innerhalb einer Messung schon Werte zwischen 30 und 170 ms gesehen. Er scheint mir allerdings irgendwie vom Drehzahlgradienten abhängig zu sein.
Ein Vergleich der Analogsignale mit der Drehzahl und dem per Counter gemessenen Winkel zeigt, daß die Drehzahl mit den Analogsignalen "in Phase" ist; der per Counter gemessene Winkel dagegen hinkt den übrigen Signalen hinterher.

Leider ist das Ermitteln des Winkels per Integration der Drehzahl für die Messungen keine Option, da ich die Drehzahl nur als Absolutwert gemessen bekomme - die Drehrichtung kann sich während der Messung jedoch ändern, und der Winkel ist relevant für die Auswertung. Es ist daher erforderlich, den Winkel zeitrichtig mit den anderen Signalen zu messen.

Hat evtl. jemand eine Idee, woran dieser Zeitversatz liegt, bzw. wie er zu beseitigen ist?

Danke schonmal!

Hi,

ich versteh jetzt nicht wirklich, warum du den Positionswert "hintenrum" durch Berechnung erfasst...wo du doch den Winkelwert offenbar direkt messen kannst...

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?

Hab ich was missverstanden?

A.

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.

Hallo,

- die beiden Counter Task sind nicht synchronisiert. Möglich dass dadurch eine Zeitverschiebung resultiert
- die Messung ist überall auf "kontinuierlich" gestellt obwohl es sich um eine Finite handelt
- bei einen gepufferten analogen Output werden zuerst die Daten geschrieben, dann erst der Task gestartet (siehe Example Finder). Zudem wird ein leerer 1D Array auf den AO geschrieben (?)
- für was ist die for-Loop gedacht. Das Timing in dieser for-Loop ist überflässig, da ja die DAQmx VIs (Timing VI) das Timing vorgibt

Schwierig zu beurteilen was da schief läuft. Vielleicht hilft es den einen oder anderen Punkt oben besser zu machen.

Grüsse,
cheggers

Hallo,

auch Dir vielen Dank für Deine Unterstützung.

(07.06.2011 20:27 )cheggers schrieb: [ -> ]- die beiden Counter Task sind nicht synchronisiert. Möglich dass dadurch eine Zeitverschiebung resultiert

Leider beschwert sich LabVIEW, wenn ich den Frequenz-Task per Sample Clock-Timing betreiben will - die Hardware kommt mit der Betriebsart dann nicht klar. Daher bin ich hier leider auf implizites Timing festgelegt, womit an sich ein Zeitversatz zwischen der Frequenzmessung und den Analog-Eingängen möglich ist. Wobei dieser - da es sich ja um einen Offset der Task-Startzeitpunkte handelt - konstant sein müsste; mein Offset ist dagegen zeitlich variabel...
Interessanterweise passt der Frequenz- bzw. Drehzahltask gut mit den Analogeingängen zusammen. Ärger macht der Winkel-Task, der ja per Sample Clock-Timing synchron mit dem AI-Task läuft...

Zitat:- die Messung ist überall auf "kontinuierlich" gestellt obwohl es sich um eine Finite handelt

Letztendlich ist doch jede Messung finit - oder sind Messysteme, die bis in alle Ewigkeit weiterlaufen, schon erfunden? ;-)
Ich habe mich hierbei (LabVIEW-Einsteiger...) an diversen Beispielen aus dem Example Finder und Codeschnipseln aus dem Netz orientiert; in den Fällen war das Timing immer auf "kontinuierlich" gestellt, wenn die Daten in einer Loop angefragt wurden (dazu weiter unten mehr).
So, wie ich das verstanden habe, läuft ein "kontinuierlicher" Task ab dem Starten des Tasks weiter, bis er dann explizit per "DAQmx Clear Task" beendet wird; ein "finiter" Task beendet sich dann - ebenfalls nach meinem Verständnis - selbst, wenn er die angegebene Anzahl an Samples aufgenommen hat.

Zitat:- bei einen gepufferten analogen Output werden zuerst die Daten geschrieben, dann erst der Task gestartet (siehe Example Finder). Zudem wird ein leerer 1D Array auf den AO geschrieben (?)

Das leere Array ist gewissermaßen ein Platzhalter für das Array, das da tatsächlich geschrieben wird - so, daß man erkennen kann, auf welche Weise der Write-Block mit Daten versorgt wird. Ich hatte aus hoffentlich verständlichen Gründen keine große Lust, hier ein Array mit ~90.000 Elementen in den Screenshot einzubauen...

Es gibt im selben Prüfaufbau auch eine weitere Messart, bei der die Länge der Messung nicht vordefniert ist, sondern allein von Benutzereingaben abhängt. Das können dann wenige Sekunden sein - oder auch mal eine halbe Stunde oder noch länger... Wenn ich die Daten vor dem Start des Tasks in einem Rutsch an den DAQmx Write übergebe, dann müssen diese Daten (20.000 Samples pro Sekunde) ja irgendwo gepuffert werden. In den FIFO der Messkarte passen sie wohl eher nicht, es muß also der RAM des Rechners sein - und der ist (auf dem hier vorliegenden PXI-Controller) ohnehin nicht all zu üppig.
Daher werden für diese Messart dann die Drehzahlvorgaben zur Laufzeit in der Mess-Loop erzeugt (durch ein Sub-VI); ergo muß da (für diese Messart) ein Write-Block in die Loop herein (es müssen ja in jedem Durchlauf die frisch erzeugten Werte geschrieben werden). Da ich eine gemeinsame grundlegende Struktur für alle Messarten haben wollte (das reduziert den Wartungsaufwand), ist auch in der hier geposteten Messung eben der Write-Block in der Loop enthalten (obwohl hier die zu schreibenden Daten außerhalb der Loop vordeiniert sind).
Ich meine, auch ein entsprechendes Beispiel mit DAQmx Write in einer Schleife im Example Finder gesehen zu haben...

Zitat:- für was ist die for-Loop gedacht. Das Timing in dieser for-Loop ist überflässig, da ja die DAQmx VIs (Timing VI) das Timing vorgibt

Ohne Schleife habe ich es nicht hinbekommen, daß LabVIEW mir die Kanäle gleichzeitig aufzeichnet. LabVIEW hat dann immer zuerst den ai Task abgearbeitet; dann, wenn dieser durch war, den ao-Task; wenn dieser abgeschlossen war, wurden Winkelmesswerte aufgenommen; und wenn diese allesamt im Kasten waren, kam die Drehzahlmessung. Dabei steht der Aufbau also während der Datenerfassung still,. und nur dann, wenn gerader nichts gemessen wird, dreht er - das ist so nicht gedacht!
Die Schleife macht jetzt zweierlei:
- Zum Einen stellt die Schleife an sich eine Art "atomare Einheit" dar - soll heißen, es wuird erst der Code vor der Schleife abgearbeitet, dann die Schleife, und dann der Code nach der Schleife. Im Ergebnis werden also erst alle Tasks eingerichtet & gestartet, dann kommt die Schleife, und erst nach Schleifenende werden die Tasks beendet. Es sind also während die ASchleife läuft schon mal alle Tasks zeitgleich aktiv.
- Zum Anderen holt die Schleife von jedem Task in regelmäßigen Abständen die aufgelaufenen Messwerte ab - so kann ein einzelner Task nicht den FIFO der Karte vollschreiben, und die Messung kann weiter laufen, bis die Schleife letztendlich abgearbeitet ist.

Ich hoffe, ich habe da nicht all zu viele Denkfehler drin - lasse mich aber auch gerne eines Besseren belehren! ;-)

Hallo,

ich habe das VI zuwenig ganau angeschaut .

Bis auf den impliziten Counter starten alle gleichzeitig und haben auch die gleiche Sample-Clock-Source (freq-out). Die beiden Zähler-Tasks starten zu unterschiedlichen Zeiten, der Zeitversatz ist wohl aber eher quasikonstant, da der Start-Trigger (mit dem Start-VI ausgelöst) per Software abgefeuert wird was ja bekanntlich relativ starken Jitter ausgesetzt ist.
In der for-Loop werden die Lese-Funktionen aber sequenziell ausgeführt (durch den Error-Cluster bestimmt). Zudem hast du in der For-Loop das angesprochene SW-Timing, welches man nicht mit HW-Timing mischen sollte. Ich denke aus diesen beiden Punkten könnten schon solche Probleme auftauchen.

Könntest du versuchen den Error-Cluster einmal pro Task durchschlaufen? Dann würden die Lesefunktionen "paralleler" ausgeführt werden. Zudem noch das SW-Timing aus der For-Loop rausnehmen.

Schwierig aus dem Stehgreif zu sagen ob das etwas verbessert. Viel Erfolg!

Grüsse,
cheggers

Zuerst mal:


KLUGSCHEISS_MODUS ON

Es heißt "Stegreif"

KLUGSCHEISS_MODUS OFF



Jetzt zum Thema:

Vielleicht ist folgende Anregung ganz nützlich...Ich hatte mal ein ähnliches Problem: Es mussten zwei Counter absolut synchron laufen, damit man feststellen konnte, wieviele Counts (Signale eines Sensors) von Counter 1 gezählt wurden, während Counter 2 ebenfalls gezählt hat (= Bruchteile einer Umdrehung eines Motors A). Der Motorgeber hat z.B. 1024 Peaks/Umdrehung ausgegeben, und der Sensor musste in der gleichen Zeit z.B. 96 Peaks liefern...

Die Synchronisierung lief dann folgendermaßen:

Ausgeben eines "Pulse train" mit Counter 1 auf PXI-Karte A, routen dieses Signals über "PXI_Trig0" als Taktgeber auf Counter 2 und Counter 3 auf PXI-Karte B, starten der beiden Counter 2 + 3 durch einen Triggerpuls (DO) von PXI-Karte A auf "PXI_Trig1"

Karte A: PXI-6251
Karte B: PXI-6602

Gruß
Achim

Hallo zusammen,

das Durschleifen des Fehlerclusters durch die einzelnen Reads ist durchaus beabsichtigt - auf diese Weise bekomme ich eine definierte Ausführungsreihenfolge in meine Operationen herein. Ohne einen solchen "Zwang" legt LabVIEW die Reihenfolge ja eher willkürlich fest; ich weiß nicht, ob es da evtl. zwischen zwei Schleifendurchläufen zu unterschiedlichen Reihenfolgen kommen könnte, was dann auch wieder eine Fehlerquelle wäre.
Zur Parallelität: Das Ganze läuft auf einem Embedded PXI-Controller (8184); auf diesem sitzt ein 850-MHz-Celeron - also eine Single-Core-CPU, die auch nur einen Thread zur Leit laufen lassen kann (Sollte ich mich irren, dann korrigiert mich bitte - ich bin nue dummer Maschinenbauer und kein Computermensch!). Von daher sollte doch ohnehin nur ein Block zur Zeit ausführbar sein, bzw. die Blöcke müssten einer nach dem Anderen abgearbeitet werden?!? Denn: Wenn die Hardware das parallele Ausführen mehrerer Codezweige nicht hergibt, dann kann ich auf Softwareebene so viel parallelisieren, wie ich will...

Einen weiteren Counter hinzunehmen kann ich leider auch nicht, da beide Counter "meiner" 6221 schon belegt sind. Den Messtalt erzeugt sich diese Karte selbst über den "freqout"-Ausgang, der dann auf der Karte auf eine Triggerleitung geroutet wird; diese ist dann auf den Takt-Eingang der Timing-VIs der einzelnen Tasks gelegt. Auf diese Weise sollten an sich die ai-, ao- und Winkeltasks schon synchrin laufen (zumal der Messtakt als erst nach diesen Tasks gestartet wird).

Wie dem auch sei, ich war nicht nur in diesem Forum hier unterwegs, sondern auch noch andernorts - das Problem ist mittlerweile gelöst: http://forums.ni.com/t5/Multifunction-DA...-p/1587230

Vielen Dank nochmal allen Helfenden für ihre Unterstützung!