Datei-I/O bei LV-Real-Time (Prioritäten, ...)

Hallo ihr beiden,

danke für eure wirklich interessanten Antworten.

@Jens: Das klingt sehr interessant und die Größe der Daten müsste immer gleich sein. Das sind einzelne boolsche Werte und Arrays, deren Länge ich von vornherein fest vorgebe (damit nicht laufend neu Speicher zugewiesen wird). Daher müsste das gehen.
Hast du mir da einen kleinen Code-Schnippsel, damit ich mir angucken kann, wie du das meinst?

Die Dateiposition beim neuen Element ans Ende setzen und wie lösche ich dann die ersten x Bytes oder kann ich da etwas wie "SizeOf(MeinCLuster)" übergeben, um das SubVI allgemein zu halten?
Was bei der Lösung natürlich kompliziert wird, ist das Auslesen:
Ich schreibe z.B. Messung 1 von Sensor 1 in die Datei, dann Messung 1 von Sensor 2, dann Messung 2 von Sensor 1 und dann Messung 2 von Sensor 3 etc. und muss das möglichst wieder auseinander fummeln können.
Bei einzelnen Dateien kann ich da wunderbar pro Sensor ein Verzeichnis anlegen (oder pro Messung) und dort die Dateien organisieren. Anders bräuchte ich vermutlich einen Header pro Eintrag.

' schrieb:Wie groß darf denn dein Jitter sein auf der Sendeseite?

Ein Schleifendurchlauf dauert vielleicht 20 - 30 ms und das sollte eben alles im Rahmen sein. Also eine Unterbrechung von 100 ms wäre dort nicht gut. Daher wollte ich das auslagern und in der Ruhephase der zeitkritischen Schleife durchführen.

' schrieb:Ich weiss das du auf keinen Fall da 'ne Queue nehmen wirst, deshalb an dieser Stelle nur viel Erfolg beim implentieren deines RT-FIFO Ansatzes mit vielen Schreibern und Lesern (und kleinerem Jitter). Ich bin mir sicher das geht, aber ob es den Aufwand tatsächlich Wert ist?

Wenn ich keinen Denkfehler gemacht habe ist das nun einfach und ordentlich gelöst. Ich habe ein SubVI, das mir die Referenzen erstellt, eines, das Daten hineinschreibt, eines, das sie ausliest und eines, das sie am Ende schließt (falls es mal ein Programmende geben sollte).
Das Ganze ist dynamisch (For-Schleifen) und als Eingänge habe ich diverse Arrays/Werte, die je nach Anzahl entsprechende Referenzen anlegen. Die Anzahl ändert sich im laufenden Betrieb zwar nicht, aber so bin ich für zukünftige Projekte gerüstet.
Aber ob das funktioniert, wird sich hoffentlich morgen zeigen.
Wenn die SubVIs so funktionieren, wie ich mir das vorstelle, muss ich mich auch nicht mehr um die unterschiedlichen Datentypen kümmern. Ich gebe denen ein Cluster vor und der wird dann intern auf die verschiedenen RT-FIFOs aufgeteilt.
Aber Theorie und Praxis sind 2 paar Stiefel. Ich bin selbst gespannt.

' schrieb:Du wolltest ja Tips aus der Praxis... und in der Praxis habe ich schon cRIO Projekte mit RT-FIFOs und Queues auch im Mischbetrieb gesehen, die laufen wie 'ne eins. Mit mehreren TimedLoops und recht harten Echtzeitanforderungen.

Das glaube ich dir gerne, aber sobald größere Daten an die Queues übergeben werden (Messreihen), kann das zu einem recht hohen Jitter führen, denke ich. Vor allem dann, wenn versucht wird, gleichzeitig lesend und schreibend auf die Queue zuzugreifen. Kann man das ausschließen (ich kann's nicht), sind die Queues sicherlich problemlos einsetzbar oder halt bei kleinen Datenmengen.
Wenn ich das mit den RT-FIFOs nicht gebacken bekomme, werde ich den Einsatz von Queues versuchen, aber da bleibt mir dann immer ein etwas mulmiges Gefühl, muss ich zugeben. Doch es ist interessant zu hören, dass ihr das so ensetzt.
Habt ihr da auch große Datenmengen, die ihr in den Queues transportiert oder sind das nur z.B. boolsche Werte um eine bestimmte Aktion daraufhin ausführen zu können ("MessendeErreicht" oder sowas)?

' schrieb:Wenn es irgendwie geht, würde ich versuchen von einem Filebased Ringpuffer weg zu kommen (ggf. die Requirements dazu nochmal hinterfragen). Die SSDs sind zwar inzwischen super robust, aber darauf anlegen würde ich es trotzdem nicht. Also das Ganze RAMbased und entweder nur recht selten Schreiben oder komplett nur auf Anforderung des Hosts.

Da gebe ich dir Recht, nur ist das für uns nicht praktikabel. Das cRIO muss Daten loggen und wenn man später sieht, dass eine Messung schlecht war, muss man nachträglich auf die Daten zurückgreifen können.
Später werden wahrscheinlich nur die Messungen protokolliert, die fehlerhaft waren und die sollten nach Möglichkeit gegen Null gehen (Null ist natürlich unrealistisch), aber es werden dann wohl verhältnismäßig wenig Daten geschrieben. Nur im Worstcase-Fall (alle Messungen laufen gleichzeitig, sind gleichzeitig beendet und alle fehlerhaft (Teil n.i.O), soll das Programm weiter laufen.