Verbindung zum RT-Zielsystem bricht ab

Hallo liebe Community,
für ein kleines Projekt zur Messung von Fahrwerkselastizitäten soll ich 2 PWM-codierte Beschleunigungssignale und ein GPS-Signal mit einem cRIO-9074 Chassis erfassen. Die Beschleunigungssignale erfasse ich mit dem NI9403 DIO Modul und die GPS-Signale über die Serielle Schnittstelle am cRIO-Chassis.
Zur decodierung der PWM-Signale habe ich mir nach dem Vorbild der NI-Beispiele 2 Counter gesbastelt die im FPGA-Vi ("FPGA_PWM_IN.vi") laufen. Die gemessenen Werte für duty cycle und periode werden dann über DMA-FIFOs an das Host-Vi geschickt. Im Host-Vi läuft dann die Signalverarbeitung und Speicherung. Soweit zum Grundsätzlichen Aufbau.
Mein Problem ist jetzt, dass das FPGA-Vi solo ohne Probleme läuft aber wenn ich es aus dem Host-Vi starte die Verbindung zum RT-Zielsystem abbricht und ich erst nach einem Reset des Chassis wieder eine neue Verbindung aufbauen kann. Also um es noch ein bisschen genauer zu beschreiben, in meinem Host-Vi ("Fahrwerksschwingungen2.vi") öffne ich im ersten Sequenzblock die FPGA-Vi Referenz, lese im mittleren Sequenzblock die Daten aus der FIFO und schließe im letzten Sequenzblock wieder die Referenz (also ganz nach "Vorschrift" ). Sobald ich das Host-Vi starte wird der Verteilungsprozess ohne Fehler beendet und das Vi startet nach ca. 10s kommt das Infofenster "Warte auf Antwort des Real-Time-Zielsystems" und kurz darauf die Warnung "Warnung: Verbindung zum Real-Time-Zielsystem abgebrochen."
Mir ist noch aufgefallen, dass beim Verbinden des RT-Targets die Info kommt, "LabVIEW: Shared Library vxfpsup.out konnte auf dem Real-Time Zielgerät nicht geladen werden".
Da das mein erstes FPGA-Projekt ist kann ich leider nicht ausmachen, ob der Verbindungsabbruch aufgrund von fehlerhafter Programmierung oder der ungeladenen Shared Library zustande kommt.
Vielleicht hat ja einer von euch eine Idee wie dieses Verhalten zusatnde kommt, ich bin für alle Tipps dankbar!

Ich habe gleich mal das ganze Projekt angehängt, wobei es egal ist ob ich das Calibration.vi oder das Fahrwerksschwingungen2.vi starte, beide zeigen das eben beschriebene Verhalten. LabVIEW Version 2009 SP1!

Gruß Nico


  Fahrwerkselastizit_t.rar (Größe: 1,34 MB / Downloads: 351)

Erreicht die RT CPU Volllast bricht die Kommunikation ab.
- prüfe Dein Schleifentiming ( keine While-Schleifen ohne Looptimer verwenden )
- CPU Load Monitor mit Distributed System Manager
- rechne mal aus ob Deine RT FIFO enabled Variablen in den Speicher des 9074 passen ( vielleicht geht's für den Anfang auch kleiner )

Das Projekt kann ich mangels S+V Kit nicht laden.

Gruß
Christian

@Christian: Gute Hinweise, ich habe mir das Programm noch etwas näher angeschaut und habe noch ein paar weitere "Optimierungsvorschläge";)

@NICO
FPGA VI:

Mir ist aufgefallen, dass Sie auf dem FPGA-VI kein Schleifentiming verwenden, dadurch werden im Takt des Dutycycles des PWM Werte generiert, vermutlich ist dies so gewünscht.

Bei der analogen Ausgabe sieht dies anders aus: rechentechnisch werden ca. 40 ticks für die Abarbeitung der analogen Ausgabe, das Auslesen des Frontpanel-Controls und die Schleifenbearbeitung benötigt. Dies entspricht bei einer Frequenz von 40 MHz ca. 1 MHz Schleifentiming. Das von Ihnen verwendete odul "NI-9263" bietet jedoch physikalisch eine maximale Rate von 100 kS/s. Dementsprechend wird hier nur jeder 10. Wert ausgegeben. Ein Schleifentiming wäre hier sinnvoll.

