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!
ich hab folgendes problem bzw. frage und hoffe jemand von euch kann mir helfen.
also ich lese ein Datenfile (*.txt file) im RT ein. Bislang übertrage ich das File im MAX mit hilfe
des Dateitransfers an das cRIO system.
Auch bin ich bis jetzt immer so vorgegangen, dass ich eine Kopie dieses Files auf meinem Desktop Rechner unter c:file.txt
ablege.
Nun greift mein LV Code (RT) auf dieses File zu... dies klappt auch soweit, aber:
1. Ich weis nicht genau von woher das RT System sich dieses File holt....?!?!
2. Es scheint so, als ob es auf das Desktop file zugreift, weil zum einen die LAN Verbindungs LED wild blinkt
und zum anderen ich auch im Dateidialog c:file.txt bis dato angebe.
Ist es auch möglich, auf das zuvor schon übertrabene, auf dem cRIO System befindliche File direkt zuzugreifen (programatisch)?
Wenn ja wie geht das?
PS: Die vorherige übertragung im MAX ans RT hab ich bislang aus dem grund durchgeführt, weil ansonsten ein fehler im LV auftaucht...
Ich hab mal einen Screenshot für einen automatischen FTP Transfer zum RT hochgeladen. Das Zielverzeichnis (RT) muss vorher angelegt werden. Das Quellverzeichnis ist hier relativ zur SharedVar root.
Für den Zugriff ist der gleiche String zu benutzen. Allerdings muss er mit String2Path konvertiert werden.
Also wenn ich das richtig verstehe, ruft NoD den Dateidialog von einem Frontpanel eines VIs auf dem cRIO auf und nicht von einem HostVI auf dem ClientPC. Dabei zeigt der Dateidialog trotz allem den Arbeitsplatz des ClientPCs, mit dem er auf das cRIO zugreift.
Der cRIO selbst verwendet für seinen lokalen nichtflüchtigen Speicher ebenfalls die Bezeichnung "c:". Das cRIO kann ohne weiteres garnicht auf den ClientPC zugreifen, um ein File auszulesen. Wenn das cRIO nun im Verzeichnis "c:datei.txt" ein entsprechendes file hat, weil es voher dort abgespeichert wurde und dann via Dateidialog im Frontpanel "zufällig" ebenfalls der Dateipfad "C:datei.txt" (auf dem PC) angegeben wurde. Dann findet das cRIO logischerweise auch auf seinem Laufwerk "c:" dieses File und kann es im folgenden auslesen.
Also... :
zu 1) Das RT System ließt das File von seinem eigenen Laufwerk "c:" aus.
zu 2) Was da blinkt ist unter anderem die Frontpanelverbindung mit dem ClientPC. Immerhin ist da noch mehr unterwegs als nur das Textfile.
"Auf das zuvor schon übertrabene, auf dem cRIO System befindliche File" greifst du schon zu, NoD. Du musst nur wissen, dass der Dateidialog in dem Fall einfach nicht wie erwartet funktioniert. Die Pfade zu Files auf dem RT kannst du dir selbst zusammenbasteln, wenn du weißt wo die Datei liegt und, dass das RT System sein Hauptverzeichnis als "c:" bezeichnet.
Legst du zum Beispiel auf dem cRIO auf höchster Ebene einen Ordner mit dem Namen "datenkammer" an und plazierst dort ein file mit dem Namen "datei.txt", dann kannst du programmatisch auf das File über den Pfad "c:/datenkammer/datei.txt" zugreifen.
danke an euch. Ja die letzte antwort scheint korrekt zu sein. das crio holt sich das file aus seinem eigenen speicher und nicht von der pc-festplatte.
auch das mit dem dateipath c:... ist der vom crio. ....ein wenig verwirrend das ganze....
was mache ich falsch, wenn ich bei Ausführung dieses VI vom cRIO 9022 aus, ständig den Fehler 43 (mit und ohne Startpfadangabe) bekomme?
Als ich die Funktion vom Hostrechner aus ausgeführt habe, gab es keine Probleme.
Ich benutze LV 2011 SP1, das Projekt ist ein Scan-Engine-Projekt und was ich ansonsten noch ansgeben muss, weiß ich nicht.
Ah, das ist schon Mal ein guter Hinweis!
Da war wohl das Denken, dass wenn die GUI vom Rechner aus gestartet wird, die VIs aber auf dem cRIO sind, der Dialog auch vom Rechner aus gestartet wird, zu groß.
gut, also habe ich es einmal so wie unten zu sehen programmiert. Mit dem Ergebnis, dass ich den Fehler 1430 bekam.
Daraufhin habe ich mich ein wenig schlau gemacht und bin darauf gekommen, dass die Pfadangaben auf dem cRIO-System nicht wie oben beschrieben "c:\" usw. sind (Backslash), sondern wie in Labviewforum-Thread so: /c/Protokolle/... (Slash)
Hm, wenn ich das was Du empflielst, anwenden würde, würde ich einen Pfad wie /c/Protokolle/\protokoll_120511_143810.txt bekommen - da bleib ich lieber bei der String-Variante, glaub ich.
Zitat:würde ich einen Pfad wie /c/Protokolle/\protokoll_120511_143810.txt bekommen
Das glaube ich nicht. Die Pfad-Funktionen sind plattformspezifisch und verwenden jeweils die Trennzeichen, wie sie die Plattform verwendet/erwartet. String-Funktionen führen da schneller zu Fehlern, wie du gemerkt hast...