Problem mit schneller (!) Messung

Liebe LabView-Gemeinde,

zuerst möchte ich ein großes Lob an dieses Forum richten! Ich bin seit etwas über einem Jahr mit LabView in Kontakt und wäre ohne Euch niemals klargekommen – also vielen Dank dafür! Meine bisherige stumme Teilnahme an diesem Forum reicht nun leider nicht mehr aus, so dass ich mich mit meinem Problem an Euch wende, bevor ich den (mutmaßlich kostspieligen) LabView-Support kontaktiere.

Ich betreue einen Prüfstand, dessen Messwerterfassung mit LabView realisiert wird. Vor einiger Zeit haben wir neue Rechner (Win XP) angeschafft und wollten in diesem Zuge auch die verwendete Software aktualisieren. Somit habe ich begonnen, die (sehr umfangreichen) Programme von LV 6 auf LV 8.5 zu portieren. Im Grunde bin ich soweit erfolgreich, nur steckt ein Problem im Kern der Sache: der Messwerterfassung.
Meine Messkarte ist die „NI PCI 6071E“, mit einer maximalen (Nenn-)Messgeschwindigkeit von 1,25 MS/s. Getriggert wird mit der Drehung einer Prüfwelle. Mit jeder Umdrehung stehen ein einmaliger sowie 240 gleichmäßig verteilte Impulse zur Verfügung. Der Einmal-Impuls startet die Messung von 240 Werten, die mittels der 240-Impulse gleichmäßig verteilt über eine Wellenumdrehung aufgenommen werden. Die Karte soll nun 13 Kanäle 240-mal pro Wellenumdrehung differentiell abfragen. Bei einer maximalen Drehzahl von 4000 U/min sind dies m.E. 4000/60*240*13 S/s = 208000 S/s = 0,208 MS/s. Schon bei der ersten Inbetriebnahme (vor meiner Zeit), bereitete die Messgeschwindigkeit Probleme (-> Stichwort Pufferüberlauf). Man fand damals heraus, dass „dieser Messmodus…“ seitens NI „… nicht empfohlen“ wird. Ein sehr fähiger Mitarbeiter (mittlerweile leider nicht mehr verfügbar) vollbrachte jedoch das „Unempfohlene“ und brachte die Messungen mit Hilfe der (in LV 6 noch verfügbaren) Einstellung „Channel Time“ zum Laufen. Empirisch (!) ermittelte Werte für die ch.time im Bereich zwischen 8 und 3,9 ms ermöglichten den Betrieb. Diese Channel-Time steht aber in der aktuellen Programmversion (8.5) nicht zur Verfügung; lediglich die „Rate“, die evtl. Ähnliches bewirkt. Die jeweiligen Dokumentationen haben mich jedenfalls nicht weitergebracht. Das Eintragen einer der ch.time entsprechenden Rate sowie umfangreiches willkürliches Ausprobieren brachte keinen Erfolg. Mit „kein Erfolg“ meine ich, dass die Durchlaufzeit eines Messzyklus etwa dem doppelten der Zeit entspricht, die pro Triggerimpuls (-> Wellenumdrehung) zur Verfügung steht – manchmal auch noch mehr. D.h.: es werden Triggerungen „verschlafen“. Dadurch gehen mir mindestens die Hälfte aller Daten verloren! Ich sehe nicht ein, wieso eine Messkarte bei anderer Software(-version) plötzlich weniger leistet.
Daher meine Fragen an die erfahrenen Benutzer: Hat jemand schon ein ähnliches Problem gehabt und lösen können? Gibt es Generelles zu beachten, um die Messgeschwindigkeit zu maximieren, bzw. das Optimum aus dieser Karte rauszuholen?
P.S.: Was ich bereits probiert habe: Ich habe den DAQ-Assistenten durch die entsprechenden einzelnen VIs ersetzt, um die Konfiguration vom eigentlichen Messen (read) zu trennen. So konnte das Auslesen an sich (ohne Konfiguration) allein in einer Schleife stehen -> leider gleich schlechte Durchlaufzeiten.

Vielen Dank im Vorraus an alle, die sich mein Problem wenigsten anhören! Noch dankbarer bin ich ntürlich für alles, was mich weiterbringen könnte.

Grüße,
Kuki


(Angehängt: Abbildung der alten Messkonfiguration)

Ich würde hier nicht nachbesseren, sondern erst mal die Datenerfassung auf DAQmx-Treiber umstellen. Bei Deiner Karte der E-Serie ist das möglich. Für mich war es immer ein Graus, mit diesen alten Treiben arbeiten zu müssen, das Aufkommen der neuen DAQmx-Treiber habe ich als Befreiungsschlag und wichtigen Fortschritt empfunden .
Also: Labview-DAQmx-Beispiele durcharbeiten und dann umstellen. Wenn es dabei Probleme gibt, dann wird Dir hier sicher weitergeholfen.

Hallo Kuki,

unter LV2009 bietet die Funktion "AI Config" noch immer einen Eingang "interchannel delay" an. Dies sollte doch weiterhin deiner "ch.time" entsprechen?

