LabVIEWForum.de

Hi zusammen,

mein cRIO macht ganz komische Sachen. Ich lese mehere Kanäle per FPGA ein. Im FPGA filter ich die Werte und übertrage sie zur RT-Anwendung. Dort lese ich die Werte aus dem FIFO aus.
Das Ganze mache ich mit 2 Messkarten und je 6 Kanälen. Pro Messkarte verwende ich einen DMA-FIFO.

Das sieht wie folgt aus.

Werte per FPGA einlesen und filtern:

[attachment=32032]

[attachment=32033]

In der RT-Anwendung lese ich die Werte so aus:

[attachment=32034]

Die Anzahl der auszulesenden Elemente liegt in meinem Fall bei einer durch 6 teilbaren Zahl wie z.B. 600.

Nun sollte man meinen, dass die Werte in jedem FIFO in dieser Reihenfolge stehen (FXP-Array in der RT-Anwendung):

Kanal0, Kanal1, Kanal2, Kanal3, Kanal4, Kanal5, Kanal0, Kanal1, ...

Prinzipiell klappt das auch, aber manchmal landen die Werte am falschen Platz (nach einen cRIO-Reboot). Die Werte von Kanal 4 stehen dann an der Stelle von Kanal 5. Alle sind um eine Stelle verschoben.
Ich habe auch schon versucht, die FIFOs zu leeren. Aber das half nichts.

Seht ihr einen Fehler?
Ich bin wirklich am Verzweifeln. Sollte sich herausstellen, dass es nicht an meinem Code liegt (muss egtl. am Code liegen), war das mein letztes cRIO ...

Frustriert grüßt
Matze

Keiner 'ne Idee?

Leider nicht auf die Schnelle. Ich tippe mal darauf, dass der FPGA früher anläuft als die RT-Software?!

Eine Idee zur Behebung: Kannst du noch irgendwie den Index deines Array-Elements in den FIFO mitreinnehmen? Dann kannst du bei der Entnahme aus dem FIFO genau sagen -> das ist jetzt Element 1, das Element 2, etc...

Oder irgendein "Trennzeichen"-Element in deinen FIFO einbauen. Quasi noch eine Element 7, dass du mit einem Wert belegst, der unmöglich vorkommen kann. Das ist dann dein Trigger für ein neues Datenpaket. Wie bei einer schönen RS232-Kommunikation.

Gruß, Jens

Hallo Jens,

danke für deine Antwort.

An so eine Art Header dachte ich auch erst, aber das ist vermutlich ein ordentlicher Overhead. Den Header benötige ich eigentlich nur beim Programmstart und danach nicht mehr. Dann müsste ich jeden 7. Wert ignorieren.

Normalerweise sollte es so auch funktionieren und in geschätzten 95% der Fälle klappt's auch. Nur kann es nach einem Reboot sein, dass es nicht funktioniert.
Die FIFOs sind ja leer nach dem Start, erst recht, wenn ich diese über FIFO.Stop aus der RT-Anwendung leere.
Ich verstehe das wirklich nicht.

Meine RT-Anwendung startet vor dem FPGA. Das FPGA starte ich dann zu Beginn meiner RT-Anwendung über die FPGA-Referenz.

Grüße
Matze

Hallo Mechatronik-Ingenieur,

kannst Du mal die Schleifen-Iteration aus Bild zwei, in ein Array "schreiben lassen" und die Werte die es beinhaltet nach einem Reboot und einem Durchlauf kontrollieren?

Gruß snuz

Hallo,

die Werte stimmen (leider). Ich kann nicht reproduzieren, wann es nicht geht.

Ich habe Jens' Vorschlag mit dem Header nun umgesetzt. Der Overhead hält sich sogar sehr in Grenzen. Im FPGA schreibe ich den Header nur zu Beginn in die FIFOs und werte ihn in der RT-App einmalig vor den Messschleifen aus, danach nicht mehr.

Mal sehen, wie sich das nun verhält.

Irgendwie funktioniert das nach wie vor nicht. Der Header kommt mal richtig, mal nicht.

NI RIO 3.5.1 ist noch aktuell oder?
Nicht dass es an der Firmware liegt. Ich kappier's echt nicht. Eigentlich ist das eine ganz triviale Messwertübertragung vom FPGA zur RT-App.

Hallo,

was aus deinen Screenshots nicht so wirklich hervorgeht ist wie die Synchronisation von FPGA und RT aussieht. Was passiert wenn die FIFOs volllaufen? Was hast du denn bei deinen Timeouts angeschlossen? Wie groß sind deine FIFOs?
Vermutlich laufen deine FIFOs über. Recht viel anderes kann ich mir eigentlich nicht vorstellen.
Brauchst du denn einen kontinuierlichen Datenstrom oder nur immer einige hundert Werte? Wenns nur einige Werte sind könntest du mit Interupts RT und FPGA synchronisieren. Allerdings klingt das von dir beschriebene Verhalten so als würde es laufen wenns erstmal läuft, allerdings teilweise mit verschobenen Kanälen. Als Idee könntest du deinen kompletten FPGA-Code in eine Flache Sequenz packen und vor deinen Code(in einen Sequenzrahmen) ein "wait for Interupt" setzen. Den Interupt kannst du dann vom RT aus setzen bevor du das erste mal Daten abholst (aber nach RT Initialisierung). Damit könntest du ein Vollaufen deines FIFOs verhindern. Es könnte durchaus sein das dein RT mal länger und mal kürzer braucht um die Schleife zum Abholen der Daten zu Starten(File I/O, etc. ).
Über die FIFO Größen, die Remaining elements und die Anzahl der ausgelesenen Daten kannst du auch einfach eine Prüfung deines FIFO Füllstandes implementieren. Wenn dein FIFO voll ist hättest du an dieser Stelle ein Problem, das du behandeln solltest.
Das leeren des FIFO vor dem Abholen ist eher problematisch, da du ja nie weist, wann du entleerst und wo der FPGA gerade beim Schreiben in den FIFO ist. Sicherer ist eine Synchronisierung.
Du könntest auch mit (-1) im FPGA in den FIFO schreiben, dann steht zwar dein FPGA wenn du die Daten nicht abholst, aber sobalds losgelaufen ist sollte das ja kein Problem sein. Im Zweifel gibt dann das RT(wenn es zu langsam abholt) den Takt vor und es entsteht ein Jitter(Größe des FIFOs).

Gruß

Hallo Matze,

hatten das Problem auch, haben es mit den Interupts gelöst.
Bei Interesse, könnte ich nächste Woche unseren Code kurz posten. Bin diese Woche nicht im Büro.

Grüße
RosJon

P.S.: Hat jemand eine Lösung 7-10 analoge Signale ohne DMA Fifo zu streamen. Komme mit den 3 vorhandenen DMA Fifos nicht aus.

ich streame alles was vom FPGA zum RT geht über einen FIFO und alles was vom RT zum FGPA geht über einen anderen, mir reichen immer 2 FIFOs ...

Erfassung auf dem FPGA
[attachment=33751]
die VIs mit den Uhren sind für die Frage eigentlich irrelevant, das sind nur verschiedene Sample-Clocks

In den FIFO schieben
[attachment=33752]

Aus dem FIFO auslesen
[attachment=33753]

Kanäle trennen
[attachment=33754]

Kanäle skalieren
[attachment=33755]

funktioniert eigentlich immer ... und wenn's doch mal Probleme gibt, dann liegt es in 50% der Fälle daran, dass ich die Anzahl der Kanäle und/oder Samples falsch eingestellt habe und in 50% der Fälle daran, dass der FIFO zu klein ausgewählt ist, ansonsten sind diese Routinen durch nichts zu erschüttern ...