INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

cRio FTP Zugriff per .Net webclient class



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!

19.06.2009, 17:13
Beitrag #1

dlambert Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 89
Registriert seit: May 2009

2010
2007
en

12359
Deutschland
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);
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
19.06.2009, 18:26
Beitrag #2

thomas.sandrisser Offline
LVF-SeniorMod


Beiträge: 1.298
Registriert seit: Sep 2005

xxxx
2005
EN

78759
United States
cRio FTP Zugriff per .Net webclient class
wenn du mit einem vxworks controller arbeitest, koennte ich dir einen grund dafuer geben...
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.06.2009, 07:03 (Dieser Beitrag wurde zuletzt bearbeitet: 22.06.2009 08:25 von dlambert.)
Beitrag #3

dlambert Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 89
Registriert seit: May 2009

2010
2007
en

12359
Deutschland
cRio FTP Zugriff per .Net webclient class
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.06.2009, 18:44 (Dieser Beitrag wurde zuletzt bearbeitet: 22.06.2009 18:44 von thomas.sandrisser.)
Beitrag #4

thomas.sandrisser Offline
LVF-SeniorMod


Beiträge: 1.298
Registriert seit: Sep 2005

xxxx
2005
EN

78759
United States
cRio FTP Zugriff per .Net webclient class
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.
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.06.2009, 19:01
Beitrag #5

cb Offline
LVF-SeniorMod


Beiträge: 1.731
Registriert seit: Feb 2006

2018SP1
2001
EN

40xxx
Deutschland
cRio FTP Zugriff per .Net webclient class
' 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 ...

http://www.rotabench.com - rotierende Prüfstände nach dem Baukasten-Prinzip
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.06.2009, 20:44 (Dieser Beitrag wurde zuletzt bearbeitet: 22.06.2009 20:45 von rolfk.)
Beitrag #6

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
cRio FTP Zugriff per .Net webclient class
' 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

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
23.06.2009, 20:54 (Dieser Beitrag wurde zuletzt bearbeitet: 23.06.2009 21:35 von cb.)
Beitrag #7

cb Offline
LVF-SeniorMod


Beiträge: 1.731
Registriert seit: Feb 2006

2018SP1
2001
EN

40xxx
Deutschland
cRio FTP Zugriff per .Net webclient class
' 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 sogarWink), 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

http://www.rotabench.com - rotierende Prüfstände nach dem Baukasten-Prinzip
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Gehe zu: