LabVIEWForum.de - cRIO-9072 - Linearmotorsteuerung - Kommunikationsprobleme

LabVIEWForum.de

Normale Version: cRIO-9072 - Linearmotorsteuerung - Kommunikationsprobleme
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Hallo allerseits,
ich arbeite derzeit an einem kleinen Projekt zur Steuerung eines Linearmotors (Tauchspulenmotor). (Diplomarbeit)

Als Echtzeitsystem kommt ein cRIO-9072 zum Einsatz, das via direkter LAN-Verbindung an einem Laptop hängt. (100Mbit)

Bei der Programmierung verwende ich FPGA-, RT- und PC-Target.

...auf dem FPGA werden 3 I/Os angebunden. Es befindet sich ein PID-Regler zur Positionsregelung auf dem Target und es findet zur späteren Auswertung der Ergebnisse eine live-Ableitung a la [x(i)-x(i-1)]/dt mittels feedbacknode statt, um aus einem gemessenen Positionssignal so gut es geht Geschwindigkeit und Beschleunigung zu ermitteln.

...das PC-Target soll hauptsächlich zu Steuerungszwecken dienen. Es ist möglich Wegvorgaben zu machen, Parameter festzulegen, die für die Regelung nötig sind und Prozesse zu starten und stoppen.

...das RT-Target hat 2 Hauptfunktionen. Zum einen dient es derzeit zur Kommunikation zwischen FPGA und PC target, um Parameter vom PC zum FPGA durchzureichen und andersherum um Messwerte vom FPGA zum PC durchzureichen. Zum anderen berechnet es zu jedem Zeitpunkt geforderte Sollpositionen der Wegvorgabe und gibt diese an das FPGA target.


Soweit zum Aufbau. Nun bleiben noch 2 Problemchen:
1) Laut allem was ich bisher von offizieller Seite rausbekommen habe dürften zur Kommunikation zwischen RT und PC network published shareVariablen das geeignete Mittel zu sein. Das ergab bei ersten Versuchen ca. 15 shared Variables die es von der Shared Variable Engine zu verbreiten galt. Grundsätzlich habe ich dieses System zwar zum laufen gebracht aber viele der Variablen wurden erst mit extremer Verzögerungen einiger Sekunden aktualisiert. Das ist absolut inakzeptabel. Bündelung einiger Cluster zum Zweck die Anzahl der Variablen zu reduzieren brachte etwas abhilfe. Dabei war es egal ob ich die SVE auf dem RT target oder dem PC hab laufen lassen.

2) Datenaufzeichnung. Ich kann, wie gesagt auf dem Frontpanel Verfahrwege einstellen und dann vom RT target entsprechend eine Sollwertvorgabe (Sinusfahrt/Rampenfahrten) produzieren lassen. Während ich verfahre will ich Zeitpunkt, Soll/Istposition, Soll/Istgeschwindigkeit, Beschleunigung und Regelabweichung mitloggen. Mein Plan bestand uhrsprünglich darin, die Kommunikation zwischen RT target und PC einigermaßen zu synchronisieren und dann auf dem PC einfach das ganze zeilenweise alle 20msec-50msec in ein einfaches csv file (genauer gesagt tsv) zu speichern. Ist es vielleicht einfacher auf dem RT target die Daten zu loggen und später manuell via ftp "abzuholen"?


Ich schlag mich jetzt schon wochenlang mit diesen Problemen rum und mittlerweile muss ich Ergebnisse liefern können. Immerhin geht das alles von der Zeit ab die ich für die Doku brauche. Tag für Tag häng ich stundenlang über der software um einen flüssigen datenfluss zu erreichen. Bisher ohne großen Erfolg.

Ich bin um jeden Tipp und jede Anregung dankbar, die mich hier einen Schritt weiterbringt.
Das ist erst mein 2tes größeres LabVIEW-Projekt.


Dank im vorraus, ich hoffe der lange Text hat niemanden abgeschreckt.

(P.S. Angaben zur LabVIEWVersion editiere ich grade in meinem Profil, kann nur Minuten dauern bis die Infos links auftauchen)
Tip1 SVE auf den PC:
Der 9072 hat nur einen kleinen Prozessor und ich würde aus der Erfahrung heraus die SVE immer auf den viel performanteren PC bringen. Den 9072 würde ich auf die absolut notwendige Software abspecken. Das ist die vom MAX angebotene minimal Konfig + Variable Client Support + System State Publisher + (vermutl. PID ControlKit ).
Im alias File des RT (/startup) muss dann Deine IP ( also die der SVE ) stehen.
-> Die langen Aktualisierungszeiten habe ich nur bei SVE auf cRIO gesehen und ich vermute das bei Deinen Tests im alias File immer noch die cRIO SVE referenziert wurde ! <-


Tip2 Kommunikationsstruktur / Logger
- implementiere einen Target2Host FIFO schreib immer Zeitstempel ( loop_count * cycle time) und dazu alle Werte ( z.Bsp 5 ) hintereinander in den FIFO
- der RT muss die Daten nicht auswerten, also schreib Sie einfach auf eine shared Var ( z.Bsp number of elements 5, number of arrays 1024, use buffering, RT FIFO enabled )
- der PC liest die sharedVar und dekodiert und schreibt ein LogFile

Hope it helps !

Christian
Hallo Mr. B,

also wenn du anständige Datenraten zusammenbekommen möchtest würde ich dir raten die TCP/IP Kommunikation selbst auszuprogrammieren. Dann sind Datenraten im bereich 20 - 50 msec sicher möglich.

Wenn sehr viele Daten innerhalb kurzer Zeit anfallen ist ein FIFO für den Datentransfer sicher eine gute Idee.

Das Logging würde ich ebenfalls direkt auf dem RIO machen und mir die Daten an via FTP holen.

Wenn du mit großen Datemengen auf einem RIO arbeitest solltest du ausserdem extrem auf Speicherperformante programmierung achten.

lg Christian
Da fährt man extra morgens zur Fachhochschule, um dort effektiv den Tag durcharbeiten zu können und dann fällt einfach mal um 10:00 das Internet aus und bleibt aus... naja home sweet home.... traue keiner hardware, die du nicht selbst administrieren kannst...
daher jetzt erst wieder hier.

Vielen Dank, Christian & Christian.

Dem Hinweis zum aliasfile werde ich auf jedenfall mal nachgehen. Ich habe bisher nur recht naiv die Lib der Shared Variablen im Project Explorer zwischen den Target hin- und hergeschoben. Abspecken könnte das Software Paket auf meinem RT wahrscheinlich auch ein wenig.
Als Zeitstempel verwende ich sicherheitshalber lieber die absolute Zeit nach dem Schema "H:MConfused,xx"

Zum schnellen lokalen Datenloggen auf dem RT hab ich gestern abend hier im Forum noch ein beispiel mit dem "Write to Binary" Block gefunden. Hab die Idee mal auf meine Software angepasst. Erste Versuche mit 50ms Logging-Rate waren kein Problem, auch wenn es natürlich nicht so schnell geht wie auf nem normalen PC. Der Zugriff auf die Daten via FTP dürften kein Problem sein, immerhin kann man sie dort recht gut archivieren solang der Speicher reicht (muss noch ausrechnen, wielang ich insgesamt aufzeichnen kann, aber da die tests wahrscheinlich eher im Bereich weniger Sekunden sind werden eine ganze menge aufzeichnungen platz finden).

...dann mach ich mich mal wieder an die Arbeit
Das Logging in Echtzeit endet am RT.
Ich würde mich nicht mit dem Versuch quälen ein stablies 20ms Logging übers Netzwerk hinzubekommen.
Wenn die Daten einen Zeitstempel des RT oder des FPGA haben kannst Du in aller Ruhe und völlig asynchron die Daten übers Netz schieben.

Damit erreichst Du eine zeitliche Auflösung für's Logging bis in den µsec (FPGA cycle) Bereich und bist unabhängig von der Netzwerkperformance.

Das soll keine Kritik sondern nur ein Hinweis sein.
Danke.
Wie oben bereits angedeutet, logge ich nun in ein file auf dem cRIO.
Ich öffne ein file. In einem timed loop packe ich dann Zeitstempel und Messwerte zusammen in einen string und schreibe sie binär in das file. Ist der schreibvorgang abgeschlossen, so schließe ich das file. Die Dateien tragen den Startzeitpunkt der Messung sekundengenau im Dateinamen. Damit werden Messergebnisse automatisch zentral auf dem cRIO archiviert.
Ist die Messung abgeschlossen und gespeichert, kann die Datei zur graphischen Auswertung optional in das Programm geladen und angezeigt werden.
Referenz-URLs