cRIO

@ i2dx,

jetzt habe ich den IRQ wieder ausgebaut und bekomme immer noch timing constraints Fehler. Das scheint and irgendwas anderem zu liegen...

' schrieb:wie schnell wird der Interrrupt denn aufgerufen (in Hz)? Wieviel Daten überträgst du denn vom FPGA zum RT-VI (Samples pro Sekunde)? 5 kHz erscheinen mir nun nicht wirklich schnell ...

Ich hatte den IRQ im FPGA in der "schnellen" loop mit 195µs (5.13kHz) eingebaut. Ich habe einen DMA-FIFO-Kanal vom FPGA zum RT für 7 Analogwerte, die mit 5.13kHz gescannt werden. Nach 512 Schleifendurchläufen wird der IRQ gesetzt (=3584 Werte). Im RT lese ich dann diese 3584 Werte alle 80ms aus (etwas schneller als im FPGA, um Datenverluste zu vermeiden). Den DMA-Kanal habe ich sicherheitshalber größer gesetzt, auf 8192 Werte.

Wenn ich in der RT-Applikation das FPGA-VI starte, scheint sich das cRIO irgendwo vor oder in der "Wait for Initialize"-Loop aufzuhängen, d.h. schon vor der eigentlich Datenerfassung und DMA-Übertragung.

@ DAX5

