FIFO Benutzung

' schrieb:Morgen.

Also Das Beispiel von i2dx scheint ja nicht schlecht zu sein nur für meine Verhältnisse zu kompliziert. Vom FPGA.vi werde ich mir bestimmt noch was abgucken.
Also freedive hat was von einem FPGA-Wizard geschrieben und Schleifen die man zeitkritisch priorisieren kann. Wo finde ich denn diesen Wizard und wo stellt man da was kritisches ein?
Gunni

nuja - ich bin auch FPGA-Anfänger, nur sind bei mir die Drähte gerade

was da drin ist, hab ich mir aus dem Examples abgeschaut - ob das nun alles so richtig ist ... ?? ... ich bin gerade dabei das zu klären

Anzeige

Zwischenergebnis- aka "war selber blöd"

2 Kanäle @ 100 kHz kann man sehr wohl per DMA vom FPGA zum RT-Host schaufeln, das Problem (in meinem Beispiel) ist (noch?!?), dass ich die Daten mit 100 kHz nicht vom RT-Host zum PC geschaufelt bekomme. TCP ist wohl zu langsam und bei UDP ist der Datenblock zu groß. Die Datenblöcke in entsprechende Häppchen aufzuspalten bedeutet wieder um, dass Rechenzeit verschwendet wird ...

Ich hab mein Beispiel so umgestrickt, dass man mal was sieht. Die *besten* Ergebnisse (sprich, konstante LoopTime und wenig Backlog) habe ich erzielt, wenn ich den DMA-Puffer auf 16384 Bytes eingestellt habe und Blöcke von 8192 Bytes ausgelesen habe, dann war quasi kein Backlog mehr erkennbar (bei Hardware-Timing) bzw. Software-Timing mit 20 Hz Loop-Rate war auch kein Problem.

@freedive: Neu in dem Beispiel ist auch ein "TCP Speed test" und da hab ich festgestellt, dass ich per TCP zum PC nur max. 14 kB pro Sekunde schaufeln kann. Kann das sein?


  crio_01.zip (Größe: 467,49 KB / Downloads: 532)

Hallo.

i2dx hat da son ne Geschichte mit der calibration in sein FPGA.vi eingebaut. Macht das jedes Gerät automatisch? Dann kann ich es doch auch für mich mit meinen Modulen benutzen, oder?
Da es in vielen NI-Beispielen verwendet wird, scheint es von Bedeutung zu sein.


Gunni

' schrieb:Hallo.

i2dx hat da son ne Geschichte mit der calibration in sein FPGA.vi eingebaut. Macht das jedes Gerät automatisch? Dann kann ich es doch auch für mich mit meinen Modulen benutzen, oder?
Da es in vielen NI-Beispielen verwendet wird, scheint es von Bedeutung zu sein.
Gunni

ich habs auch aus den Beispielen. Ich hab auch in meinem RT VI den Link zu einem Artikel auf ni.com hinterlegt, wo das ganze nochmal erklärt wird. Mir war am Anfang auch nicht klar, warum man jeden Wert erstmal mit 10^-9 multiplizieren muss, bis ich rausgefunden habe, dass die Kalibrierdaten in Nanovolt angegeben sind, etc ...

So wie ich das bisher verstehe sind in jedem Modul die Kalibrierdaten hinterlegt - sofern es etwas zum Kalibrieren gibt. Bei DIO Modulen gibt es sowas meines Wissens nicht.

' schrieb:ich habs auch aus den Beispielen. Ich hab auch in meinem RT VI den Link zu einem Artikel auf ni.com hinterlegt, wo das ganze nochmal erklärt wird. Mir war am Anfang auch nicht klar, warum man jeden Wert erstmal mit 10^-9 multiplizieren muss, bis ich rausgefunden habe, dass die Kalibrierdaten in Nanovolt angegeben sind, etc ...

So wie ich das bisher verstehe sind in jedem Modul die Kalibrierdaten hinterlegt - sofern es etwas zum Kalibrieren gibt. Bei DIO Modulen gibt es sowas meines Wissens nicht.

Morgen.

i2dx hast du es auch mal mit anderen Methoden probiert die Daten vom RT Host zum PC Host zu transportieren - gab es, wenn ja, eine erfolgversprechende darunter? Ich habe nämlich gestern mal durch die Beispiele geguckt und bin da auch auf deine TCP/IP-Geschichte getroffen. Das wirkt mir so kompliziert und ich habe gar nicht erkannt ob da was zwischen gepuffert wird. Hast du es schon mal mit den RT FIFOs probiert, die mir freedive vorgeschlagen hat?


Gunni

' schrieb:i2dx hast du es auch mal mit anderen Methoden probiert die Daten vom RT Host zum PC Host zu transportieren - gab es, wenn ja, eine erfolgversprechende darunter? Ich habe nämlich gestern mal durch die Beispiele geguckt und bin da auch auf deine TCP/IP-Geschichte getroffen. Das wirkt mir so kompliziert und ich habe gar nicht erkannt ob da was zwischen gepuffert wird. Hast du es schon mal mit den RT FIFOs probiert, die mir freedive vorgeschlagen hat?
Gunni

So, ich hab ein vorläufiges Endergebnis:

die Erkenntnis dabei ist 1. - es ist manchmal wirklich hilfreich beim Programmieren, wenn man rechnen kann

ok, zu den Fakten: in meinem Speed Test war ein Bug, ich hab multipliziert anstatt zu dividieren. Ich hab ihn nochmal umgeschrieben und komme zu dem Ergebnis, dass man ca. 1200 kB pro Sekunde vom RT-Host zum PC übertragen kann (rote Kurve). Mein Aufbau: PC mit GB Ethernet, 100 MBit Switch full duplex, cRIO 9004 Controler.

   

man muss beim Versenden der Daten schwer darauf achten, dass das Versenden nicht zu lange dauert. Ich habe keine RT-Fifos oder dergleichen ausprobiert, weil die Daten ja sowieso übers Netz müssen. UDP fällt aus, weil die max. Paketgröße von 8192 Bytes pro Datagramm bei der anfallenden Datenmenge überschritten wird, also bleibt nur TCP. Da die einzige Verbindung zwischen RT-Host und PC das Netzwerkkabel ist, müssen die Daten ja irgendwie da durch. Egal welche wie auch immer geartete Funktionalität man nun nutzt, sei es Shared Variables oder sonstiges, die Daten müssen durch dieses Kabel. Um Rechenzeit zu sparen hab ich den niedrigsten mir zur Verfügung stehenden Level gewählt, der mir zur Verfügung steht, und das ist TCP.

Im speziellen muss man sein Timing explizit austüfteln und da wird die blaue Kurve interessant:

   

Wenn man eine Loop Time auf dem RT-Host von ca. 100 ms anstrebt, dann hat man die Qual der Wahl zwischen einer Paketgröße von 32, 64 oder 128 kByte bei annähernd gleichem Durchsatz. Das beißt sich aber mit der anfallenden Datenmenge die vom FPGA kommt. In meinen Tests habe ich rausgefunden, dass ich ein 2 x 2048 Double Array (=32 kB) bei einer Loop-Time von 100 ms sicher zum PC übertragen kann, wobei vom FPGA aber erstmal die vierfache Menge an Daten reinkommt. Man muss hier also reduzieren und da der Controler sowieso schon genug mit Abholen und Verschicken zu tun hat, bleibt einem da eigentlich nur, die Daten bereits auf dem FPGA zu reduzieren.

Das deckt sich im Übrigen auch wieder mit meiner ersten Erkenntnis, dass man bis zu einer Samplerate von 25 kHz 2 Kanäle vom FPGA über den RT-Host zum PC Schaufeln kann[und wenn man bedenkt, dass eine Schaufel ein manuell betriebenes Arbeitsgerät ist, dann ist das schon relativ schnell - als wir vor einem Jahr den Estrich gemacht haben hab ich den Beton mit höchstens 0,1 Hz geschaufelt]

Wie du nun die Daten reduzierst - kann ich dir auch nicht sagen, dazu müsste man wissen wie du die Daten auf dem PC verarbeiten musst. Mein Problem ist erstmal gelöst;)bzw. ich hab aus der Geschichte das gelernt, was ich wissen wollte / das war auch der Grund warum ich mich so intensiv damit beschäftigt habe.


  crio_01.zip (Größe: 485,38 KB / Downloads: 330)

Anzeige

Hat überhaupt schon mal jemand mit den RT FIFOs gearbeitet. Ich habe ein kleines Test.vi gebaut und gemerkt das ich wie bei sämtlichen anderen Sachen den FIFO erst erstelle dann beschreibe oder lese und zum Schluß lösche. Das alles zusammen in einem VI klappt soweit. Nur wie sieht es jetzt aus wenn ich in meinem RT HOST.vi den FIFO erstelle und beschreibe - da kann ich doch auf meinem PC HOST.vi nicht einfach nur das VI "FIFO lesen" benutzen. Ich muss den doch da auch erst anlegen und schon habe ich zwei.


Gunni

' schrieb:Hat überhaupt schon mal jemand mit den RT FIFOs gearbeitet. Ich habe ein kleines Test.vi gebaut und gemerkt das ich wie bei sämtlichen anderen Sachen den FIFO erst erstelle dann beschreibe oder lese und zum Schluß lösche. Das alles zusammen in einem VI klappt soweit. Nur wie sieht es jetzt aus wenn ich in meinem RT HOST.vi den FIFO erstelle und beschreibe - da kann ich doch auf meinem PC HOST.vi nicht einfach nur das VI "FIFO lesen" benutzen. Ich muss den doch da auch erst anlegen und schon habe ich zwei.
Gunni

