Guten Morgen
Vielleicht habe ich Glück und jemand kennt sich mit dem Problem aus.
Ich habe eine TCPIP Verbindung zu einer Ethernetkarte die wir produzieren.
Mein testtool funktioniert unter Windows XP aber unter Windows 7 Kann ich noch nicht mal die TCPIP Verbindung öffnen.
Ich lege ein Bild bei.
Vielen Dank für euere Hilfe im voraus.
(09.06.2011 07:53 )xtro schrieb: [ -> ]Guten Morgen
Vielleicht habe ich Glück und jemand kennt sich mit dem Problem aus.
Ich habe eine TCPIP Verbindung zu einer Ethernetkarte die wir produzieren.
Mein testtool funktioniert unter Windows XP aber unter Windows 7 Kann ich noch nicht mal die TCPIP Verbindung öffnen.
Ich lege ein Bild bei.
Vielen Dank für euere Hilfe im voraus.
Standardfrage: Schon mal ein Ping von diesem Computer zu dieser Adresse probiert???
Ja ping klappt.
Ein Agilent Messmittel kann ich auch ansteuern. Scheinbar liegt es dann an der Karte. Trotzdem komischer Fehler. Weil es ja bei Windows XP ohne Probleme läuft.
Error 56 deutet auf einen timeout hin, oder?
Schon mal probiert die Gerät eine andere IP-Adresse zuzuweisen, bzw. hatte das Agilent Gerät die gleiche IP-Adresse?
Edit meint:
Überprüfe mal ob du diesen Port vlt entweder auf einen anderen Port umleitest oder die Firewall selbigen blockierst... Wenn das nicht der Fall ist, lässt sich eventuell der Port umstellen?
Schon mal Win7 Firewall und/oder Win7 Defender deaktiviert? Oder was sonst so an Sicherheitssoftware reinspucken könnte?
Gruß, Jens
Schließe mich da gleich mal an.
Habe eine Anwendung, in der ich über Modbus-TCP (mit den Modbus-Libs von NI) mit einem WAGO-Koppler kommuniziere.
Unter XP habe ich diese Art der Kommunikation schon X-fach gemacht, ohne Probleme.
Sobald ich auf dem Win7-System bin, bekomme ich ständig die 56-Timeouts. Wobei ich (subjektiv) die Erfahrung gemacht habe, dass es kurzfristig funktioniert, wenn ich die Anwendung "als Administrator" starte, andernfalls bekomme ich gleich beim Start einen Timeout-Error.
Auf das Web-Interface vom WAGO-Koppler komme ich mit dem IE ganz normal, auch die WAGO-SW (BootP Server für die IP-Vergabe) hat Verbindung, nur über LabVIEW gehts nicht.
Firewall und Defender sind deaktiviert über die Services, keine Besserung.
Hatte das Problem schon einmal, damals haben wir aus Zeitgründen einfach einen Workaround genommen und ein virtuelles XP aus Win7 gestartet und dann hats funktioniert und die Anwendung läuft heute noch ohne Probleme. Im jetzigen Fall würde ich dann doch gerne eine Lösung in Win7 haben
LV-Version ist im übrigen 2009 SP1 bzw. die Runtime davon.
Weitere Anregungen gern gesehen und danke im voraus.
Also ich kenne mich mit Win7 auch ganz und gar nicht aus, aber ich schieß einfach mal ins Blaue wenns recht is...
ein ganz andres Problem hatte ich auch mal, die Lösung davon ist aber unter Umständen übertragbar.
Ich wollte meine Messwerte in eine Datei schreiben, schlicht und einfach C:\"Datei". Eine Fehlermeldung(von Windows und nicht LabVIEW) verriet mir dann, dass ich dazu nicht die Berechtigung habe und nachdem ich dann den Pfad in C:\Users\Ich(ihr wisst was ich meine, also der Benutzerordner) oder so ähnlich geändert hatte gings einwand frei.
Mein Ansatz: Kopier doch mal dein VI in oben genannten Benutzerordner, also Eigene Dateien oder so.
Vieeeeleeeeeeeeeeeeeicht gehts ja
Hallo,
ich würde versuchen die IP Adresse Deines Zielgerätes zu ändern. Eine Null in der Adresse wird normalerweise vermieden, da damit Broadcasts adressiert werden.
Gruß Marco
(13.07.2011 07:31 )mheintz schrieb: [ -> ]Hallo,
ich würde versuchen die IP Adresse Deines Zielgerätes zu ändern. Eine Null in der Adresse wird normalerweise vermieden, da damit Broadcasts adressiert werden.
Gruß Marco
Reden wir hier vor der der Null in 99.
0.7.139?
Diese Null hat nichts mit Broadcast zu tun. Als Broadcastadresse dient die letzte Adresse in einem Netzsegment und dieses ist abhängig von der Subnetmask.
zB. Wenn die Subnetmask 255.255.255.0 bei der o.g. IP ist, also 24 Bit hat,
dann ist die Adresse 99.0.7.0 die Netzadresse und die 99.0.7.255 die Broadcastadresse...
Gruß Achim
Das Problem besteht weiterhin.
Jeodch hat irgendwas der lokale Port im TCP/IP open.vi damit zu tun.
Laut Beschreibung heißt es das wenn der lokale Port mit 0 initialisiert wird dann wird ein feeier port vom System (Windows 7) genommen.
Genau das scheint nicht zu klappen. Gibt man irgendeinen Port an klappt es ab und an aber man weiß ja halt nicht welcher lokaler Port frei ist.