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!
24.05.2013, 11:41 (Dieser Beitrag wurde zuletzt bearbeitet: 24.05.2013 11:41 von GerdW.)
Zitat:Und wenn ich das zB so wie eben erwähnt nacheinander schreibe, also Messwert, Zeitstempel, Messwert usw, dann weiß ich doch, dass der Messwert zeitlich zwischen den beiden Zeitstempeln liegt oder nicht?
Woher weiß dein RT, welcher Wert was bedeutet? Wenn du Werte wie a,b,a,b bekommst: woran erkennst du, was a und was b bedeutet? Und bevor du antwortest "Das weiß ich doch, weil ich auf dem RT schnell genug lese und der FIFO nie überläuft!": nur weil du denkst, ein Fehler könnte nicht auftreten, heißt, nicht, dass er niemals auftreten wird...
Ich schreibe deshalb Werte wie c,a,b,a,b,c,a,b,a,b, wobei "c" eine Konstante ist, die in den Messdaten nicht vorkommt. Daran erkennt der RT-Teil immer, wann ein neuer Datenblock beginnt...
Zitat:Der relative Zeitstempel ist doch der TickCount zB in ms oder us o.ä. ?
Den kannst du auch verwenden. Ich weiß aber nicht, ob und wieviel Overhead noch in diesem Aufruf versteckt ist. Man kann auch einen eigenen Counter nehmen, der einfach Schleifendurchläufe zählt - die auf dem FPGA (fast immer) mit fester/bekannter Zeit ablaufen.
also meine Messwertanalyse muss nicht online erfolgen, daher reicht es, wenn ich die Daten an einen Host geschickt bekomme und dort speichern kann.
allerdings hab ich jetzt eine neues Problem... hab zunächst erstmal alle Anzeigen auf fpga und rt Level weggemacht, um die Last zu reduzieren.
ich schreibe in den FIFO Zeitwert, Messwert, Zeitwert, Messwert ... (allerdings noch ohne eigenen Counter, sondern mit dem Tickcount s. attachment fpga)
Wenn ich mir jetzt eine Sonde auf RT Level mache, sehe ich in der Zeitkritischen Schleife noch alle Daten (jeder ms-Wert und Messwert nacheinander).
Auf dem Rechner kommt allerdings zB. nur noch so was hier an
Zum einen sind die Messwerte nicht mehr äquidistant verteilt ? manchmal sind 60 ms dazwischen Zeit, oft nur 20 ms. Und wieso überhaupt 20 ms, ich hatte eigentlich 1 ms Wartezeit eingestellt zwischen den Messpunkten eingestellt. Und auf dem RT Level laufen die beiden Schleifen mit 10 ms, dh in 10 ms sollten 20 Werte ankommen (10 Messwerte und 10 Zeitwerte im Wechsel). Ich habe für die Variable "Daten" Typ Netzwerk eingestellt und bei Netzwerk Puffern aktiviert mit 1 Array von 2 Elementen. RT FIFO hab ich auch aktiviert, Einzelnes Element, 1 Array, 2 Elemente. Sind die Einstellungen richtig zum Zwischenspeichern?
Allerdings müsste (falls der Fehler am Zwischenspeichern lag) ja eigentlich alle 10 ms Messwerte aufgezeichnet werden, da determistischer und nichtdeterministischer Loop mit 10 ms laufen. Muss ich hier überhaupt den gleichen Wert einstellen ? War die Rechnung oben eigentlich richtig ? in 10 ms 20 Elemente ? Soll ich den Fifo dann bei der Konfiguration auf 30 Elemente stellen auf RT Seite zB Anzahl Elemente von 30 einstellen mit einem Timeout von 15 ms ? Und auf FPGA Seite dann auch Timeout von 15 ms ? Wären das sinnvolle Werte ?
Auf der Hostseite kann man, wenn man sich die Anzeige der Daten und der Iteration der Netzwerkschleifen beobachten, dass manchmal bei jedem Schleifendurchlauf neue Werte kommen bzw aktualisiert werden und manchmal Sekundenlang nichts passiert und nur die Iterationen hochzählen. Das scheint irgendwie ein Kommunikationsproblem zu sein, aber ich dachte man hat extra die Netzwerkstreamfunktionen um eine Art Handshaking zu machen ? Oder muss von der Hostseite noch eine Art Bestätigung zurückkommen ?
hoffe, dass das hier noch einigermaßen reingehört...
mfG Erik
ps: beim Ausführen steht öfters die Meldung:
Warte auf Antwort des Real-Time Zielsystems (CRIO....)
Verbindung beenden? Woher kommt die große Auslastung?
ah okay, hab ein Problem schon gelöst bekommen,
wenn ich die Zeit für die getakteten Schleifen auf dem RT Level auf 100 ms stelle, kommen die Daten ohne Verlust an und können gespeichert werden. Es lag scheinbar eindeutig an der Auslastung.
Die Messdaten sehen zB so aus:
-15552,000000
91,000000
-15452,000000
93,000000
-15352,000000
94,000000
-15252,000000
80,000000
-15152,000000
82,000000
-15052,000000
96,000000
Das heißt, er nimmt die 100 ms als Wert.
In der zeitkritischen Schleife, kommen noch jede ms Messwerte, allerdings nicht mehr in der Netzwerkschleife. Dabei hab ich doch Puffer für die Netzwerkvariable eingestellt...
Warum schreibst du eigentlich nicht direkt in den Netstream und gehst stattdessen den Weg über die Shared Variable mit RT Fifo? Würde ich an der Stelle weglassen wenn es nicht einen guten Grund dafür gibt. Vielleicht überseh ich den auch einfach nur
danke für den Tipp... bin wie gesagt noch Anfänger; dachte ich brauche die Variablen auch eventuell zum Puffern der Daten;
ich habe es jetzt hinbekommen!allerdings ging es nicht über 2 Loops (siehe Att 1), sondern nur, wenn ich einen Loop nehme wo zeitkritische und netzwerk Kommunikation in einem bearbeitet wird; wozu sind dann der deterministische und nicht deterministische Loop ???
vielen Dank für die Hilfe, ich denke ich kann jetzt meine Messwerte nehmen und das Projekt dann beenden
11.06.2013, 21:53 (Dieser Beitrag wurde zuletzt bearbeitet: 11.06.2013 21:54 von Holy.)
Der DMA FIFO selbst ist schon ein Puffer, daher würdest du den Puffer nochmals puffern und dies erhöht nur unnötig die Komplexität.
Das Frontend der Netstreams selbst ist, je nach Konfiguration, nichtblockend. Daher kann man das Problemlos in der Schleife mit haben ohne Probleme zu bekommen. Dein 1. Bild kann nicht funktionieren da die 2. Schleife, aufgrund der Datenabhängigkeit, erst loslaufen darf wenn die 1. beendet ist. Das meinte ich natürlich nicht sondern dein Bild 2, ohne den Wegfall der 2. Schleife explizit zu erwähnen. Weiterhin hattest du 2 Timed Loops also 2 deterministische Schleifen, was meinst du daher mit 1 deterministischen und 1 normalen Loop?
achso na ich hatte mit dem Wizard ein Echtzeitprojekt erstellt, und da war hieß die eine Schleife deterministic und hatte Priorität 100 und die 2. hieß non deterministic und hatte Priorität 50; war der Meinung, gelesen zu haben, dass in den deterministischen Teil die Datenerfassung via FIFO muss und in den nicht deterministischen Teil der Netzwerkstream; bring da bestimmt irgendwas durcheinander, hatte mich halt an dem vorgefertigten Bsp entlanggehangelt...
Der Ansatz ist prinzipiell korrekt, insbesondere Kommunikation in die nicht deterministische Schleife zu verlagern. Aber in einer reinen Streaming-Anwendung (FIFO lesen und über Netstream wegsenden) ist Determinismus eigentlich garnicht notwendig. Man kann sowas prinzipiell auch so aufbauen wie du es orginal hattest aber wenn es nicht zwingend notwendig ist, ist es nur eine potentielle Fehlerquelle