Ich kenne RT-FIFOs aus meinen RT Projekten und da verwende ich sie analog zu Queues, nur mit dem Unterschied, dass der FIFO zur Laufzeit eine festge Größe hat und kein Speicher neu allociert wird. Soweit ich das bisher verstehe sind RT-FIFOs immer VI-bezogen und haben keinen Mechnismus um Daten von einer Maschine zu einer anderen zu transportieren.

Ich vermute mal freedive hat mit dem RT-FIFO gemeint, dass man auf dem RT-Host 2 parallele Schleifen laufen lassen soll. In der einen Schleife (mit Zeitkritischer Priorität) werden die Daten aus dem DMA FIFO abgeholt und in einen RT-FIFO geschrieben, während in der 2. Schleife (mit normaler Prio) die Daten aus dem RT-FIFO gelesen und per TCP zum PC übertragen werden. Das hätte den Vorteil , dass zwar ggf. der RT-FIFO überlaufen kann, wenn die TCP-Schleife nicht schnell genug ist, aber wenigstens der DMA-FIFO nicht überläuft. Trozdem hätte man aber immer noch das Problem mit den "Stufen" / "fehlenden Samples" wenn der Prozessor ausgelastet ist.

Man kann auch bei einer Shared-Variable die Eingeschaft "RT-FIFO" einstellen und damit nach dem FIFO Prinzip Daten vom RT-Host zum PC transportieren lassen. Allerdings bedeuten Shared Variables, dass die dazugehörige Engine im Hintergrund laufen muss und das ist in meinen Augen nur Verschwendung von Rechenzeit.

' schrieb:Ich kenne RT-FIFOs aus meinen RT Projekten und da verwende ich sie analog zu Queues, nur mit dem Unterschied, dass der FIFO zur Laufzeit eine festge Größe hat und kein Speicher neu allociert wird. Soweit ich das bisher verstehe sind RT-FIFOs immer VI-bezogen und haben keinen Mechnismus um Daten von einer Maschine zu einer anderen zu transportieren.

Ich vermute mal freedive hat mit dem RT-FIFO gemeint, dass man auf dem RT-Host 2 parallele Schleifen laufen lassen soll. In der einen Schleife (mit Zeitkritischer Priorität) werden die Daten aus dem DMA FIFO abgeholt und in einen RT-FIFO geschrieben, während in der 2. Schleife (mit normaler Prio) die Daten aus dem RT-FIFO gelesen und per TCP zum PC übertragen werden. Das hätte den Vorteil , dass zwar ggf. der RT-FIFO überlaufen kann, wenn die TCP-Schleife nicht schnell genug ist, aber wenigstens der DMA-FIFO nicht überläuft. Trozdem hätte man aber immer noch das Problem mit den "Stufen" / "fehlenden Samples" wenn der Prozessor ausgelastet ist.

Man kann auch bei einer Shared-Variable die Eingeschaft "RT-FIFO" einstellen und damit nach dem FIFO Prinzip Daten vom RT-Host zum PC transportieren lassen. Allerdings bedeuten Shared Variables, dass die dazugehörige Engine im Hintergrund laufen muss und das ist in meinen Augen nur Verschwendung von Rechenzeit.

Ich habe mich jetzt umgehört und hab da was von DataSocket aufgeschnappt. Da ich keine Ahnung habe von Shared Variables (da muss man beim anlegen schon so viel beachten) und die normale TCP/IP- Geschichte bei meinem versuch nicht geklappt hat möchte ich was anderes Bekanntes ausprobieren. Bei DataSocket läuft aber auch so ne extra Sache im Hintergrund. Das ist aber meines Erachtens ne fertige und damit ausgereifte Sache die sich um die Übertragung kümmern kann.

Ich hoffe mal das damit die Datenübertragung geht - das Signal wird mit 100kHz abgetastet und das muss es auch, damit bei 10kHz Sinus noch 10 Punkte pro Schwingung übrig bleiben.

Gunni

' schrieb:Ich hoffe mal das damit die Datenübertragung geht - das Signal wird mit 100kHz abgetastet und das muss es auch, damit bei 10kHz Sinus noch 10 Punkte pro Schwingung übrig bleiben.

Datasocket basiert auf UDP, und ist nix anderes als eine Kapselung in ein anderes Format bzw. eine andere API. Du kommst nicht dran vorbei, dass die Daten durch das Netzwerkkabel müssen, egal auf welches Protokoll du nun setzt und da sind 100 KHz einfach zu viel. Wenn du es trozdem schaffst, lass es mich wissen

Das Kabel an sich wird nicht das Problem sein, wenn du ein 100 MBit Netz hast gehen ja theoretisch ca. 12 MByte/Sekunde durch das Kabel. Die Schwachstelle ist der Netzwerktreiber auf dem cRIO bzw. das kleine Prozessörchen das noch viele andere Aufgaben zu erledigen hat.