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!
' schrieb:in der ersten Version war ein Bug bzw. das ganze VI ist Schrott, nimm mal die letzte Version, da ist das richtig implementiert
Gut aber nochmal zu meiner Frage. Die Daten werden doch bei TCP kontinuierlich gesendet - oder kann da auch nur in bestimmten Zeitabständen ein Austausch statt finden?
Sehe ich das richtig das du bei deinen Array die Teilarrays ersetzt - also dein gesamtes Array nicht ewig groß wird, sondern alte nicht mehr benötigte Teile werden überschrieben?
Auch wenn das jetzt eine Stata Maschine ist - Ich verstehe das Wesen einer solchen Sache nicht. Es ist doch so das du die Daten nicht parallele zum Auslesen des FIFOs sendest. In der State Maschine passiert alles Schritt für Schritt. Dauert das Senden der Datenpakete über TCP lange? Nicht das ich wenn ich sowas nachprobiere den FPGA FIFO ewig nicht auslesen kann weil der RT noch beim senden ist.
' schrieb:Gut aber nochmal zu meiner Frage. Die Daten werden doch bei TCP kontinuierlich gesendet - oder kann da auch nur in bestimmten Zeitabständen ein Austausch statt finden?
Sehe ich das richtig das du bei deinen Array die Teilarrays ersetzt - also dein gesamtes Array nicht ewig groß wird, sondern alte nicht mehr benötigte Teile werden überschrieben?
Auch wenn das jetzt eine Stata Maschine ist - Ich verstehe das Wesen einer solchen Sache nicht. Es ist doch so das du die Daten nicht parallele zum Auslesen des FIFOs sendest. In der State Maschine passiert alles Schritt für Schritt. Dauert das Senden der Datenpakete über TCP lange? Nicht das ich wenn ich sowas nachprobiere den FPGA FIFO ewig nicht auslesen kann weil der RT noch beim senden ist.
Gunni
die Daten werden bei TCP paketweise gesendet.
ja, ich ersetze immer ein Teilarray. Das mache ich desshalb, damit zur Laufzeit des RT VIs kein neuer Speicher allociert werden muss.
ja das Versenden der Daten benötigt Rechenzeit. Hättest du dir mal mein Post mit der Überschrift "vorläufiges Endergebnis" durchgelesen wüsstest du das.
' schrieb:...
ja, ich ersetze immer ein Teilarray. Das mache ich desshalb, damit zur Laufzeit des RT VIs kein neuer Speicher allociert werden muss.
ja das Versenden der Daten benötigt Rechenzeit.
...
Gut, aber du hast ja gesagt laut deinem Test ist es trotzdem möglich bei einer Abtastung von 100000 Samples/s Daten zu senden ohne Verlust.
Das mit den Teilarray ersetzen ist ne klasse Idee, aber ich habe doch bei meinem Beispiel ne dynamische Speicherallokierung vom FIFO - d.h. meine Datenpakete sind nicht immer gleich groß.
[attachment=31245:dynam_Sp...okierung.JPG]
Beim ersetzen der Teilaaray werden immer nur so viele Pakete ersetzt wie angegeben. Waren die Pakete vorher größer liest er ja dann noch alte Werte mit aus.
Wie kann man sowas verhindern?
' schrieb:Gut, aber du hast ja gesagt laut deinem Test ist es trotzdem möglich bei einer Abtastung von 100000 Samples/s Daten zu senden ohne Verlust.
Das mit den Teilarray ersetzen ist ne klasse Idee, aber ich habe doch bei meinem Beispiel ne dynamische Speicherallokierung vom FIFO - d.h. meine Datenpakete sind nicht immer gleich groß.
[attachment=31245:dynam_Sp...okierung.JPG]
Beim ersetzen der Teilaaray werden immer nur so viele Pakete ersetzt wie angegeben. Waren die Pakete vorher größer liest er ja dann noch alte Werte mit aus.
Wie kann man sowas verhindern?
Gunni
Himmelarschundzwirn, dann schau halt in meinen Quellcode! *händering* ich kann dir nun nicht jeden Draht und jede Funktion einzeln erklären.
Das letzte von mir hochgeladene Projekt enthält die fertige Musterlösung. Da musst/solltest/könntest/wasweisichst du dich jetzt mal intensiv einarbeiten und versuchen zu verstehen, was abgeht. Und unter intensiv einarbeiten verstehe ich nun nicht alle 3 Stunden mit einer Frage aufzuwarten "was macht der blaue Draht, darf ich den grünen durchknippsen oder geht der Alarm los, wenn ich den gelben abzwicke?", sondern folgendes:
Wenn du dich fragst, wie ein bestimmter Aspekt des VIs funktioniert, kopiere den Code in ein neues VI, lösch alles, was dir nicht relevant erscheint raus und lass das stark reduzierte VI im Highlightning Modus laufen, und schau dir genau an, was passiert. Wenn du wissen willst, was ein Baustein (die s.g. Primitives - meistens sind die ja hellgelb) macht schalte die Context-Hilfe ein (strg+H) geh mit der Maus über den Baustein und lies dir die Kontext-Hilfe durch. Wenn da nicht genug Infos drinstehen, klicke auf "mehr Hilfe" (detailed Help in der engl. Version) und lies dir die Hilfetexte durch.
Zu der Frage der dyn. Speicherallokierung: wie freedive schon in einer seiner letzten Posts zu diesem Thema erklärt hat: jein, es ist ein "bischen" dynamisch. Der Speicher für den FIFO wird auf den Host schon beim Start des VIs allociert. Ich verwende noch so eine art Zwischenpuffer mit der gleichen Größe des FIFOs, in den ich die aus dem FIFO ausgelesenen Werte schreibe. Dabei werden im Zwischenpuffer immer soviele Werte überschrieben (von index 0 an), wie ich aus dem FIFO bekomme. Dadurch schreibe ich immer in das gleiche Speicher-Segment im RAM (das wird einmalig beim Initialisieren des Arrays reserviert) und spare mir bis zum Umwandeln des Sub-Arrays in den binären String jede Menge Buffer allocations. Buffer-Allokations sind lokale Kopien der Daten auf dem Stack, die zur Laufzeit angelegt werden um die Daten in irgend einer Form zu bearbeiten. Auch das "Verkürzen" des Arrays mit "Get Array Subset" (Frame 8 von CRD01 RT Main DMA Raw.vi) verschwendet keine Rechenzeit durch "Buffer allocations".
' schrieb:Himmelarschundzwirn, dann schau halt in meinen Quellcode! *händering* ich kann dir nun nicht jeden Draht und jede Funktion einzeln erklären.
Das letzte von mir hochgeladene Projekt enthält die fertige Musterlösung. Da musst/solltest/könntest/wasweisichst du dich jetzt mal intensiv einarbeiten und versuchen zu verstehen, was abgeht. Und unter intensiv einarbeiten verstehe ich nun nicht alle 3 Stunden mit einer Frage aufzuwarten "was macht der blaue Draht, darf ich den grünen durchknippsen oder geht der Alarm los, wenn ich den gelben abzwicke?", sondern folgendes:
Wenn du dich fragst, wie ein bestimmter Aspekt des VIs funktioniert, kopiere den Code in ein neues VI, lösch alles, was dir nicht relevant erscheint raus und lass das stark reduzierte VI im Highlightning Modus laufen, und schau dir genau an, was passiert. Wenn du wissen willst, was ein Baustein (die s.g. Primitives - meistens sind die ja hellgelb) macht schalte die Context-Hilfe ein (strg+H) geh mit der Maus über den Baustein und lies dir die Kontext-Hilfe durch. Wenn da nicht genug Infos drinstehen, klicke auf "mehr Hilfe" (detailed Help in der engl. Version) und lies dir die Hilfetexte durch.
...
Entschuldigung das ich dir so auf den Zwirn gehe. Aber du weißt ja das es einem schwer fällt sich Dinge die man nicht kennt zu denken. Du machst halt nen fitten Eindruck. "Jetzt wo ich so einen der was drauf hat einmal an der Strippe hab lege ich ungern wieder auf."
' schrieb:Entschuldigung das ich dir so auf den Zwirn gehe. Aber du weißt ja das es einem schwer fällt sich Dinge die man nicht kennt zu denken. Du machst halt nen fitten Eindruck. "Jetzt wo ich so einen der was drauf hat einmal an der Strippe hab lege ich ungern wieder auf."
joh, weiß ich, ich mach dauernd Sachen, von denen ich erstmal überhaupt keine Ahnung habe. Die Kunst dabei ist - und das trifft auch auf eine DA zu - sich in kürzest möglicher Zeit in die Problematik einzuarbeiten und zu erkennen, welcher Weg der beste ist.
' schrieb:joh, weiß ich, ich mach dauernd Sachen, von denen ich erstmal überhaupt keine Ahnung habe. Die Kunst dabei ist - und das trifft auch auf eine DA zu - sich in kürzest möglicher Zeit in die Problematik einzuarbeiten und zu erkennen, welcher Weg der beste ist.
Guten Morgen.
Ich weiss ich sollte dich nicht weiter stören, aber du hast dich gerade mit der TCP-Tematik auseinandergesetzt und kannst mir vielleicht auf einen Blick sagen was bei mir falsch ist.
Ich probiere im Moment nur eine Kommunikation über TCP und das HOST.vi bricht schon mit folgender Meldung ab.[attachment=31268:Fehler_bei_TCP.jpg]
Nun bin ich total überfordert. Das alles sah so leicht und verständlich aus. Ich habe versucht etwas in abgespeckter Version aus deinem Beispiel zu entnehmen, wie du es mir empfohlen hast. Nur leider war ich auf solch Fehlermeldung nicht gefasst.
In meinem Projekt tut sich gar nichts.[attachment=31269:Communic..._Projekt.zip]
Bitte schau es dir mal an. Vielleicht sieht dein routiniertes Auge den simplen Fehler sofort.
' schrieb:Ich weiss ich sollte dich nicht weiter stören, aber du hast dich gerade mit der TCP-Tematik auseinandergesetzt und kannst mir vielleicht auf einen Blick sagen was bei mir falsch ist.
Ich probiere im Moment nur eine Kommunikation über TCP und das HOST.vi bricht schon mit folgender Meldung ab.
das sieht so aus, als käme gar keine Verbindung zustande. Das Problem könnte folgendes sein: Ich sehe, du gibt öffentlich IP Adressen an (172er Namensraum), vermutlich versuchst du die Daten über das UNI-Netz zu schicken? Es könnte gut sein, dass der von dir angegebene Port gar nicht geroutet wird! oder dass der Router diese schnelle Abfolge von Paketen als DNS-Angriff wertet und den Traffic unterbindet.
Versuch mal folgendes: besorg dir einen Switch und verbinde das cRIO direkt mit deinem PC OHNE über das Uni-Netz zu gehen und gib dem PC und dem cRIO eine IP Adresse aus dem privaten Namensraum (z.B. 192.168.1.1 und 192.168.1.2). Ich hab deine VIs getestet und bei mir funktioniert die Übertragung einwandfrei.
Du kannst ja ggf. auch erstmal versuchen Daten von einem PC auf einen anderen zu schicken, dann musst du dich gar nicht mit dem cRIO beschäftien. Ich hab in das Projekt mal ein VI "PC Server" eingefügt, mit dem die die Daten-Übertragung von PC zu PC testen kannst. Bei mir funktionieren die beiden VIs einwandfrei (ERST das PC Server.vi starten, dann das PC Host.vi !! der Listener im Server wartet 60 Sekunden, dass eine Verbindung reinkommt ...)
Schön zu sehen, dass du nun weisst was eine State-Machine ist:)die flat sequence um die While-Schleife brauchst du nicht, das regelt der Datenfluss alleine. Die roten Punkte an Funktionen etc. heissen "Coercion Dot". Das Bedeutet, dass du an dieser Stelle von einem Datentyp zu einem anderen umwandelst. Das solltest du auf einem RT Ziel tunlichst vermeiden, auf dem FPGA ist es quasi total verboten und eine unerschöpfliche Quelle schwer zu findender, unerklärlicher Bugs. Coercion Dots vermeidet man am besten dadurch, dass man die Datentypen konsistent hält (Rechtsklick auf die Konstante --> Representation --> Datentyp auswählen ...)
' schrieb:das sieht so aus, als käme gar keine Verbindung zustande. Das Problem könnte folgendes sein: Ich sehe, du gibt öffentlich IP Adressen an (172er Namensraum), vermutlich versuchst du die Daten über das UNI-Netz zu schicken? Es könnte gut sein, dass der von dir angegebene Port gar nicht geroutet wird! oder dass der Router diese schnelle Abfolge von Paketen als DNS-Angriff wertet und den Traffic unterbindet.
Versuch mal folgendes: besorg dir einen Switch und verbinde das cRIO direkt mit deinem PC OHNE über das Uni-Netz zu gehen und gib dem PC und dem cRIO eine IP Adresse aus dem privaten Namensraum (z.B. 192.168.1.1 und 192.168.1.2). Ich hab deine VIs getestet und bei mir funktioniert die Übertragung einwandfrei.
Du kannst ja ggf. auch erstmal versuchen Daten von einem PC auf einen anderen zu schicken, dann musst du dich gar nicht mit dem cRIO beschäftien. Ich hab in das Projekt mal ein VI "PC Server" eingefügt, mit dem die die Daten-Übertragung von PC zu PC testen kannst. Bei mir funktionieren die beiden VIs einwandfrei (ERST das PC Server.vi starten, dann das PC Host.vi !! der Listener im Server wartet 60 Sekunden, dass eine Verbindung reinkommt ...)
...
Danke erstmal für deine schnelle Antwort i2dx.
Deine Vermutung war natürlich goldrichtig und nachdem ich die Geräte direkt mit Cross-Over-Kabel verbunden habe lief mein Kommunikationsprojekt einwandfrei. Also habe ich die State-Mashine auch in mein eigentliches Projekt übertragen und dort muckte die ganze Geschichte wieder rum - es gäbe wohl keine verbindung zwischen meinem PC und dem RT-Controller. Und das obwohl ich im MAX das Gerät sehe und keine Verbindungsprobleme zu haben scheine. Also dachte ich mir ich Eröffne ein komplett neues Projekt und suche den Controller mit dem FPGA-Target und kopiere meine VIs dort rein. :angry2:Pustekuchen ! Jetzt fand er zwar meinen RT-Controller aber als ich das target suchte meldete er mir wieder das keine Verbindung möglich wäre. Ich dachte mir das wenigstens das Starten des RT-VIs geht - aber beim runterladen meldete das Gerät mir auch hier wieder ein Verbindungsfehler.
Auf jeden Fall danke ich dir - du hast mir sehr geholfen.
' schrieb:Ich dachte mir das wenigstens das Starten des RT-VIs geht - aber beim runterladen meldete das Gerät mir auch hier wieder ein Verbindungsfehler.
joh, dann hast du wirklich einen Verbindungsfehler. Hast du die IP-Adressen so geändert, wie ich dir geraten hatte? Dann musst du die IP-Adresse des RT-Controlers ggf. auch im Projekt ändern. LV "merkt" sich die letzte Adresse und da steht ggf. die falsche Adresse drin.
Dass du das Gerät im MAX siehst kommt dadurch zustande, dass jeder RT-Controler beim Booten (?) auch einen UDP-Broadcast sendet, der vom MAX empfangen wird. Sonst könntest du ja z.B. niemals ein Gerät, dass im Auslieferungszustand die IP-Adresse 0.0.0.0 hat über den MAX konfigurieren und eine neue Netzwerkadresse zuweisen.
"
