INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

NI-XNET Write miese Verarbeitungszeit



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

30.04.2021, 12:30
Beitrag #1

Msengxxl Offline
LVF-Grünschnabel
*


Beiträge: 20
Registriert seit: Sep 2008

LV2017 & LV2020
2007
DE

78087
Deutschland
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?
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
30.04.2021, 14:07 (Dieser Beitrag wurde zuletzt bearbeitet: 30.04.2021 17:21 von GerdW.)
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 17.398
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: NI-XNET Write ##### unerwartet lange Verarbeitungszeit
Hallo Mseng,

kannst du mal ein Beispiel-VI bereitstellen?

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

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.05.2021, 16:07 (Dieser Beitrag wurde zuletzt bearbeitet: 03.05.2021 16:09 von Msengxxl.)
Beitrag #3

Msengxxl Offline
LVF-Grünschnabel
*


Beiträge: 20
Registriert seit: Sep 2008

LV2017 & LV2020
2007
DE

78087
Deutschland
RE: NI-XNET Write miese Verarbeitungszeit
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.


Angehängte Datei(en)
17.0 .vi  CAN_Example.vi (Größe: 13,8 KB / Downloads: 135)

0.0 .zip  FLS_XnetDB.zip (Größe: 963 Bytes / Downloads: 99)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.05.2021, 18:12 (Dieser Beitrag wurde zuletzt bearbeitet: 03.05.2021 18:14 von GerdW.)
Beitrag #4

GerdW Offline
______________
LVF-Team

Beiträge: 17.398
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: NI-XNET Write miese Verarbeitungszeit
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:
   

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
04.05.2021, 09:50
Beitrag #5

Achim Offline
*****
*****


Beiträge: 4.219
Registriert seit: Nov 2005

20xx
2000
EN

978xx
Deutschland
RE: NI-XNET Write miese Verarbeitungszeit
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

"Is there some mightier sage, of whom we have yet to learn?"

"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
05.05.2021, 09:47
Beitrag #6

Msengxxl Offline
LVF-Grünschnabel
*


Beiträge: 20
Registriert seit: Sep 2008

LV2017 & LV2020
2007
DE

78087
Deutschland
RE: NI-XNET Write miese Verarbeitungszeit
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...
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  XNET Read (Signal XY).vi "time limit" beschreiben andrepf 0 2.269 31.03.2016 10:18
Letzter Beitrag: andrepf

Gehe zu: