Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Ich bin jetzt schon ein halbes Jahr daran mich mit LabVIEW auseinander zu setzen. Seit drei Monaten beschäftige ich mich mit dieser Real-Time-Geschichte. Ich versuche krampfhaft mein Diplomarbeit zu bewältigen aber ich trampel nur auf der Stelle.
Ich bin schon vielen Ratschlägen nachgegangen und habe meine Signalgeneration und Datenerfassung in einer seperaten Schleife. Ich habe gehört das man nicht ohne weiteres Signale mit Frequenzen bis z.B 10 kHz abtasten und Darstellen kann. Die Abtastung eines Signals mit dieser Frequenz bedarf vieler Samples in der Sekunde. das heißt ich habe sehr viele Daten in der Sekunde so um die 100000 Elemente. Diese bekommt man nicht einzeln nacheinander auf den RT-HOST, da da wohl die Zeit nicht mitspielt. Also müssen die daten in ein Paket geschnürt werden und so los geschickt werden.
Dies versuche ich mit dem FIFO zu realisieren.
Leider muss ich jetzt feststellen das mein Signal eine Weile gut läüft aber dann ist wie so ne Art Sprung drin. Es fehlen ein paar Elemente. Ich kann aber auch nie garantieren das der FIFO genauso schnell ausgelesen wird wie er beschrieben wird. das ist aber meines Erachtens notwendig, um alle Werte auf den RT-Controller zu bekommen.
Ich bin jetzt schon ein halbes Jahr daran mich mit LabVIEW auseinander zu setzen. Seit drei Monaten beschäftige ich mich mit dieser Real-Time-Geschichte. Ich versuche krampfhaft mein Diplomarbeit zu bewältigen aber ich trampel nur auf der Stelle.
Ich bin schon vielen Ratschlägen nachgegangen und habe meine Signalgeneration und Datenerfassung in einer seperaten Schleife. Ich habe gehört das man nicht ohne weiteres Signale mit Frequenzen bis z.B 10 kHz abtasten und Darstellen kann. Die Abtastung eines Signals mit dieser Frequenz bedarf vieler Samples in der Sekunde. das heißt ich habe sehr viele Daten in der Sekunde so um die 100000 Elemente. Diese bekommt man nicht einzeln nacheinander auf den RT-HOST, da da wohl die Zeit nicht mitspielt. Also müssen die daten in ein Paket geschnürt werden und so los geschickt werden.
Dies versuche ich mit dem FIFO zu realisieren.
Leider muss ich jetzt feststellen das mein Signal eine Weile gut läüft aber dann ist wie so ne Art Sprung drin. Es fehlen ein paar Elemente. Ich kann aber auch nie garantieren das der FIFO genauso schnell ausgelesen wird wie er beschrieben wird. das ist aber meines Erachtens notwendig, um alle Werte auf den RT-Controller zu bekommen.
Kann mir jemand sagen was ich anders machen kann?
Gunni
HI Gunni,
Wenn Du noch einiges an Platz auf dem FPGA hast, wie wäre es wenn Du deine Messdaten vor der übertragung an den Host komprimierst? Spart Dir vielleicht einiges an Bandbreite ein.
Die Frage ist nur, gibts für Datenkompression schon fertige VIs oder müsste man sich das selber zusammen bauen und lohnt sich der Aufwand?
Gruß, Rob
Bitte Beachten:
Die obenstehenden Texteile können unter Umständen Sarkasmus und Ironie enthalten, für nicht erkannten Sarkasmus oder nicht erkannte Ironie wird keine Haftung übernommen.
N.B.: "Multiple exclamation marks, " he went on, shaking his head, "are a sure sign of a deseased mind." - Terry Pratchett
Haeng das naechste Mal bitte das komplette Projekt an, denn ich seh nix ueber deine DMA Konfiguration...
Deine DMA Groeße am Host kann auf keinen Fall stimmen, denn der FIFO wird am Host automatisch doppelt so groß gewaehlt wie am FPGA eingestellt und das solltest auch einhalten -> d.h. wennst unbedingt den FIFO vergroeßer willst, dann nimm das ganzzahlige vielfache davon...
Als 1. solltest du in deinem FPGA VI ein RS FF einbauen, damit du siehst ob der FIFO ueberlaeuft
Zum anderen koenntest eine While Schleife um den FIFO Block legen und den Ausgang Full an die Schleifenabbruchbedingung haengen (Continue if True).
Des weiteren versteh ich net warum du einen Offset von 65000 dazu zaehlst (wenn du damit vor hattest, auf 32bit zu mappen, dann ist das fehl geschlagen, weil der Ausgang nach wie vor I16 ist)
An der Stelle macht es mehr Sinn 2 AI Werte zusammen zu mappen (mit Join Numbers) und am Host einfach den Rueckweg nehmen (Split Numbers + Konvertierung in I16)
Des weiteren macht es bei dir keinen Sinn, dass du "Stop FIFO" bei der oberen Schleife anschließt, wo du nie sicher stellst ob des ueberhaupt fruchtet. weil du auch unten das Close drinnen hast...
Es reicht, wennst nach einer Schleife die Referenz schließt. Du arbeitest hier net mit OO sodass jede Abzweigung eine eigene Instanz ist...
Zusaetzlich ist deine CPU Last auf 100% weil die Funktion FIFO.Read pollt; d.h. wenn du X Elements anschließt, dann pollt die Funktion so lange, bis der Zeiger auf X steht und gibt dann die Werte zurueck.
Besser ist, wenn du mit einem kleinen Trick arbeitest, dadurch die CPU Last (je nach Timing auf unter 20% bringst), dafuer aber eine "leichte" dynamische Speicherallokierung hast... So wie ich das sehe, laeuft das VI unter Windows, dann ist das unterm Strich eigentlich egal :-)
In der 2ten Schleife hast ueberhaupt kein Timing drinnen...
' schrieb:Haeng das naechste Mal bitte das komplette Projekt an, denn ich seh nix ueber deine DMA Konfiguration...
Deine DMA Groeße am Host kann auf keinen Fall stimmen, denn der FIFO wird am Host automatisch doppelt so groß gewaehlt wie am FPGA eingestellt und das solltest auch einhalten -> d.h. wennst unbedingt den FIFO vergroeßer willst, dann nimm das ganzzahlige vielfache davon...
Als 1. solltest du in deinem FPGA VI ein RS FF einbauen, damit du siehst ob der FIFO ueberlaeuft
Zum anderen koenntest eine While Schleife um den FIFO Block legen und den Ausgang Full an die Schleifenabbruchbedingung haengen (Continue if True).
Des weiteren versteh ich net warum du einen Offset von 65000 dazu zaehlst (wenn du damit vor hattest, auf 32bit zu mappen, dann ist das fehl geschlagen, weil der Ausgang nach wie vor I16 ist)
An der Stelle macht es mehr Sinn 2 AI Werte zusammen zu mappen (mit Join Numbers) und am Host einfach den Rueckweg nehmen (Split Numbers + Konvertierung in I16)
Des weiteren macht es bei dir keinen Sinn, dass du "Stop FIFO" bei der oberen Schleife anschließt, wo du nie sicher stellst ob des ueberhaupt fruchtet. weil du auch unten das Close drinnen hast...
Es reicht, wennst nach einer Schleife die Referenz schließt. Du arbeitest hier net mit OO sodass jede Abzweigung eine eigene Instanz ist...
Zusaetzlich ist deine CPU Last auf 100% weil die Funktion FIFO.Read pollt; d.h. wenn du X Elements anschließt, dann pollt die Funktion so lange, bis der Zeiger auf X steht und gibt dann die Werte zurueck.
Besser ist, wenn du mit einem kleinen Trick arbeitest, dadurch die CPU Last (je nach Timing auf unter 20% bringst), dafuer aber eine "leichte" dynamische Speicherallokierung hast... So wie ich das sehe, laeuft das VI unter Windows, dann ist das unterm Strich eigentlich egal :-)
In der 2ten Schleife hast ueberhaupt kein Timing drinnen...
Danke für eure Antworten.
Ich werde morgen früh wenn ich am Arbeitsplatz bin alles nochmal genau durch lesen und versuche die Tips zu befolgen. Ich ahbe 65000 dazu addiert weil ich beim Anlegen des FIFO mit der Auswahl "Target to Host" nur die Möglichkeit U32 geboten bekomme. Dies bedeutet wohl vorzeichenloser Lon Int. Meine Messwerte sind jedoch auch negativer Natur und zur Übertragung vom FPGA zum Host musste ich mir was einfallen lassen. Ich habe 65000 dazu addiert und beim HOST wieder abgezogen.
Den FIFO habe ich in meinem Projekt mit einer Tiefe von 16388 Byte, oder was das sein mag, angelegt.
Wie meinst du das mit dem doppelt anlegen? Heißt das wenn ich zum Bsp. 10000 Werte auf dem FPGA in den FIFO schreibe und diese auf dem RT-HOST abrufen möchte muss dort eine 20000 bei FIFO.Depth stehen?
Dir erstmal danke freedive für die schnelle Antwort. Das mit der dynamischen Speicherallokierung ist ne echt super Idee. Hat meines Erachtens beträchtlich was gebracht. Das HOST.vi lasse ich aber auf dem RT-HOST laufen. Macht das Unterschiede? Ich dachte da gehört es hin und die Verbindung vom FPGA zum RT-HOST wäre schneller wie vom FPGA zum PC-HOST.
Du hattest mir nen Tip gegeben, ich solle ein RS FF ins FPGA.vi einbauen und ne While-Schleife um den FIFO legen. Ich weiß nicht wie ein RS FF aussieht und wie man ihn benutzt. Wozu dient dieser mir dann?
Ich habe mal vor nem viertel Jahr den Tip bekommen 3 VI's zu schreiben: 1 für FPGA, 1 für RT HOST (um speicherfressende Sachen die der FPGA nicht kann zu bewältigen) und zu guter letzt das PC HOST.vi um den RT Controller zu steuern. Nun habe ich das Problem das selbst wenn es mal so funktioniert das der FIFO ordentlich ausgelesen wird ich diese Datenpakete in ein Array speichern muss. Der RT Controller hat nur 64 MB zur Verfügung, d.h. er kann dies nicht. Meine Daten hole ich mit dem RT HOST.vi ab muss aber diese Pakete auf dem PC HOST in ein Array packen. Gibt es auch hier so ne Art FIFO den ich auf dem RT voll schreibe und auf dem PC HOST wieder auslese? Denn diese Verbindung zw. RT und PC ist ja über Netzwerk.
Gunni
(Hier ist jetzt mein komplettes Projekt angehängt)
nachdem am fpga unter normalen umstaenden alles innerhalb von x*25ns abgearbeitet ist, hast du wenig chancen einen FIFO ueberlauf durch einfaches auslesen der Status LED des DMA FIFOs mitzubekommen.
Deshalb sollte man sich beim FPGA Programmieren angewoehnen, entweder mit RS FF zu arbeiten, die den Wert so lange speichern bis man diesen quittiert ODER mit synchronous display (an der stelle wuerde ich dir raten ersteres vorzuziehen, weil zweiteres inoffiziell funktioniert aber nicht richtig ausgetestet wurde und du im zweifelsfalle keine ansprueche gegenueber NI stellen kannst :-))
zweiteres ist aber grundsaetzlich ein super feature dass man in vielen vielen lagen im fpga sehr sinnvoll nutzen kann...
anbei ein bsp eines rs ffs
mit dem dma schaffst du je nach anwendung eine best moegliche durchsatzrate von 10MB/s und im Normalfall 3-5MB/sec
auf keinen fall darst shared variablen verwenden :-)
die verbindung zw rt und windows host machst am besten ueber RT FIFOs und priorisierst die schleife in der die FPGA komm implementiert ist als zeitkritisch und die komm schleife mit tcp/ip zum windows host mit normaler prioritaet.
wennst mit der architektur net vertraut bist, dann programmier nur das fpga vi und verwende im anschluss den RT wizard -> hier aufpassen, weil du sicherlich im FPGA (TCL).vi nacharbeiten musst!
' schrieb:auf keinen fall darst shared variablen verwenden :-)
nur so am rande und bevor ich jetz das Off Topic Flag bekomme das macht dich richtig sympatisch!
ich hasse die Teile. Das ist der gleiche %"§$% wie Express VIs. Funktioniert wunderbar auf den Demo-Shows, aber wenn man damit arbeiten will stellt man sehr schnell fest, dass das doch nicht so wirklich was taugt ...
' schrieb:mit dem dma schaffst du je nach anwendung eine best moegliche durchsatzrate von 10MB/s und im Normalfall 3-5MB/sec
da ich derjenige war, der vor 3 Monaten den Tip gegeben hat, hab ich mich auch nochmal mit dem Thema beschäftigt.
zu den 100 kHz Sample Rate und DMA hab ich bei NI folgendes Dokument gefunden: Benchmarking Single-Point Performance .... Wenn ich das richtig interpretiere sind 100 kHz per DMA nicht möglich. Ich hab es nachgestellt auf *meinem* cRIO - cRIO 9004 + cRIO 9103 + NI 9215 + NI 9263 - ausprobiert und komme zu dem Ergebnis, dass man einen Datenstrom (U32) von 2 AI Kanälen bis max. 25 kHz sicher auf den RT-Host übertragen kann.
Testaufbau:
Ich hab mal - ansatzweise - probiert, ob das evtl. mit IRQs geht: Ich habs nicht mal geschafft, das FPGA VI zu kompilieren. Das liegt vermutlich an der falschen IRQ-Nummer. Der Compile Server läuft ins Leere und kann nur beendet werden, indem man die cmd.exe abschießt = Windows Neustart. Vermutlich hängt sich irgend eine Xilinx exe auf!? Leider hab ich noch keine Doku gefunden, wo drinsteht, welchen IRQ man nun wirklich verwenden kann - nur den Hinweis:
Zitat:Asserts an interrupt on the interrupt line of the FPGA target. Support of interrupts and the number of interrupts available varies according to the FPGA target. Refer to the specific FPGA target hardware documentation for more information.
Zu dem Problem von Gunni:
[aka: mit ner stinknormalen M-Serien Karte im PC hättest du diese Probleme nicht.]
Ich denke du kannst das nur dadurch lösen, dass du die Datenmenge, die zum RT-Host übertragen wird reduzierst. Das kannst du wiederum nur dadurch realisieren, dass du die Funktionen (z.B. FFT?, etc ...?) die du normalerweise auf dem PC-Host ausführen würdest bereits im FPGA implementierst - hoffentlich reichen die Gates
Der RT-Controler den du (wahrscheinlich) verwendest verfügt über einen 200 MHz Prozessor. Das ist nicht besonders schnell und reicht eigentlich genau dafür die TCP/IP Kommunikation zum PC-Host zu verwalten und die Daten vom und zum FPGA zu schaufeln. Ich denke nicht, dass es Sinn macht komplexe und rechenintensive Algorithmen auf dem RT-Host laufen zu lassen.
Ich hab mal mein Projekt angehängt, damit man schauen kann, wovon ich rede:
Dein Benchmark von NI beschreibt keinen DMA Transfer sondern eine typische Regelaufgabe, die bedacht ist Aktio und Reaktio zu implementieren...
Das senden von Werte ins FPGA Register benoetigt ca. 1.2µs und das abholen ca. 0.8µs
(dazu kommt dann noch ne Menge an Overhead) im normalen Betrieb...
Bei FPGA gelten diese Werte nicht mehr...
Mit DMA schaffst du 10MB im besten Fall und 3-5MB im Normalfall...
(Mit LabVIEW 8.20 hat sich der PID Algorithmus um einiges verbessert...)
Und aus deinem Programm kann man noch einiges raus holen +sfg+
23.01.2007, 07:30 (Dieser Beitrag wurde zuletzt bearbeitet: 23.01.2007 07:31 von cb.)
' schrieb:Dein Benchmark von NI beschreibt keinen DMA Transfer sondern eine typische Regelaufgabe, die bedacht ist Aktio und Reaktio zu implementieren...
ok ...
' schrieb:Das senden von Werte ins FPGA Register benoetigt ca. 1.2µs und das abholen ca. 0.8µs
(dazu kommt dann noch ne Menge an Overhead) im normalen Betrieb...
Bei FPGA gelten diese Werte nicht mehr...
HÄ??
' schrieb:Mit DMA schaffst du 10MB im besten Fall und 3-5MB im Normalfall...
Und aus deinem Programm kann man noch einiges raus holen +sfg+
ok, 3 MB pro Sekunde sind 3145728 Byte pro Sekunde oder 786432 U32 pro Sekunde, reicht also nach deinen Angaben auf jeden Fall um 8 AI Kanäle mit 100 kHz zu sampeln und in den Speicher des Controlers zu schieben. Warum bricht dann die Performance in meinem Beispiel bei >25 kHz und 2 Kanälen drastisch ein? bzw. was kann man noch rausholen? mach ma
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?
Was sollte eigentlich passieren wenn der FIFO überläuft und wie benutze ich den FlipFlop?
