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!
mit Hilfe von LabVIEW 8,6 und einer cRIO, die sowohl mit analogen, als auch mit digitalen Ein- und Ausgängen bestückt ist, bauen wir gerade eine Geschwindigkeitsregelung auf. Aufgrund unserer Anforderung, muss der Regler mit einer Frequenz im kHz-Bereich arbeiten. Da LabVIEW auf Host-Ebene keine zeitgesteuerte Schleifen im mikrosekunden-Bereich anbietet, läuft die Regelung auf RT-Ebene. Der Host wird also nur als MMI und Parametereingabe genutzt.
Natürlich benötigen wir - insbesondere zur Regleroptimierung - die Funktion der Datenprotokollierung. Bislang erreichen wir das mit der normalen Spreadsheet String-Funktion und speichern die txt-Datei direkt auf dem Speicher der cRIO. Das widerrum ist notwendig, weil wir nicht mit Umgebungsvariablen arbeiten können, mit deren Hilfe die Werte auf den Host geschickt werden könnten.
Unser Problem ist, dass die RT die Werte "nach eigenem Ermessen" speichert. Der max. Speichertakt liegt in der Größenordung von 50ms und variiert stark. Das Variieren ist nicht gut aber wäre zu verkraften aber die Speicherfrequenz von ungefähr 50Hz ist viel zu wenig. Die alte Regelung auf C-Basis schaffte das mit 200Hz und musste die Werte noch durch eine lahme RS232 schicken.
Jetzt meine Frage: Wie könnte der Speicherungsintervall reduziert werden? Die Protokollierung mit TDMS soll ja schneller sein, jedoch haben wir diese Art bislang nur auf PC-Ebene geschafft! Welche Protokkolierungsmethode ist auf der RealTime-Ebene überhaupt möglich?
für die Kommunikation RT und Host kann man eigentlich ganz gut DMA-FIFOs verwenden - die sind mindestens so schnell wie Deine Hardware und durch DMA auch so groß, das das gut geht. Dann muss natürlich das System mit dem PC verbunden sein - zum Testen ist das aber sicherlich der Fall. Sonst musst Du glaub ich das SD-Karten-Modul haben, um auf den Karten speichern zu können...
Das das RT die Daten "nach eigenem Ermessen" speichert, wage ich allerdings zu bezweifeln... Lad doch mal das VI hoch...
Beim cRio ist ja der Begriff Host etwas ungenau, bzw. ist damit zum Bsp. bei der Festlegung der DMA FIFO Richtung immer der RT gemeint.
Da hier aber von einem MMI die Rede ist, gehe ich davon aus, dass dieses doch eher auf einem PC läuft, denn für die RT Variante bliebe nur ein WebInterface.
Von daher scheint es doch eine Netzwerkverbindung zur Laufzeit des Reglers zu geben, und ich würde empfehlen, die Daten auf eine RT FIFo gebufferte SharedVariable zu schreiben. Es gibt hier auch keine Lizenzprobleme, da alle Komponenten runtimefähig sind, also keine Entwicklungslizenz benötigt wird.
Für eine Lösung ohne SharedVar Support würde ich in der zeitkritischen Schleife die Protokolldaten in einen RT FIFO schreiben und diesen in einer niedrigpriorisierten 'langsameren' Schleife auf eine Datei schreiben. Der Puffer muss nur groß genug sein, so dass keine Daten verloren gehen.
Der Begriff 'eigenes Ermessen' kommt wohl durch die Verletzung des Zyklus der TimedStructure zustande. Das kHz Timing dürfte beim Dateizugriff 'versaut' werden. Der RT verlängert dann tatsächlich eigenmächtig.
Viel vermutet aber vielleicht hilft es...
Christian
Hallo erst einmal für die schnellen und hilfreichen Antworten.
Also das Reglerprogramm läuft wie gesagt auf der RT-Ebene. Das Abbild des Frontpanels läuft zewcks Steuerung des Programms auf dem PC (das meinte ich mit MMI). Mit Host habe ich den PC gemeint, der mit einer Crosslink-Verbindung direkt an der cRIO hängt. Der wird auch immer mit der cRIO verbunden bleiben.
Das ganze VI werde ich wohl nicht hochladen können, höchstens die Teile die die Speicherung vornehmen. Dazu muss ich diese aber noch "herausskeletieren". Bisher lief dieser Bestandteil in der "Haupt-While-Schleife" des Programms. Die Sache mit dem "nach Ermessen" ist tatsächlich so. Gleichzeitig zu den Daten wird die Zeit mit gespeichert und da sieht man, dass manchmal 40ms, dann mal 63ms oder auch mal 125ms zwischen den Zeilen vergehen. Halt immer unterschiedlich.
Das Problem ist wahrscheinlich wirklich der ständig stattfindende Dateizugriff. Aber ein einziger Dateizugriff zum Start des VI hat nicht funktioniert. Die ganze Sache in eine parallel ablaufende Zeitschleife zu packen hat etwas gebracht. Aber selbst mit einer Taktung von 1ms gelangen nur ca. alle 20 ms Werte in die txt-Datei.
Mit den FIFOs habe ich mich bisher nicht auseinandergesetzt, weil die mir bisher zu kompliziert aussahen. Als Neuling wächst einem das alles schnell über den Kopf. Aus diesem Grund arbeite ich bzgl. der Kommunikation zwischen RT und FPGA auch nicht mit den FIFOs sondern mit der normalen FPGA-Target-Geschichte. Das funktioniert soweit auch alles ganz gut, d.h. die Reglung scheint zu funktionieren. Nur kann ich das nicht gut analysieren, weil die Datenspeicherung mehr als dürftig ist. Aber ich werde mal mit den RT-FIFOs herumspielen.
Ich gucke mal, dass ich die Teile gleich hochgeladen bekomme...
also hier wie versprochen die Programmfetzen, die die Datenspeicherung realisieren.
Das Programm läuft wie gesagt auf der RT-Ebene. durch den Pfad mit C:... wird die txt.Datei auf dem cRIO eigenen Speicher abgelegt. Über FTP hole ich mir die Datei dann auf den PC.
Dort wo jetzt einfach die Variablen rumliegen, finden normalerweise die Berechnungen statt und die Ein-/Ausgabe zur FPGA.
Zu Programmstart wird die Datei angelegt und ein kleiner Header angelegt. Während des Programms werden die Variablen in die Datei geschrieben.
Das Frontpanel sieht jetzt aus wie Kraut und Rüben aber darum geht es ja nicht.
Autsch, Write-To-Spreadsheet-File, und das in einer zeitkritischen Schleife...
Ist dir klar, wieviel Overhead dieses VI mit sich bringt? U.a. bei jedem Aufruf File öffnen, Schreiben, File schließen...
Schau dir mal folgendes Bsp an (nicht ganz perfekt, da das Beenden des Programms noch eine Fehlermeldung liefert, aber egal): datenspeicherung2.vi (Größe: 92,08 KB / Downloads: 390)
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Zitat:Ist dir klar, wieviel Overhead dieses VI mit sich bringt?
Natürlich nicht , sonst hätte ich das ja nicht so gemacht. Ich bin nicht nur LabVIEW-Neuling, sondern habe auch nur rudimentäres Informatikwissen...
Aber vielen lieben Dank für deine Antwort. Echt krass: Hast du diesen Programmentwurf einfach so auf die schnelle mal eben so für mich entworfen?
Ich war so frei, deine Idee mal nachzubauen. Erst einmal hatte es keine Verbwesserung gebracht. Aber nachdem ich die Inhalte beider Schleifen in die Zeitschleife gepackt habe, kommen tatsächlich jede ms neue Werte. Fehlermeldungen kommen auch keine mehr.
Wo ist denn der Unterschied zwischen dem hochgeladen VI und dem hochgeladenen VI? Mit diesen gelben Blöcken habe ich bisher auch noch nicht gearbeitet...
Wenn alles läuft wie es laufen soll, werde ich das VI mal hochladen...
' schrieb:Aber vielen lieben Dank für deine Antwort. Echt krass: Hast du diesen Programmentwurf einfach so auf die schnelle mal eben so für mich entworfen?
Na klar...
' schrieb:Ich war so frei, deine Idee mal nachzubauen. Erst einmal hatte es keine Verbwesserung gebracht. Aber nachdem ich die Inhalte beider Schleifen in die Zeitschleife gepackt habe, kommen tatsächlich jede ms neue Werte. Fehlermeldungen kommen auch keine mehr.
Eigentlich brauchst du nur für die Erfassung eine Timed-Loop, das Datenspeichern kann auch in der normalen Schleife bleiben.
' schrieb:Wo ist denn der Unterschied zwischen dem hochgeladen VI und dem hochgeladenen VI? Mit diesen gelben Blöcken habe ich bisher auch noch nicht gearbeitet...
Upps, da sollte eigentlich kein Unterschied zwischen Screenshot und VI sein... Da hat mirlv09mit seinem Snippet einen Streich gespielt...
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
, sonst hätte ich das ja nicht so gemacht. Ich bin nicht nur LabVIEW-Neuling, sondern habe auch nur rudimentäres Informatikwissen...