NI-XNET Write miese Verarbeitungszeit

Hallo,
ich möchte per X-NET im Signal Single Point Modus Daten alle 5 ms auf den Bus legen. Das Signal ist in der X-Net DB zyklisch alle 5ms eingestellt). Allerdings habe ich schon das Problem, dass, wenn ich das Write-Kommando in eine Schleife packe, die Ausführungszeit stark schwankt (zwischen 5ms und 35ms !). Es laufen keine anderen Prozesse parallel und der Rechner ist eine hochperformante Workstation.
Mir ist klar, dass 5ms auf Windows-Basis relativ sportlich sind.
Eine Ixxat-USB2Can-Schnittstelle schafft die gleiche Schleife absolut problemlos in 5ms. Ich habe auch andere Modi getestet z.B. Frame Stream Mode mit dem gleichen Ergebnis.

Woran kann das liegen? Ist das normal? Oder betrifft das unsere Kombination aus cDAQ-9174 Rack und der NI 9860 Can-Schnittstelle? Kann diese Kombi das Ganze evtl. gar nicht schneller bearbeiten ?

Vielleicht hatte schon mal jemand ein ähnliches Problem?

Anzeige

Hallo Mseng,

kannst du mal ein Beispiel-VI bereitstellen?

Machst du das immer noch mit LV8.6? (evtl. )

Hi,

ups: ist mir bisher nicht mal aufgefallen, dass mein Profil immer noch auf LV 8.6 stand...Wie die Zeit vergeht ;-). Hab's geändert.

Wie auch immer: Im Prinzip ist das bei mir in jedem X-Net Beispiel dasselbe. Aber im Anhang mal ein einfaches VI für den Output Single Point Modus.
Das Problem besteht aber eigentlich in jedem Modus (außer beim Queued vermutlich).

Ich vermute stark, dass es eher am cDAQ-9174 liegt und die Daten nicht schnell genug auf den Bus geschrieben werden.

Hallo Mseng,

Zitat:Im Prinzip ist das bei mir in jedem X-Net Beispiel dasselbe. Aber im Anhang mal ein einfaches VI für den Output Single Point Modus.
Das Problem besteht aber eigentlich in jedem Modus (außer beim Queued vermutlich).

Ich vermute stark, dass es eher am cDAQ-9174 liegt und die Daten nicht schnell genug auf den Bus geschrieben werden.

Wenn das Gerät über USB angebunden ist, kann das bei 200Hz schon eine Limitierung/Fehlerquelle bedeuten…

Ich habe noch nicht wirklich mit XNet gearbeitet, aber könntest du nicht den "Signal Output Waveform Mode" verwenden, wenn du variable Daten mit 200Hz ausgeben willst?

Theoretisch könnte sich das Timing etwas verbessern, wenn du so vorgehst:
   

Mal ganz allgemein:
Unter Windows zuverlässig im 5ms Takt "irgendwas" machen, ist wie du sagst utopisch.

Wenn man eine Botschaft/ein Signal zyklisch senden will, dann stellt man das entsprechend als Zykluszeit ein, und ab dann macht das der Treiber bzw. das Ausgabemodul absolut zuverlässig. Dafür gibts Beispiele, und die sollten funktionieren.

Musst du tatsächlich alle 5 ms einen neuen Wert ausgeben? Du gibst offenbar einen Sollwinkel vor, also steuerst (regelst?) du irgendwas? Bei nem Winkel, der sich alle 5 ms ändert, steht vermutlich eine drehende Welle hintendran. Wenn du so schnell nen neuen Winkel vorgeben willst, musst du vermutlich passene HW verwenden...nen passenden Regler, z.B. vom Antriebshersteller oder als FPGA-Code. Ich vermute, das geht so unter Windows nicht. Mich wundert, dass irgend ne andere HW das über USB zuverlässig/regelmäßig schafft. Und überhaupt es erscheint mir auch irgendwie fragwürdig, aus nem PC-Programm solche Vorgaben zu machen.


Gruß
Achim

Hi Achim,

danke für deine Antwort. Klar, 5ms sind schon grenzwertig. Aber 35ms Ausführung für einen Schreibbefehl finde ich trotzdem zu lange.
Es könnte sein, dass die andere Schnittstelle, die ich benutzt hatte ebenfalls die 5ms nicht immer 100% einhält, aber da läuft die Bewegung (gefühlt) schon sehr sauber ab. Über die NI-Schnittstelle fängt das ganze immer nach kurzer Zeit an zu ruckeln.
Zur Erklärung: die Applikation ist ein Fahr-Lenk-System, was über eine CAN-PDO einen Soll-Lenkwinkel und eine Soll-Drehzahl alle 5ms bekommen soll. Das System hat (noch) keinen internen Rampengenerator. Also muss ich dafür sorgen dass ich die Rampe für Lenken und Fahren vorgebe und gewisse Limits einhalte z.B. maximale Lenkwinkeländerung in° / s = 90°/s.

Wie du sagst: es wäre möglich den Frame Output Queued Modus zu benutzen und meine gesamte Rampenfunktion im Vorfeld zu generieren und dann erst mit der vordefinierten Zykluszeit von 5 ms sequentiell auf den Bus rauszufeuern. Aber da wäre die Anzahl der Frames die in das Array gepackt würden ziemlich hoch (bei sehr langsamen Rampen). Die Queue hat ja auch eine maximale Anzahl Frames.
Aber das wäre vielleicht trotzdem der korrekte Weg...