Ein kleiner Tipp für die Messung der PWM: anstatt der "select" Funktion für True/False können Sie auch einen Inverter ("Negierer) verwenden, dies macht das Diagramm übersichtlicher.

RT VI:

Sobald die CPU-Auslastung 100% erreicht, bricht die Kommunikation zum Host ab. In diesem Fall hilft nur ein Reset des Controllers. Einen groben Eindruck über die akutelle CPU-Auslastung liefert der "Distributed System Manager", diesen können Sie in LabVIEW über die Menüzeile » Tools (ungefähr in der Mitte) starten.

Bei der näheren Betrachtung Ihres RT-VIs fällt mir sofort im ersten Case auf, dass auch hier kein Schleifentiming verwendet wurde, dadurch versucht die CPU diese Schleife mit maximaler Leistung (Geschwindigkeit) abzuarbeiten. Dadurch kommt es zu dieser hohen Auslastung. Platzieren Sie einfach ein "Timing » Wait (ms)" oder "Timing » Wait next multiple (ms)" in dieser Schleife mit einem Wert >0, danach sollte die Auslastung schon wesentlich besser aussehen.

Das Gleiche trifft auf die Schleife zu, in der Sie die TDMS-Datei schreiben. Die obere Schleife (auslesen der FIFOs) scheint vom Timing her in Ordnung zu sein, da bei den "Timed Structures" das Timing bereits implementiert ist.

Viele Grüße
Marian

Hallo Christian & Marian,

vielen Dank für die hilfreichen Tipps, das hört sich ja schon sehr vielversprechend an! Ich werde dann morgen berichten, ob die vorgeschlagenen Modifikationen zum Erfolg geführt haben.

Viele Grüße

Nico

Also ich habe heute mal all eure Vorschläge umgesetzt und das Verhalten ist leider gleich geblieben .
Im DSM habe ich dann auch mal die Prozessorlast über den Programmverlauf beobachtet. Während der Verteilungsphase vor dem Programmstart steigt die Prozessorlast für einen kurzen Augenblich auf 100%, wenn das Programm dann läuft pendelt sie sich bei einem Wert um die 22 ein.
Wenn ich mir den Verlauf im Debug-Mode anschaue dann läuft das Programm eigentlich ganz normal durch, bis es zur Abfrage der Werte aus der DMA-FIFO kommt. Ab hier bricht die Verbindung zum RT-Zielsystem ab.
Ich habe daraufhin auch mal etwas an der FIFO-Größe herumgespielt (verkleinert und vergrößert) aber das führte auch nicht zum Erfolg. Ich denke dennoch, dass der Fehler bei der FIFO zu suchen ist.

@Christian:
Könntest du bitte mal kurz erklären, wie ich ausrechne ob die RT FIFO enabled Variablen in den Speicher des 9074 passen?

Durch das Interleaving füttere ich die DMA-FIFO ja mit einem Array aus U32-Elementen. Die FIFO habe ich auch für U32-Elemente konfiguriert, könnte es sein dass hieraus ein Konflikt erwächst? Immerhin erwartet die FIFO ja U32-Elemente und kein Array, was meint ihr?

Viele Grüße
Nico

Also auch auf die Gefahr hin, dass ich hier Selbstgespräche führe. Das Problem ist gelöst! Für alle die es interessiert oder das gleiche Problem haben:

Es kam hier eine Verkettung von mehreren Fehlern zusammen. Zum Einen konnte das NI 9403 gar keine Signale empfangen bzw. diese als Solche erkennen, da es keine Verbindung zu Masse gab. Eigentlich dachte ich ja, dass das Modul die Kanäle schon über das Chassis auf Masse referenziert aber da lag ich wohl falsch. Auf jeden Fall kamen jetzt schonmal Signale an. Jetzt lief das Programm aber immernoch nicht. Erst als ich die DMA-FIFO für den 2. Kanal entfernt hatte (da nur ein Sensor angeschlossen war) lief das VI. Das Verhalten legte dann nahe einmal zu überprüfen wie sich das System verhält wenn die FIFO leer läuft. Also Stichwort "FIFO-Underflow" und siehe da sobald die FIFO "leergelesen" war brach wieder die Kommunikation zum "RT-Zielsystem" ab.
Wer das gleiche Problem hat, der findet in diesem Tutorium: http://zone.ni.com/devzone/cda/tut/p/id/3555 auf Slide 343 Methoden um FIFO underflow zu vermeiden.

Das die Verbindung zum RT-Zielsystem abbricht wenn eine DMA-FIFO leerläuft, finde ich schon ein bisschen komisch aber das ist jetzt nunmal das Ergebnis das ich beobachtet habe. Mag sein dass da noch andere, VI-abhängige Faktoren mit reinspielen aber für den Moment löst diese Erkenntnis erstmal mein Problem .

Viele Grüße

Nico

Hi,
ich habe ein ähnliches Problem, wie ich vermute und würde mich sehr, um ein bisschen Hilfe freuen.
Ich habe einen Motorprüfstand in Labview mit einem PXI System aufgebaut und bei mir bricht auch jedoch in unregelmäßigen Abständen die Verbindung zum RT Zielsystem ab.
Ich denke den Code zu Posten ist eher unnötig bei meinem Problem.
Meine konkrete frage, da ich dazu leider nicht viel im Internet und unter ni.com gefunden habe, ist:

"Welche Möglichkeiten gibt es, dass man die Verbindung zum Target verliert?"

hab die Möglichkeiten, die oben geschildert wurden schon geprüft.

Noch ein Hinweis: die Verbindung bricht ab wenn ich das target.vi laufen lassen will. Wenn ich das host.vi starte nachdem das target.vi läuft bekomme ich keine Probleme.
Manchmal bricht die Verbindung zum Target.vi jedoch auch ab während es läuft (ohne host.vi)

Bin um jeden Tipp glücklich!
fani

hab noch eine fehlermeldung bekommen, die mein Problem wahrscheinlich eingrenzt, weiß aber leider nicht wie ich das fixen bzw interpretieren soll. (Siehe Bild)

Ich kann mir nicht vorstellen, dass ich der RT CPU zuwenig resourcen lasse. Ich hab 3 Parallel loops. 2 sind timed loops mit wartezeitenvon >100ms. und eine muss bissl schneller laufen aber auch nur alle 50 ms, weil diese Schleife für die Motorregelung zuständig ist.

Netzwerkvariablen mit FIFOs verwende ich erst garnicht und CPU Speicher und Auslastung ist beides < 10%

Mein PXI System ist über einen Switch mit dem Agilentgerät (Kühl-Pumpenschalter) und dem PXI System verbunden.
Kann dass das Problem verursachen?

Außerdem habe ich 2 Netzwerkkarten im PC. Kann das auch Probleme machen?

Suche nun schon 2 Tage aber komme einfach nicht auf die Lösung des Problems.