+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Module (/Forum-LabVIEW-Module)
+---- Forum: LabVIEW FPGA (/Forum-LabVIEW-FPGA)
+---- Thema: cRIO (/Thread-cRIO)
cRIO - MichaDu - 21.10.2008 21:05
Hallo,
habe seit einiger Zeit ein Problem mit meinem cRIO beim Programmstart. Ich habe eine RT-Applikation, die die üblichen Initialisierungen auf dem FPGA-VI vornimmt. Häufig (aber nicht immer) hängt sich das cRIO mittendrin auf und es kommt die Fehlermeldung "Warning: connection lost...".
Ich arbeite mit 2 DMA-FIFOs, um Daten vom FPGA zum RT und zurück zu übertragen. Mein Verdacht ist eine eventuell falsche Reihenfolge in den FPGA-Abfragen (Nodes) auf der RT-Applikation, eine falsche Konfiguration der DMA-FIFOs oder irgendwelche falschen Timeout-Werte. Könnte das daran liegen? Weiß momentan nicht weiter und bin über Hilfe dankbar!
Anbei Screenshots vom FPGA- und RT-VI
cRIO - thomas.sandrisser - 22.10.2008 03:50
was ich mir vorstellen koennte ist, dass deine while schleife intialize das problem ist.
den error cluster nicht zu beruecksichtigen kann gefaehrlich sein. entweder du implementierst die negiert logik oder du musst den error cluster bei entscheidungen beruecksichtigen.
aber, sehr loeblich dein code, bis auf eine kleine sache: der 2. dma mit 200 irgendwas elementen ist aeusserst ungewoehnlich :-)
cRIO - cb - 22.10.2008 07:05
ich benutze eigentlich immer Interrupts um zwischen dem Host und dem Target zu signalisieren "hey, der Puffer is voll, hol ma ab" bzw. "schick ma was runter". Das macht die Daten-Übertragung deutlich stabiler (IMHO). Vielleicht bringt das bei dir ja auch was?
FPGA VI: (in dem Fall sendet der FPGA Daten an das cRIO)
[attachment=14949]
RT-VI (holt die Daten ab)
[attachment=14929]
cRIO - MichaDu - 22.10.2008 08:30
@freedive
das mit der while-schleife werde ich überprüfen. die applikation scheint ab da irgendwo ärger zu machen.
warum ist der 2.dma (RT->FPGA) komisch? Ich schreibe in der Schleife, die auch für das DMA-Read zuständig ist, nur 2 Werte ins FIFO und habe die DMA-Tiefe "etwas" größer gewählt. Ist das nicht so gut? Oder hier lieber mit Shared Variablen arbeiten?
Was ist denn die Negiert-Logik? Ich muss zugeben, die Fehlerbehandlung etwas vernachlässigt zu haben. Um Popup-Dialoge zu vermeiden, habe ich aber den General-Error-Handler verwendet und "No Dialog" aktiviert. Meinst du das?
Danke für das Lob! ;-)
@i2dx
Hatte mal irgendwo gelesen, dass man Interrupts aus Performancegründen möglichst vermeiden soll (?). Wenn es die Applikation aber stabiler macht, werde ich das in jedem Fall ausprobieren! Meine Programmstarts sind bis jetzt doch weniger gut reproduzierbar (Abstürze mit "Connection lost" error, fehlerhafte Datenübertragung über DMA,...) :-(
Danke euch für die Tipps! Werde mich melden, wenn ich eure Vorschläge ausprobiert habe.
cRIO - cb - 22.10.2008 09:14
' schrieb:@i2dx
Hatte mal irgendwo gelesen, dass man Interrupts aus Performancegründen möglichst vermeiden soll (?). Wenn es die Applikation aber stabiler macht, werde ich das in jedem Fall ausprobieren! Meine Programmstarts sind bis jetzt doch weniger gut reproduzierbar (Abstürze mit "Connection lost" error, fehlerhafte Datenübertragung über DMA,...) :-(
hmm ... die Aussage widerspricht nun direkt dem, was ich mal auf ner cRIO Schulung gehört habe, da war die Rede davon, dass das Warten auf Interrupts quasi keine Performance schluckt. Wie dem auch sei, das ist mir eigentlich egal. Ich will meistens keine möglichst performante Anwendung schreiben, sonder eine, die mir nach dem Release möglichst wenig Ärger bereitet (Stichwort: Support, Bugfix, etc). Und wenn das cRIO durch diese "Philosophie" nun mehr rechnen muss ... who cares, dafür is die CPU schließlich da. Performance ist für mich immer nur optimierungs-Kriterium Nr. 2. auf Platz 1 kommt die Betriebsfestigkeit (es sei denn ich wurde nun explizit dafür angeheuert möglichst performanten Code zu schreiben ...)
cRIO - thomas.sandrisser - 22.10.2008 09:33
Wer hat denn den Kurs gegeben :-)
Das Warten verbraucht auch keine Performance aber das verarbeiten, sprich je oefters der IRQ auftritt, desto hoeher ist die grundlast...
Der zweite FPGA hat nur 256 elemente (2xFPGA lt. label)... das ist eigentlich eine Verschwendung am FPGA einen FIFO so klein zu waehlen...
cRIO - cb - 22.10.2008 17:42
' schrieb:Wer hat denn den Kurs gegeben :-)
Das Warten verbraucht auch keine Performance aber das verarbeiten, sprich je oefters der IRQ auftritt, desto hoeher ist die grundlast...
Der zweite FPGA hat nur 256 elemente (2xFPGA lt. label)... das ist eigentlich eine Verschwendung am FPGA einen FIFO so klein zu waehlen...
ein Mitarbeiter von NI ... (wenn du den Namen haben willst musst du mir ne PM schreiben
)ich persönlich programmiere das Auslesen des FIFOs eigentlich immer so, dass alle 50 bis 100 ms ein Interrupt kommt. Die dadurch entstehende Grundlast sollte eigentlich vernachlässigbar klein sein. Wenn man das ganze deutlich schneller betreibt kann das natürlich sehr wohl ins Gewicht fallen ...
cRIO - MichaDu - 27.10.2008 07:22
Habe das mit dem Interrupt mal ausprobiert, allerdings gibt mir der Compiler dann immer timing constraints aus. Kann das auch an der hohen Gatterauslastung von 95% slices liegen? Ich benutze auf dem FPGA 4 parallele loops, wobei die schnellste 195µs ist. Hier habe ich auch den Interrupt eingebaut. Auf der RT-Seite habe ich ebenfalls 4 loops, wobei die schnellste hier 100ms ist.
Das nervige bei der Fehlersuche ist, dass der Compiler nicht deterministisch arbeitet, d.h. das Compilieren kann auch mal nach dem x. mal erfolgreich sein, ohne dass Codeänderungen gemacht wurden :-(
Beim Aufruf des FPGA-VIs in der RT-Applikation tauchen die sporadischen Abstürze aber immer noch auf. Ich vermute, dass irgendwas passiert, sobald ich "Run FPGA" aufrufe...
cRIO - cb - 27.10.2008 08:23
' schrieb:Habe das mit dem Interrupt mal ausprobiert, allerdings gibt mir der Compiler dann immer timing constraints aus. Kann das auch an der hohen Gatterauslastung von 95% slices liegen? Ich benutze auf dem FPGA 4 parallele loops, wobei die schnellste 195µs ist. Hier habe ich auch den Interrupt eingebaut. Auf der RT-Seite habe ich ebenfalls 4 loops, wobei die schnellste hier 100ms ist.
Das nervige bei der Fehlersuche ist, dass der Compiler nicht deterministisch arbeitet, d.h. das Compilieren kann auch mal nach dem x. mal erfolgreich sein, ohne dass Codeänderungen gemacht wurden :-(
Beim Aufruf des FPGA-VIs in der RT-Applikation tauchen die sporadischen Abstürze aber immer noch auf. Ich vermute, dass irgendwas passiert, sobald ich "Run FPGA" aufrufe...
hmm ... ohne den Code zu sehen hab ich nun auch keine Idee woran das liegen könnte. Die Fehlermeldung mit dem Timing Contstraint seh ich heut zum ersten mal ...
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 ...
cRIO - DAX5 - 27.10.2008 12:58
' schrieb:Hallo,
habe seit einiger Zeit ein Problem mit meinem cRIO beim Programmstart. Ich habe eine RT-Applikation, die die üblichen Initialisierungen auf dem FPGA-VI vornimmt. Häufig (aber nicht immer) hängt sich das cRIO mittendrin auf und es kommt die Fehlermeldung "Warning: connection lost...".
Ich arbeite mit 2 DMA-FIFOs, um Daten vom FPGA zum RT und zurück zu übertragen. Mein Verdacht ist eine eventuell falsche Reihenfolge in den FPGA-Abfragen (Nodes) auf der RT-Applikation, eine falsche Konfiguration der DMA-FIFOs oder irgendwelche falschen Timeout-Werte. Könnte das daran liegen? Weiß momentan nicht weiter und bin über Hilfe dankbar!
Anbei Screenshots vom FPGA- und RT-VI
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