cRio FTP Zugriff per .Net webclient class

Es gelingt mir nicht mit der .Net webclient Klasse einen FTP Zugriff auf den RT zu realiseren.
Es ist so simpel und funktioniert mit anderen FTP Servern prima. Was ist am cRIO FTP Server anders ?
Die DownloadFile Funktion läuft immer in ein timeout.

National schreibt doch immer jeder FTP Client würde funktionieren.

code..

System.Net.WebClient
Webclient.DownloadFile(ftp_path,local_path);

wenn du mit einem vxworks controller arbeitest, koennte ich dir einen grund dafuer geben...

Hallo Thomas,
in der Tat handelt es sich bei den cRIO RT's um ein VXWorks OS. Ich würde schon gern wissen warum es nicht klappt...

Update:

Es funktioniert jetzt. Ich hab mal mit Wireshark den FTP Verkehr gesniffed und musste feststellen, dass der FTP Server durch eine offene Session eines anderen Rechners geblocked war.

--- Multiple user sessions not allowed -----

Gruß Christian

Auf das haette ich jetzt net getippt, aber top das es nun fkt!
Es gibt einen bug im tcp stack vom vxworks der ab und zu probleme macht.

' schrieb:Auf das haette ich jetzt net getippt, aber top das es nun fkt!
Es gibt einen bug im tcp stack vom vxworks der ab und zu probleme macht.

kann dieser Bug zufällig die Ursache dafür sein, dass beim Schließen der TCP/IP Verbindung von Host PC aus das Client VI (als exe Kompiliert) mit einem Windows App - Error abschmiert? Ist in meinem Fall nicht tragisch, weil die LV-Applikation dann ja schon (fast) komplett geschlossen ist, aber es sieht irgendwie so aus als würde beim Garbage Collector (oder wie auch immer der Saubermacher bei der LV-Runtime-Engine nun heist) irgendwo noch auf nen NULL-Pointer zugreifen wollen ...

' schrieb:kann dieser Bug zufällig die Ursache dafür sein, dass beim Schließen der TCP/IP Verbindung von Host PC aus das Client VI (als exe Kompiliert) mit einem Windows App - Error abschmiert? Ist in meinem Fall nicht tragisch, weil die LV-Applikation dann ja schon (fast) komplett geschlossen ist, aber es sieht irgendwie so aus als würde beim Garbage Collector (oder wie auch immer der Saubermacher bei der LV-Runtime-Engine nun heist) irgendwo noch auf nen NULL-Pointer zugreifen wollen ...

Ist es eine grosse App? Hast Du da noch externen Code drin der so nette Dinge wie MFC, Visual C++ etc verlangt? Dann könnte es eher damit zu tun haben dass der LabVIEW EXE Stub explizit versucht um die lvrt.dll beim Abschliessen aus dem Speicher zu laden. Das ist gemäss MSDN ein nobles Unterfangen wenn das geschieht wenn die aufrufende DLL normal aus dem Speicher entfernt wird etwa durch ein FreeLibrary Aufruf aber etwas zu nobel gedacht wenn das am Ende der Prozesslebensdauer geschieht. Bei FreeLibrary Aufrufe während der Terminierung eines Prozesses können Racekonditionen entstehen und es wird deshalb abgeraten von DLLMain Funktionen wiederum FreeLibrary Aufrufe zu machen wenn der entsprechende eigentlich undokumentierte Parameter angibt dass der Prozess beendet wird.

lvrt.dll seit etwa 8.0 macht das aber wobei das normalerweise keine Problem verursacht, ausser wenn Du grosse C++ DLLs aufrufst die selber Unmengen an Objekten und Speicher deallozieren wollen am Ende und deshalb die Prozessterminierung sehr lange herausgezögert wird.

Rolf Kalbermatter

Anzeige

' schrieb:Ist es eine grosse App?

ja, bei allen großen Applikationen tritt das Problem auf. Ich hab nun schon ganz explizit "Shutdown-Routinen" eingeführt, die nach und nach und mit kleinen Wartezeigen alle Treiber (VISA, DAQmx, etc) "runterfahren" und wenn ich das mitlogge gibts auch kein Problem bis zu dem Moment wo das FP vom Main-VI per Property Node geschlossen wird - das ist definitiv die letzte Anweisung im Programm, das Fenster geht auch zu und Zack - hab ich die Windows Fehlermeldung

Ich tippe auch auf eine Race Condition beim Deallocieren, wenn ich nur mal wüsste welche DLL das ist ... ich hatte ja schonmal auf VISA getippt, als du geschrieben hattest dass die intern wiederum asynchron arbeitet , ich kann das Problem auch kaschieren in dem ich Wartezeiten einbaue, wirklich weg ist es aber nicht ...

ach ja, ActiveX (Stichwort: ADO-Tool), .Net aufrufe, DLL-Aufrufe (von Praktikanten geschrieben und gehn sogar), is alles drin, in wilden Konstellationen;)und eine dieser Anwendungen ist das Paradebeispiel dafür dass man mit einer vernünftigen Architektur immer und immer und immer und (...) wieder erweitern kann, weil man dies noch braucht und jenes noch schön wäre ...

edit: das tritt übrigens erst mit 8.5.1 auf unter 8.2.1 hatte ich damit keine Probleme. Mal schaun wie's unter 8.6.1 läuft

Grüße
CB