FIFO Benutzung

' schrieb:Ich habe mich jetzt umgehört und hab da was von DataSocket aufgeschnappt. Da ich keine Ahnung habe von Shared Variables (da muss man beim anlegen schon so viel beachten) und die normale TCP/IP- Geschichte bei meinem versuch nicht geklappt hat möchte ich was anderes Bekanntes ausprobieren. Bei DataSocket läuft aber auch so ne extra Sache im Hintergrund. Das ist aber meines Erachtens ne fertige und damit ausgereifte Sache die sich um die Übertragung kümmern kann.

Ich hoffe mal das damit die Datenübertragung geht - das Signal wird mit 100kHz abgetastet und das muss es auch, damit bei 10kHz Sinus noch 10 Punkte pro Schwingung übrig bleiben.

Gunni

Wie stark schwankt denn der Pegel deines zu messendem Signals?
Vielleicht wäre es ja sinnvoll die Daten nicht als Double oder so zu über tragen sondern in ein int8 oder int16 zu skalieren?

Oder halt doch eine Komprimierung implementieren.. *duck*

Gruß, Robert

Anzeige

' schrieb:Wie stark schwankt denn der Pegel deines zu messendem Signals?
Vielleicht wäre es ja sinnvoll die Daten nicht als Double oder so zu über tragen sondern in ein int8 oder int16 zu skalieren?

Oder halt doch eine Komprimierung implementieren.. *duck*

Gruß, Robert

Komprimierung kostet Rechenzeit und die ist sowieso schon knapp. Da die Daten aber vermutlich als I16 aufgezeichnet werden kann man die Datenmenge schonmal halbieren, in dem man Singles überträgt, nach meiner Rechnung wären dass dann 50 kHz mit 2 Kanälen. Wenn er die Rohdaten schickt, könnt es evtl. ausreichen ...

' schrieb:Komprimierung kostet Rechenzeit und die ist sowieso schon knapp. Da die Daten aber vermutlich als I16 aufgezeichnet werden kann man die Datenmenge schonmal halbieren, in dem man Singles überträgt, nach meiner Rechnung wären dass dann 50 kHz mit 2 Kanälen. Wenn er die Rohdaten schickt, könnt es evtl. ausreichen ...

Ich komme bei euch nicht mehr so richtig mit. Was sind denn Singles? Wenn du dann 50 kHz mit zwei Kanälen hast sollte es doch nach meiner Annahme mit einem Kanal und 100kHz auch gehen. Ich benutze ja auch nur einen. Wie funktioniert das Halbieren?

Gunni

' schrieb:Ich komme bei euch nicht mehr so richtig mit. Was sind denn Singles? Wenn du dann 50 kHz mit zwei Kanälen hast sollte es doch nach meiner Annahme mit einem Kanal und 100kHz auch gehen. Ich benutze ja auch nur einen. Wie funktioniert das Halbieren?

Gunni

ich verwende in meinem Beispiel den Datentyp Double, sprich ich berechne aus den Rohdaten, die vom FPGA kommen bei der Umwandlung von binär zu nominal Fließkommawerte des Datentyps Double. Der Datentyp Single ist auch eine Fließkommazahl, aber mit - gegenüber dem Double - stark eingeschränkter Genauigkeit bzgl. der Nachkommastellen. Ein Double benötigt 8 Byte, ein Single aber nur 4. Somit reduziert sich die Datenmenge, die man übertragen muss schonmal um die Hälfte, wenn man statt Doubles Singles verwendet, wobei sich dann eben die Genauigkeit reduziert.

Wenn du nun aber ein 16 bit Analog-Eingangs-Modul verwendest, das einen 20 Volt Eingangsbereich in 65535 "Häppchen" aufteilt, dann kannst du damit max. 0,3 mV auflösen. Die höhere Genauigkeit des Doubles bringt also erstmal keinen Vorteil, insbesondere nicht, wenn du die Daten NUR übertragen willst und nicht auf dem RT-Host damit noch irgendwelche Berechnungen anstellen willst.

