LabVIEWForum.de

Hallo Team

Ich hab da mal eine Frage.

Ich habe ein cRIO 9049, in dem (unter anderem) die Module NI9234 (in Slot 1, IEPE AC, alle 4 Kanäle verwendet) und NI9205 (in Slot 2, 12 Kanäle verwendet) stecken.

NI9234 muss mit (ca.) 52 kHz betrieben werden (Beschleunigungsaufnehmer oder Mikrophon), bei NI9205 (diverse AIn) reichen 1kHz, allerdings bevorzugt 1 kHz. Verwendet wird der DAQmx im cRIO.

Diese beiden Module sollen synchron und ohne Phasenverschiebung funktionieren. Das würde dann der Fall sein, wenn beide "exakt" zum selben Zeitpunkt ihren jeweils 1. Samplewert generieren => keine Phasenverschiebung. Ist dann auch noch die Sampletakt-Quelle identisch, sind die beiden Module auch synchron.

Synchronität und (keine) Phasenverschiebung werden dadurch nachgewiesen, dass mittels eines Funktionsgenerators ein Sinus mit 100.00Hz auf jeweils einen Kanal der beiden Module (= zwei Tasks) gegeben wird.

Bisher ist das Ergebnis folgendes:
NI9234 und NI9205 laufen exakt synchron - und zwar immer. Das sieht man in einem Graphen. Allerdings haben die beiden Kanäle eine Phasenverschiebung von (meistens!) (ca.?) 2ms. Beachte: Konstante Phasenverschiebung und synchron bedingen sich gegenseitig.

Ich möchte gerne, dass die Sample-Quelle für NI9205 von NI9234 kommt. Dann wären nämlich Synchronität und keine Phasenverschiebung gegeben. Nach allen meinen Versuchen (einschließlich Nachbildung der Vorschläge von NI) ist es mir bisher nicht gelungen, der NI9205 mitzuteilen, dass es sich nach dem Modul NI9234 zu richten hat. Egal, was ich mache, es kommt immer ein Fehler. Entweder gleich beim Create der Tasks oder spätestens, wenn Samplewerte ausgelesen werden sollen.

Kann mir einer einen Tipp geben, was ich ausprobieren soll, damit NI9205 den Takt von NI9234 übernimmt und dass beide gleichzeitig(!) starten (NI9205 mit 1kHz und NI9234 mit 52kHz) ?

Bisher hab ich alles ohne Waveforms gemacht. Würde die Sache ohne Waveforms funktionieren?

Oder muss ich auf Waveforms umsteigen: Die Phasenverschiebung würde dadurch verschwinden (davon würde ich bisher ausgehen), weil in den Waveform ja der Sample-Zeitpunkt enthalten ist.

Und noch eine Kleinigkeit: Finde ich irgendwo die Belegung des 15poligen Anschlusses in Chassis des cRIO (bzw. Rückseite Module)? - bisher nicht.

Hallo Selbst,

Zitat:Bisher hab ich alles ohne Waveforms gemacht. Würde die Sache ohne Waveforms funktionieren?
Oder muss ich auf Waveforms umsteigen: Die Phasenverschiebung würde dadurch verschwinden (davon würde ich bisher ausgehen), weil in den Waveform ja der Sample-Zeitpunkt enthalten ist.

Wieso sollte die Phasenverschiebung verschwinden?
Jede Waveform hat ihr t0: wenn das t0 der NI9205 ein anderes als beim NI9234 ist, dann bleibt das auch so…

Zitat:Und noch eine Kleinigkeit: Finde ich irgendwo die Belegung des 15poligen Anschlusses in Chassis des cRIO (bzw. Rückseite Module)? - bisher nicht.

Du kannst das MDK (ModuleDevelopmentKit) bei NI kaufen, dann bekommst du natürlich auch die Pinbelegung des Modul-Anschlusses…

Ohne jetzt der Spezialist für DAQmx-Triggerung zu sein: du willst zwei Module synchronisieren, die sehr unterschiedliche ADC-Verfahren verwenden. Das dürfte schwierig werden, was du anhand der Fehlermeldungen deiner DAQmx-Tasks gesehen hast (welche Fehler denn?).

Zitat:Bisher ist das Ergebnis folgendes:
NI9234 und NI9205 laufen exakt synchron - und zwar immer. Das sieht man in einem Graphen. Allerdings haben die beiden Kanäle eine Phasenverschiebung von (meistens!) (ca.?) 2ms. Beachte: Konstante Phasenverschiebung und synchron bedingen sich gegenseitig.

Reicht dir das nicht aus?

Worst case: einen AI des NI9234 auch noch auf dem NI9205 mitmessen (da ist ja noch was frei…) und hinterher per Software die Phasenverschiebung korrigieren…

Beim NI9205 hast du doch einen MUX und damit eigentlich immer eine Phasenverschiebung!?

(20.08.2025 06:35 )GerdW schrieb: [ -> ]Wieso sollte die Phasenverschiebung verschwinden?

Diese Phasenverschiebung beträgt 2000µs - das ist ein Messer, äh eine Phasenverschiebung.