Hast du schon mal versucht, deine Karte mit DAQmx-Funktionen zu verwenden? (Bin mir aber nicht sicher, ob sie von DAQmx unterstützt wird. Edit: Lucki hat's schon erwähnt...)
Der DAQ-Assi baut jedenfalls darauf auf - bringt dir aber nur weiteren Overhead in deine Schleife rein...

"Vielen Dank im Vorraus an alle, die sich mein Problem wenigsten anhören!"
Durchlesen ging dann doch schneller als sich das Ganze anzuhören

' schrieb:(Bin mir aber nicht sicher, ob sie von DAQmx unterstützt wird.)

Doch, E-Serie und DAQmx geht!

Gruß, Jens

Danke ersteinmal an alle für die schnellen Antworten - und natürlich fürs "zuhören"!

Vielleicht habe ich mich etwas ungünstig ausgedrückt. Das Messprogramm ist bereits fertiggestellt -> in LV 8.5. Leider bringt es eben nicht die erwünschte Performance. Ich hänge mal ein paar Bilder der neuen Konfiguration an. Dabei habe ich wie erwähnt bereits zwei verschiedene Möglichkeiten ausprobiert:
1. DAQ-Assistent - ich denke, das ist der Fortschritt, von dem Lucki sprach, oder?!
2. "aufgelöster" DAQ-Assistent - hier konnte ich dann das VI "DAQmx Lesen" isoliert im SubVI "Messen" laufen lassen, ohne die komplette Konifuration mit zu durchlaufen

Sehr interessant finde ich den Beitrag von GerdW (vielen Dank für den Hinweis). Allerdings kommt mir da die Frage: Gibt es die Funktion "AI Config" auch in LV 8.5? Die ist mir nämlich bis jetzt nur aus LV 6 bekannt. Ansonsten müsste ich auf LV 2009 upgraden. Wenn das mein Problem löst (also wenn die ch.time dann wieder verfügbar wäre, was in mir große Hoffnungen weckt), wäre ich dazu bereit.

Gruß,
Kuki

Hallo Kuki,

"Allerdings kommt mir da die Frage: Gibt es die Funktion "AI Config" auch in LV 8.5? Die ist mir nämlich bis jetzt nur aus LV 6 bekannt."
Der in meinem LV2009 installierte TraditionalDAQ-Treiber verwendet VIs, die noch mit LV7.0 erstellt wurde. Von daher sollten die gleichen VIs auch in LV8.5 zur Verfügung stehen, sobald man dort auch den TraditionalDAQ-Treiber installiert...

"1. DAQ-Assistent - ich denke, das ist der Fortschritt, von dem Lucki sprach, oder?!"
Das kann ich mir beim besten Willen nicht vorstellen:)Lucki bezog sich wohl eher auf den DAQmx-Treiber im Allgemeinen...

Anzeige

' schrieb:"1. DAQ-Assistent - ich denke, das ist der Fortschritt, von dem Lucki sprach, oder?!"
Das kann ich mir beim besten Willen nicht vorstellen:)Lucki bezog sich wohl eher auf den DAQmx-Treiber im Allgemeinen...

Genau so ist es. DAQmx ist ein Fortschritt, aber gleichzeitig damit ist leider auch der DAQmx-Assistent hinzugekommen, mit dem bei Anfängern mehr Unheil als Nutzen gestiftet wird. (Meine rein persönliche Meinung, und wenn ich ihn mal selbst verwenden sollte, dann ist das natürlich etwas gaaanz anderes.. )

' schrieb:Genau so ist es. DAQmx ist ein Fortschritt, aber geleichzeitig damit ist leider auch der DAQmx-Assistent hinzugekommen, mit dem bei Anfängern mehr Unheil als Nutzen gestiftet wird. (Meine rein persönliche Meinung, und wenn ich ihn mal selbst verwenden sollte, dann ist das natürlich etwas gaaanz anderes.. )

Ja, wurde mir dann auch klar, als ich es nochmal las.

Aber nochmal zu meinem "Strohhalm" AI Config: Ich find es einfach nicht. Hab jetzt die Traditional Treiber nachinstalliert. Zusätzliche VIs sind mir bis jetzt allerdings nicht über den Weg gelaufen. Dann habe ich das "AI Config", das ich aus den alten Programmen (LV 6) extrahiert habe, in mein neues Programm geschmissen und siehe da: ein Bluescreen. Lange nicht gehabt sowas.
Ich geb jetzt auf für diese Woche. Vielleicht komm ich am Montag "in alter Frische" weiter (ist auch viel zu heiß im Moment...).

Ein schönes Wochenende allerseits!

Guten Tag zusammen!

Kurzes Update meinerseits: Es hat zwar nahezu den ganzen Tag gedauert, aber jetzt begrüße ich endlich die traditionellen Treiberbausteine in meiner Funktionen-Palette. Ich habe dazu LV komplett de- und reinstalliert - diesmal MIT den traditionals. Es geht wohl aber auch so: http://digital.ni.com/public.nsf/allkb/7B9...62574BB000E2AB5