Weiterhin ist der Datentyp des 16 Bit AI Moduls auf I16 festgelegt, der braucht nur 2 Bit. Wenn du also direkt die Rohdaten vom FPGA zum PC überträgst und erst auf dem PC die Umrechnung von binär zu nominal vornimmst, sparst du für die Übertragung 75% der Bandbreite gegenüber meinem Beispiel. Damit sollte es möglich sein einen Kanal @100 kHz auf den PC zu streamen.

Wenn mir die Anmerkung erlaubt ist: einen 10 kHz Sinus mit 100 kHz zu sampeln und dann "vernünftige" Ergebnisse zu erwarten ist recht optimistsich. Ich würde nochmals vorschlagen, lass das mit dem FPGA bleiben und kauf dir für rund 1000 Euro eine schöne M-Serien Messkarte + Anschlusstechnik für den PC. Damit kannst Sample-Raten bis zu 1 MHz realsieren, das ist dann auch ausreichend um ein schnelles Sinus-Signal zu messen und verwertbaren Ergebnissen zu kommen.

' schrieb:ich verwende in meinem Beispiel den Datentyp Double, sprich ich berechne aus den Rohdaten, die vom FPGA kommen bei der Umwandlung von binär zu nominal Fließkommawerte des Datentyps Double. Der Datentyp Single ist auch eine Fließkommazahl, aber mit - gegenüber dem Double - stark eingeschränkter Genauigkeit bzgl. der Nachkommastellen. Ein Double benötigt 8 Byte, ein Single aber nur 4. Somit reduziert sich die Datenmenge, die man übertragen muss schonmal um die Hälfte, wenn man statt Doubles Singles verwendet, wobei sich dann eben die Genauigkeit reduziert.

Wenn du nun aber ein 16 bit Analog-Eingangs-Modul verwendest, das einen 20 Volt Eingangsbereich in 65535 "Häppchen" aufteilt, dann kannst du damit max. 0,3 mV auflösen. Die höhere Genauigkeit des Doubles bringt also erstmal keinen Vorteil, insbesondere nicht, wenn du die Daten NUR übertragen willst und nicht auf dem RT-Host damit noch irgendwelche Berechnungen anstellen willst.

Weiterhin ist der Datentyp des 16 Bit AI Moduls auf I16 festgelegt, der braucht nur 2 Bit. Wenn du also direkt die Rohdaten vom FPGA zum PC überträgst und erst auf dem PC die Umrechnung von binär zu nominal vornimmst, sparst du für die Übertragung 75% der Bandbreite gegenüber meinem Beispiel. Damit sollte es möglich sein einen Kanal @100 kHz auf den PC zu streamen.

Wenn mir die Anmerkung erlaubt ist: einen 10 kHz Sinus mit 100 kHz zu sampeln und dann "vernünftige" Ergebnisse zu erwarten ist recht optimistsich. Ich würde nochmals vorschlagen, lass das mit dem FPGA bleiben und kauf dir für rund 1000 Euro eine schöne M-Serien Messkarte + Anschlusstechnik für den PC. Damit kannst Sample-Raten bis zu 1 MHz realsieren, das ist dann auch ausreichend um ein schnelles Sinus-Signal zu messen und verwertbaren Ergebnissen zu kommen.

Nee, nee. Das mit dem FPGA geht schon in Ordnung - der wurde mir für die Diplomarbeit gestellt. Zur Diplomverteidigung kann ich es ja erwähnen das die Aufgabe sich mit so ner M-Serie besser lösen ließ. Bei dieser Aufgabe ist es nur von Nöten das Signal als Sinus, Rechteck oder sonstiges wie es erzeugt wurde zu erkennen und um zu kontrollieren ob nach gewisser Zeit eine Dämpfung eintritt. Dafür reichen die 10 Punkte denke ich mal aus.

Wenn ich dich jetzt richtig verstehe dann meinst du meine Daten des mit 100kHz abgetasteten Signals kann ich problemlos vom RT zum PC schieben? Ich habe sie aber auf dem RT schon in Double umgewandelt.


Gunni

' schrieb:Wenn ich dich jetzt richtig verstehe dann meinst du meine Daten des mit 100kHz abgetasteten Signals kann ich problemlos vom RT zum PC schieben? Ich habe sie aber auf dem RT schon in Double umgewandelt.

habs grad getestet, es geht, einen Kanal als I16 per TCP zum PC übertragen klappt einwandfrei mit einem 100 MBit Netzwerk