' schrieb:Ich vermisse einige Randbedingungen
1. Wie groß ist der DMA Buffer auf dem FPGA
2. Wie groß oder klein ist die reaktionszeit von deinem RT
( bei normaler XP Umgebung muss man auf dem FPGA zum Bsp. einen Buffer einrichten der min. die Messdaten für 250 ms buffern kann.
3. Der ACKNOWLEDGE des Interrupt gehört hinter FIFO READ zudem sollte vor dem Quittieren
DMA Time Out abgefragt und ausgewertet werden.
4. Um einen einwandfreien DMA Tranfer zu gewährleisten sollte das Auslesen des DMA Buffer auf
Host seite synchronisiert erfolgen

1. DMA-FIFO-Größe auf dem FPGA = 8192
2. RT-Leseschleife mit 80ms (s.o.). Ich arbeite nur mit dem cRIO als Stand-Alone-Applikation, d.h. ohne PC. Der Datenaustausch erfolgt über Datasocket (TCP/IP)
3. Habe ich gemacht, ganz zum Schluss in der Leseschleife.
4. was meinst du denn mit synchronisieren? einen zweiten IRQ setzen und im FPGA quittieren?

Danke für die Hinweise!

Anzeige

Die Methode wie in Bild 4 hatte ich auch mal probiert und damit nur Probleme. Die Idee dafür hatte ich von der Programmierung mit dem alten DAQ Treiber, wo man auch durch Auslesen von 0 Samples das "Backlog" ermitteln konnte und dann den kompletten Puffer abholen konnte. Mit der Methode, wie ich sie ein paar posts oberhalb als Screenshot dargestellt habe, hab ich beim Datentransfer keinerlei Probleme mehr ...

Ich mach das immer so:
ich lege erstmal fest wie schnell meine Abhol-Schleife laufen soll. Angenommen ich hab 8 analoge Kanäle (I16) @ 1kHz und möchte dass alle 100 ms Daten aus dem DMA ausgelesen werden, dann schiebe ich auf dem FPGA 8/2 x 100 = 400 Werte in den FIFO. Wenn diese 400 Werte drin sind setze ich einen Interrupt, der in dem RT-VI das Auslesen aus dem FIFO triggert. das durch /2 kommt daher, dass ich zwei I16 zu einem U32 zusammenfasse und auf dem Host wieder trenne. Daraus ergibt sich dann auch die Größe des FIFOs, in diesem Beispiel müsste er dann mindestens 511 U32 groß sein ...

und ich hab auch schon den 3M Gate FPGA bis auf 90% vollgestopft und eigentlich nie Timing Probleme gehabt ...

hmm :/

Habe den IRQ jetzt eingebaut. Die Datenübertragung per DMA scheint jetzt "sauberer" zu sein, auch wenn die Performance darunter gelitten hat (RT-Leseschleife vorher 80ms, jetzt ca. 120ms).

Was ich aber immer noch nicht verstehe, sind meine sporadischen Abstürze kurz nach dem Starten meiner Applikation :-(( Sobald das FPGA-VI bzw. -Bitfile aufgerufen wird, hängt das cRIO irgendwo und antwortet nicht mehr ("connection lost"). Dann hilft meist nur noch der Neustart des cRIO...

' schrieb:Habe den IRQ jetzt eingebaut. Die Datenübertragung per DMA scheint jetzt "sauberer" zu sein, auch wenn die Performance darunter gelitten hat (RT-Leseschleife vorher 80ms, jetzt ca. 120ms).

Was ich aber immer noch nicht verstehe, sind meine sporadischen Abstürze kurz nach dem Starten meiner Applikation :-(( Sobald das FPGA-VI bzw. -Bitfile aufgerufen wird, hängt das cRIO irgendwo und antwortet nicht mehr ("connection lost"). Dann hilft meist nur noch der Neustart des cRIO...

ich hoffe ich versteh dich jetz richtig: Abhol-Schleife ist die, die auf dem RT-Teil läuft, nicht im FPGA?

hmm ... wieso denkst du dass eine schneller laufende "Abholschleife" gleich mehr Performance ist? Die Schleife sollte genau dann ausgeführt werden, wenn genug Werte im FIFO sind um einen "Block" auszulesen. Die Blockgröße legst du ja (in-)direkt fest, somit ist es bei der Abhol-Schleife eigentlich nur wichtig, dass sie jeden anfallenden Block rechtzeitig ausliest. Das ist durch die Kombination Blockgröße festlegen und IRQ setzen wenn die gewünschte Anzahl an Samples aufgelaufen ist ja erreicht.

*blond guck*

' schrieb:ich hoffe ich versteh dich jetz richtig: Abhol-Schleife ist die, die auf dem RT-Teil läuft, nicht im FPGA?

hmm ... wieso denkst du dass eine schneller laufende "Abholschleife" gleich mehr Performance ist? Die Schleife sollte genau dann ausgeführt werden, wenn genug Werte im FIFO sind um einen "Block" auszulesen. Die Blockgröße legst du ja (in-)direkt fest, somit ist es bei der Abhol-Schleife eigentlich nur wichtig, dass sie jeden anfallenden Block rechtzeitig ausliest. Das ist durch die Kombination Blockgröße festlegen und IRQ setzen wenn die gewünschte Anzahl an Samples aufgelaufen ist ja erreicht.

*blond guck*

Auf dem FPGA scanne ich 6 Analogeingänge mit 195µs und speichere dazu die Zykluszeit dt. Diese 7 Werte schreibe ich dann in den DMA-FIFO. Nach 512 Schleifendurchläufen setze ich den IRQ, d.h. es sind 7x512=3584 Werte im FIFO. Dazu habe ich dann insgesamt 512x195µs=99.84ms gebraucht.

Auf dem RT muss ich dann ja diese 3584 Werte auch mindestens mit 99.84ms auslesen, sonst verliere ich doch Daten, oder? Das habe ich vorher mit einer Zykluszeit von 80ms getan. Nach Einbau des IRQ ging dann die Zykluszeit auf ca. 130ms hoch. Das meinte ich mit "schlechterer Performance". Da werde ich wohl versuchen müssen, den Code zu optimieren.

Übrigens habe ich heute gehört, dass die cRIO-Systeme 9014 und 9074 mit NI-RIO Version 2.3.0 bis 3.0.0 Probleme mit dem DMA haben, die zu Abstürzen führen können. Ich arbeite mit 2.4.1. Das könnte meine Fehler erklären. NI empfiehlt, die neue Version 3.0.1 zu installieren. Dann probiere ich das mal aus...

' schrieb:Auf dem FPGA scanne ich 6 Analogeingänge mit 195µs und speichere dazu die Zykluszeit dt. Diese 7 Werte schreibe ich dann in den DMA-FIFO. Nach 512 Schleifendurchläufen setze ich den IRQ, d.h. es sind 7x512=3584 Werte im FIFO. Dazu habe ich dann insgesamt 512x195µs=99.84ms gebraucht.

Auf dem RT muss ich dann ja diese 3584 Werte auch mindestens mit 99.84ms auslesen, sonst verliere ich doch Daten, oder? Das habe ich vorher mit einer Zykluszeit von 80ms getan. Nach Einbau des IRQ ging dann die Zykluszeit auf ca. 130ms hoch. Das meinte ich mit "schlechterer Performance". Da werde ich wohl versuchen müssen, den Code zu optimieren.

Übrigens habe ich heute gehört, dass die cRIO-Systeme 9014 und 9074 mit NI-RIO Version 2.3.0 bis 3.0.0 Probleme mit dem DMA haben, die zu Abstürzen führen können. Ich arbeite mit 2.4.1. Das könnte meine Fehler erklären. NI empfiehlt, die neue Version 3.0.1 zu installieren. Dann probiere ich das mal aus...

sorry, aber das ist komplett unlogisch.

Wenn die Erfassung der Daten (deines "Blocks") auf dem FPGA 99,84 ms dauert, dann läuft die "FIFO-Lesen" Schleife (beim Einsatz von Interrupts) auf dem RT-Controler mit genau der gleichen Geschwindigkeit ansonsten sind deine Daten nicht konsistent.

Deine Erfassung-Schleife auf dem FPGA sollte IMHO so aussehen, dann klappt's auch mit DMA+Interrupt:

   

Das Auslesen aus dem FIFO geschieht ann analog zu meinem Beispiel weiter oben ...
Empfohlene-FIFO-Größe: min 4191 U32

Anzeige

Hallo id2x,

ich habe das Prinzip schon verstanden. Die 80ms hatte ich als Timer gesetzt, bevor ich den IRQ benutzt habe. Mit IRQ wird die RT-Schleife ja jetzt mit der FPGA-Schleife synchronisiert.

Ich hatte aber übersehen, dass ich in der FPGA-Schleife noch einen Trigger eingebaut habe, der bei periodischen Signalen erst bei Nulldurchgang mit dem FIFO-Schreiben startet, so dass es im ungünstigsten Fall bei einem periodischen Signal von 50Hz eine Verzögerung von 20ms gibt. Außerdem werden die Daten in meiner "RT-Abholschleife" nach dem Auslesen noch verarbeitet (rechenintensivere Aufbereitung und Analyse).

Ich habe noch recht wenig praktische Erfahrung im Bereich RT-Programmierung. Würde es Sinn machen, die ganze Datenanalyse in eine extra Schleife zu packen? Ich habe noch zwei weitere für Regelung/Datenausgabe und den Datenaustausch über TCP/IP.

Schon mal Danke für deine bisherige Hilfe!

' schrieb:Hallo id2x,

ich habe das Prinzip schon verstanden. Die 80ms hatte ich als Timer gesetzt, bevor ich den IRQ benutzt habe. Mit IRQ wird die RT-Schleife ja jetzt mit der FPGA-Schleife synchronisiert.

Ich hatte aber übersehen, dass ich in der FPGA-Schleife noch einen Trigger eingebaut habe, der bei periodischen Signalen erst bei Nulldurchgang mit dem FIFO-Schreiben startet, so dass es im ungünstigsten Fall bei einem periodischen Signal von 50Hz eine Verzögerung von 20ms gibt. Außerdem werden die Daten in meiner "RT-Abholschleife" nach dem Auslesen noch verarbeitet (rechenintensivere Aufbereitung und Analyse).

Ich habe noch recht wenig praktische Erfahrung im Bereich RT-Programmierung. Würde es Sinn machen, die ganze Datenanalyse in eine extra Schleife zu packen? Ich habe noch zwei weitere für Regelung/Datenausgabe und den Datenaustausch über TCP/IP.

Schon mal Danke für deine bisherige Hilfe!

Ja, das macht IMHO schon Sinn. In der Abhol-Schleife wandle ich die Roh-Daten eigentlich nur in Spannungen um (=Verrechnung mit der Kalibrierung) und wende die Skalierung darauf an (Spannungen --> Messdaten). Anschließend schicke ich die Daten über einen RT-FIFO oder eine Queue* an die Auswerte-Schleife.

Wenn du einen Trigger in der FPGA-Schleife eingebaut hast ist das natürlich klar, dass sich der Takt verzögern kann. So lang dadurch der FIFO und das warten auf den IRQ nicht in einen Timeout laufen seh ich da auch kein Problem damit. Sehe ich das jetzt richtig, dass du nach einem Nulldurchgang genau 512 Samples pro Kanal aufzeichen willst?

* RT-FIFOs verwende ich eigentlich nur, wenn es richtig schnell gehen muss. Bei Beispielen wie diesem - weil die Übertragung alle 100ms doch recht langsam ist- nehm ich eine Queue (frag mich nicht warum, hat sich irgendwann so eingebürgert und wenn mir Tom gleich ne Watschen gibt, dann weiß ich dass das grundsätzlich falsch ist) die ich am Anfang des Programms mal initialisiert hab: Erstellen, mit z.b. 200 werten füllen, Flush Queue => der Speicher für diese Queue ist initialisiert

' schrieb:Ja, das macht IMHO schon Sinn. In der Abhol-Schleife wandle ich die Roh-Daten eigentlich nur in Spannungen um (=Verrechnung mit der Kalibrierung) und wende die Skalierung darauf an (Spannungen --> Messdaten). Anschließend schicke ich die Daten über einen RT-FIFO oder eine Queue* an die Auswerte-Schleife.

Ich arbeite im FPGA mit Fixedpoint-Werten, die (wie mir gesagt wurde) bereits kalibriert sind (Calibrated Data im AI-Modul einstellen), allerdings ohne Linearisierung, aber damit kann ich leben. Diese wandle ich im FPGA direkt in I16-mV-Werten um und schicke sie dann zum RT. Dort skaliere ich sie dann entsprechend den Sensoren zu "physikalischen" Werten und verarbeite sie weiter. Ich hatte die Kalibrierung auch vorher im RT gemacht, war aber nicht so glücklich damit.

' schrieb:Wenn du einen Trigger in der FPGA-Schleife eingebaut hast ist das natürlich klar, dass sich der Takt verzögern kann. So lang dadurch der FIFO und das warten auf den IRQ nicht in einen Timeout laufen seh ich da auch kein Problem damit. Sehe ich das jetzt richtig, dass du nach einem Nulldurchgang genau 512 Samples pro Kanal aufzeichen willst?

Ja, ist eine eingebaute Option zur Signaldarstellung in einem Diagramm, damit es nicht so zappelt (wie beim Oszi)

' schrieb:* RT-FIFOs verwende ich eigentlich nur, wenn es richtig schnell gehen muss. Bei Beispielen wie diesem - weil die Übertragung alle 100ms doch recht langsam ist- nehm ich eine Queue (frag mich nicht warum, hat sich irgendwann so eingebürgert und wenn mir Tom gleich ne Watschen gibt, dann weiß ich dass das grundsätzlich falsch ist) die ich am Anfang des Programms mal initialisiert hab: Erstellen, mit z.b. 200 werten füllen, Flush Queue => der Speicher für diese Queue ist initialisiert

Mit RT-FIFOs habe ich noch nicht gearbeitet. Werde mir das mal anschauen für meine Datenanalyse.

' schrieb:Ich arbeite im FPGA mit Fixedpoint-Werten, die (wie mir gesagt wurde) bereits kalibriert sind (Calibrated Data im AI-Modul einstellen), allerdings ohne Linearisierung, aber damit kann ich leben. Diese wandle ich im FPGA direkt in I16-mV-Werten um und schicke sie dann zum RT. Dort skaliere ich sie dann entsprechend den Sensoren zu "physikalischen" Werten und verarbeite sie weiter. Ich hatte die Kalibrierung auch vorher im RT gemacht, war aber nicht so glücklich damit.

joh, ich schalt das immer aus. Ich bilde mir ein, dass die Kalibrierung im FPGA nochma ein paar Slices braucht und das ist Platz den man ggf. für wichtigere Dinge braucht,:

Werte für das Beispiel mit den 6 AIs, einmal Fixed Point, einmal RAW
RAW:
Compilation Summary
-------------------
Device Utilization Summary:
Number of BUFGMUXs 3 out of 16 18%
Number of DCMs 1 out of 12 8%
Number of External IOBs 149 out of 484 30%
Number of LOCed IOBs 149 out of 149 100%
Number of RAMB16s 8 out of 96 8%
Number of SLICEs 1277 out of 14336 8%


FPX:
Compilation Summary
-------------------
Device Utilization Summary:
Number of BUFGMUXs 3 out of 16 18%
Number of DCMs 1 out of 12 8%
Number of External IOBs 149 out of 484 30%
Number of LOCed IOBs 149 out of 149 100%
Number of MULT18X18s 1 out of 96 1%
Number of RAMB16s 8 out of 96 8%
Number of SLICEs 1564 out of 14336 10%