An diese Anleitung werde ich mich dann auch Morgen halten, wenn ich die auf die traditionellen Treiber umgestellten Programme am Prüfstand auf ihre Performanz testen werde. Ich werde von meinen Fortschritten (ggf. auch von Rückschritten) berichten.

Viele Grüße,
Kuki

Hallo zusammen,

ich bringe diesen Beitrag mal wieder nach vorne. Zwar hatte ich in den vergangenen Monaten einfach nicht die Zeit, mich weiter um mein Problem zu kümmern, jedoch hat es sich leider nicht in Luft aufgelöst... In der Zwischenzeit hatte ich allerdings Kontakt zu gleich mehreren NI-Support-Mitarbeitern (inkl. Hausbesuch!). Dieser war wider meiner ursprünglichen Vermutung sogar kostenlos. Die Schlussfolgerung ist im Übrigen die folgende: Die neue Struktur (DAQmx vs. traditional) in Form eines Zustandsautomaten verhindert scheinbar leider grundsätzlich das von mir geplante Mess-Vorgehen (das vor Monaten beschriebene Trigger-Konzept), bzw. dessen ausreichende Performanz.
Ich fasse noch einmal zusammen: Ich habe einen "Hauptimpuls", der die Messung starten soll (1 Umdrehung einer Messwelle). Ein weiterer Impuls vom gleichen Drehgeber taktet 240-mal so schnell. Zu jedem dieser schnellen Impulse (alle 1,5°) soll je ein Wert pro Kanal aufgenommen werden.
Der workaround vom Support sieht folgendes vor: (Originalzitat vom Support)
"Oeffnen Sie dazu bitte aus LabVIEW den Example Finder (unter Hilfe) und waehlen dort den Baumeintrag Hardware Input and Output >> DAQmx >> Synchronization >> Multi-Function. Darin sollte ein Beispiel namens "Multi-Function-Ctr Pulse Train Generation for AI Sample Clock.vi" zu finden sein. Dieses Beispiel zeigt genau das Vorgehen, das ich Ihnen als Alternative vorstellen moechte.
Nach wie vor halte ich jedoch (sofern der "Z-Impuls" eine hinreichende Laenge hat) eine reine Softwareauswertung fuer die sicherste Loesung, Fehlpulse zu erkennen. Hierzu muessen Sie die derzeitige Erfassung lediglich auf kontinuierlich umstellen und entsprechend die Datenpakete nach dem "Z-Kanal" [...] analysieren: Die steigende Flanke eines Pulses dieses Kanals repraesentiert Ihnen die 0°. Wenn bis zum naechsten Puls auf diesem Kanal mehr als 240 Takpulse lagen, koennen Sie davon ausgehen, dass es zu Fehlpulsen kam und Sie koennen diese Umdrehung verwerfen.
Die Schwierigkeit in diesem Ansatz liegt darin, dass Sie paketuebergreifend eine solche Analyse machen muessen. Aber mit einem entsprechenden Ansatz ist dieses wahrscheinlich auch "online" (also parallel zur Erfassung) moeglich. Der Schluessel liegt dabei darin, Erfassung von der Verarbeitung/Speicherung zu entkoppeln. Nutzen Sie hierfuer bitte das Design Pattern "Producer/Consumer Desing Pattern (Data)" aus dem Template Browser. Diesen oeffnen Sie, indem Sie in LabVIEW "Datei >> Neu" anwaehlen."

Soweit so gut - der Plan ist mir klar. Nun also zu meinen Unklarheiten, bei denen ich auch Eure Hilfe hoffe
1.) Es wird mir empfohlen, die Messung auf kontinuierlich umzustellen. Gebe ich damit meinen Referenz-Trigger (die 240 Pulse) auf? Dies wäre nicht vertretbar, denn ich brauche die Winkelzugehörigkeit!
Ich verstehe einfach das Beispiel (Multi-Function-Ctr Pulse Train Generation for AI Sample Clock.vi) nicht.
2.) Wieso erhalte ich Messergebnisse, obwohl das Triggersignal gar nicht läuft (es dreht sich definitiv nichts - der Motor hat keinen Strom)? Es ist doch gerade der Trigger, der die "Messgeschwindigkeit" vorgeben soll und NICHT die anzugebende Rate. Wieso stelle ich überhaupt Trigger ein, wenn diese den Vorgang scheinbar gar nicht beeinflussen (bzw.: Was mache ich falsch?)?
3.) Wieso kann ich keine Schleife um "DAQmx - Lesen" legen? Dann erhalte ich keine Ergebnisse.

Ich hoffe ich stelle mich einfach nur zu blöd an... Scheinbar habe ich grundlegende Verständnisprobleme^^
Ich hänge das Beispiel VI mal an und hoffe auf Eure Kommentare.
Vielen Dank dafür im Voraus!!!

Beste Grüße,
Kuki

P.S.: LV-Version 8.5