Zitat:Jede Waveform hat ihr t0: wenn das t0 der NI9205 ein anderes als beim NI9234 ist, dann bleibt das auch so…

Das ist richtig - aber: beide Sample-Streams sollen gleiches t0 haben (=> keine Phasenverschiebung). Außerdem werden nicht Waveforms verwendet, sondern bisher nur Arr of double.

Zitat:Du kannst das MDK (ModuleDevelopmentKit) bei NI kaufen, dann bekommst du natürlich auch die Pinbelegung des Modul-Anschlusses…

Kaufen? - Gut, das streichen wir.

Zitat:(welche Fehler denn?).

z.B.: "Diese Timing-Quelle funktioniert nicht". Alles Fehler, bei denen ich mir denke: "Warum denn das? Für was hab ich denn DAQmx?"

Zitat:Reicht dir das nicht aus?

Mir würde das reichen. Außerdem werden die Daten vor dem Speichern (TDMS, Diadem) noch auf 100 Hz reduziert. Was interessieren mich da noch zwei ms? Der Kunde besteht darauf, also bekommt er seinen Willen ...

Zitat:Beim NI9205 hast du doch einen MUX und damit eigentlich immer eine Phasenverschiebung!?

Diese Phasenverschiebung liegt im Bereich um 2µs (wahrscheinlich max. 10µs) - diese Phasenverschiebung interessiert weder mich noch den Kunden. In dem Bereich, in dem diese Phasenverschiebung relevant ist, arbeiten wir überhaupt nicht.

Im übrigen gibt es doch tatsächlich ein NI-Dokument, in dem genau dieser Fall (unterschiedliche ADCs mit DAQmx, unterschiedliche Abtastraten) beschrieben ist und das Konfigurationsbeispiele zeigt. LV-Programer-Netzwerk mit Indien sei Dank ...

Hallo Selbst,

Zitat:Im übrigen gibt es doch tatsächlich ein NI-Dokument, in dem genau dieser Fall (unterschiedliche ADCs mit DAQmx, unterschiedliche Abtastraten) beschrieben ist und das Konfigurationsbeispiele zeigt. LV-Programer-Netzwerk mit Indien sei Dank ...

Könntest du mal einen Link bereitstellen?
Andere haben dieses Problem ja auch immer wieder mal, gerade mit den NI923x-Modulen…

(20.08.2025 18:55 )GerdW schrieb: [ -> ]Könntest du mal einen Link bereitstellen?

Folgendes will ich ausprobieren, da ich vermute, dass das eine Lösung ist.

https://www.ni.com/en/support/documentat...ZGhV9ylppe

Auf dieser Seite herunterscrollen bis "Multichassis, Multi-Rate Synchronization with Mixed Modules (NI-DAQmx 19.5 and later)" und bis "Multichassis, Multi-Rate Synchronization with Mixed Modules (DAQmx 18.6 to DAQmx 19.5)" und bis "Multichassis, Multi-Rate Synchronization with DSA Modules (DAQmx 18.6 and earlier)".

Möglicherweise die Version "DAQmx 18.6 and earlier".

Das wurde vorgeschlagen, von einem Anwender, der sich nachweislich damit auskennt. Nicht vom NI-Support.

Ich bin ja mal gespannt. Immerhin haben wird nur 1 Chassis, ein cRIO. Hoffentlich hat der Anwender auch verstanden, dass wir ein cRIO haben - sehe ich gerade.

(20.08.2025 16:26 )IchSelbst schrieb: [ -> ]interessant ... ich wollte schon fast den Vorschlag machen, das alles per FPGA zu lösen und nicht über DAQmx. Ich kenne allerdings die verwendeten Module zu wenig um beurteilen zu können, ob das auch mit DAQmx machbar ist.

[quote]Der Kunde besteht darauf, also bekommt er seinen Willen ...

Ja, wenn es nicht anders geht ... dann mach mal.

Bei manchen Kunden rennt man gegen eine Betonwand. Ich habe keine Ahnung wie oft ich schon irgendwelchen Schwachsinn implementiert habe (bevorzugt bei Kunden aus aus einem ganz bestimmten Land, welches ich nicht öffnentlich nennen möchte). Bei manch einem Kunden hilft nichts, die können sich das nicht vorstellen. Da helfen die besten Argumente und Erläuterungen nichts. Der Kunde will es haben und sei es noch so Unsinnig. Ich sehe immer vor, dass sich derartiges später wieder leicht entfernen lässt. Irgendwann kommt auch der Kunde darauf, dass das Unsinn ist. Ich hatte erst vor kurzem so einen Fall. Nach 13 Jahren kommt der Wunsch vom Kunden (die gleiche Person), ob man den damals unbedingt gewollten Unsinn nicht entfernen könnte. :-)

(20.08.2025 20:20 )Martin.Henz schrieb: [ -> ]ich wollte schon fast den Vorschlag machen, das alles per FPGA zu lösen und nicht über DAQmx.

Für was hab ich denn DAQmx - um mir die Unmenge an Arbeit zu sparen, die ein FPGA nach sich zieht.

Zitat:Ich sehe immer vor, dass sich derartiges später wieder leicht entfernen lässt.