' schrieb:habs grad getestet, es geht, einen Kanal als I16 per TCP zum PC übertragen klappt einwandfrei mit einem 100 MBit Netzwerk

Okay. In deinem ersten Versuchsbeispiel aus dem Forum habe ich gesehen das du die Daten aus deinem FIFO ausließt und dann in einen der nächsten Case-Fälle los sendest. Zuvor hattest du die TCP-Verbindung hergestellt. Das alles liegt bei dir in deiner Hauptschleife.

Wenn ich jetzt kontinuierlich meine Daten aus dem FIFO auslese und abschicken möchte, muss ich da auch jedesmal die TCP-Verbindung neu herstellen und nach dem Senden kappen. Oder sollte ich die Verbindungsgeschichte nicht vor der Hauptschleife einmal machen und nach der Hauptschleife schließen? Denn wenn ich jedesmal erst die Verbindung erneut herstelle wartet der TCP-Listener doch auch jedesmal.

Ich versuche nämlich gerade ein einfaches Projekt wo ich nur Arrays (den Datenpaketen aus dem FIFO entsprechend) los schicke und auf dem PC empfange.
So richtig weiß ich noch nicht wie ich es anstellen soll denn im richtigen Projekt kommen die Pakete ja auch mal in kleinen und mal in großen Stücken. Die Durchlaufzeit schwankt deshalb auch etwas hin und her. Muss ich da jetzt noch einen RT FIFI zwischen abgeholten Paketen aus dem FPGA FIFO und der Sendevorrichtung mit TCP einbauen? Oder liegen diese Pakete in der Leitung abholbereit (so ne Art interner Zwischenspeicher)?


Gunni

' schrieb:Okay. In deinem ersten Versuchsbeispiel aus dem Forum habe ich gesehen das du die Daten aus deinem FIFO ausließt und dann in einen der nächsten Case-Fälle los sendest. Zuvor hattest du die TCP-Verbindung hergestellt. Das alles liegt bei dir in deiner Hauptschleife.

:wacko:das ist eine State Machnine ...

' schrieb:Muss ich da jetzt noch einen RT FIFI zwischen abgeholten Paketen aus dem FPGA FIFO und der Sendevorrichtung mit TCP einbauen?

nein, der Fiffi bleibt zu hause

' schrieb:Oder liegen diese Pakete in der Leitung abholbereit (so ne Art interner Zwischenspeicher)?

nein, das widerspräche ja grundlegend dem Sinn und Zweck einer Peer to Peer Verbindung

' schrieb:Ich versuche nämlich gerade ein einfaches Projekt wo ich nur Arrays (den Datenpaketen aus dem FIFO entsprechend) los schicke und auf dem PC empfange.

falls es dir noch nicht aufgefallen ist, das ist in meinem Projekt schon mit drin (die beiden Speed-Test VIs ...)

' schrieb:...
falls es dir noch nicht aufgefallen ist, das ist in meinem Projekt schon mit drin (die beiden Speed-Test VIs ...)

Also wenn ich das richtig verstehe werden die Daten per TCP kontinuierlich los geschickt und du hast in deinem Speed-Test die einezelnen Pakete als Teilarray zu einem Array dazu gepackt. Wenn ich bei mir die Datenpakete als Teilarray zu einem Array dazu tue sind meine 64 MB Festspeicher auf dem RT in 7 Sekunden voll.

Kannst du mir da mal bitte auf die Sprünge helfen wie ich das realisieren könnte?


Gunni

' schrieb:Also wenn ich das richtig verstehe werden die Daten per TCP kontinuierlich los geschickt und du hast in deinem Speed-Test die einezelnen Pakete als Teilarray zu einem Array dazu gepackt. Wenn ich bei mir die Datenpakete als Teilarray zu einem Array dazu tue sind meine 64 MB Festspeicher auf dem RT in 7 Sekunden voll.

Kannst du mir da mal bitte auf die Sprünge helfen wie ich das realisieren könnte?
Gunni

in der ersten Version war ein Bug bzw. das ganze VI ist Schrott, nimm mal die letzte Version, da ist das richtig implementiert


  crio_01_final.zip (Größe: 1.019,04 KB / Downloads: 381)