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
/
Problem mit schneller (!) Messung
