# [?] Port 102 - durchpusten



## Kurt (23 Februar 2015)

Hallo, vielleicht hat Jemand einen Tip.

Es geht um eine Testumgebung - Alles auf einem Rechner.
Win 8.1 mit Step7 V5.5 SP 4 und PlcSim ( JA - egal, es ist oben und es läuft und für Tests stabil genug)
NetToPlcsim
C# Prog mit Snap7.
Firewall ist OFF
Laut nettoplcsim = der Port102 OK

Das Ganze läuft und kommuniziert, wenn die "SPS" auf einem XP oder W7 Rechner ist.

Wenn die "SPS" auf dem W8.1 Rechner ist, kann ich die SPS Pingen, ein Connect mit/über Snap7 ist nicht möglich.
Laut Wireshark hängt es am Port 102.

Wählt man im nettoplcsim\Tools\StartIEPGhelper -> kommt eine Meldung dass der zugehörige Dienst nicht gestartet werden kann.
Somit hat auch die Original DLL ein Port 102 Problem.

Hat jemand eine Idee wie man den Port102 "durchpusten" kann?
oder wie ich sinnvoll weiter forschen kann?

Ich möchte nicht den Rechner auf Win7 umbauen.

useful help welcome
kurt


----------



## Thomas_v2.1 (23 Februar 2015)

Unter Windows 7 musste Nettoplcsim mit Administratorrechten gestartet werden, damit der Dienst beendet werden kann. Du musst ihn auch beenden (stop) und nicht starten.
Vlt. heißt der Dienst auch mittlerweile anders, da wurde kürzlich von Siemens dran rumgefummelt.

Um herauszufinden wer den Port belegt, machst du unter einer Eingabeaufforderung folgendes:
netstat -ao | find "102"

Die Zahl ganz rechts ist die Prozess-id. Wie das Programm heißt findest du mit
tasklist | find "die prozess id"

heraus.
Diesen kannst du dann hoffentlich mit net stop und dem Namen beenden.


----------



## Kurt (24 Februar 2015)

_-> habe bei dieser Wunderforumssoftware gerade wieder mal den Text verloren, somit Kurzfeedback.
_
Danke für den Tip!

Ergebnis:
netstat liefert bei 102 nur einen Zeilenvorschub.
wird nettoplcsim gestartet,
netstat liefert bei 102 einen Eintrag - es ist nettoplcsim, listen

-> ich forsche noch etwas...


----------



## ChristophD (24 Februar 2015)

Windows 8.1 64bit oder 32bit?
mal bei den Diensten schauen ob der "SIMATIC S7DOS Help Service" läuft (Das ist der neue Name für den Dienst  )


----------



## Kurt (24 Februar 2015)

Danke Christoph: 64Bit - es ist nicht der HilfeService o7oiehsx64 - der Port ist frei.
----------
Die Kommunikation mit einem Probierprogramm Client/Server funktioniert über Port 102.
Das Probierprogramm verwendet einen TcpListener..

-> nach 3 x korrigieren und viel forschen:
Es muss ein Kompatibilitäsproblem auf der Clientseite sein.
wenn ich mit dem ProbierClient auf NetToPlcSim verbinde, und etwas sende, wird die OnReceiveData in NetToPlcSim getriggert.

Ich schaffe sowohl mit snap7 als auch mit den JFK Toolbox Elementen keine Verbindung.
Socketfehler 10061 (du bist da, aber redest nix mit mir)
OnReceiveData triggert nicht
Wireshark errötet wenn ein Zugriff auf Port 102 kommt.

Kurt
_ich werde das lassen._


----------



## Kurt (24 Februar 2015)

Das Ergebnis:

zum Test verwende ich nun S7.Net+ von Github, da es dabei um eine schlanke für mich überschaubare Lösung handelt.

Es wird darin die Klasse System.Net.Sockets.Socket verwendet.
Diese liefert beim Connect ebenso einen 10061 Fehler wie Snap7 und JFK Libno .

Dies kann mit einer Holzhammermethode behoben werden.

es wird ein TcpClient mit dem Endpoint SPS_IP und Port 102 erstellt und connected.
client = new TcpClient();
client.Connect(serverendpoint);
das klappt

Die alte Socketvariable _mSocket wird danach mit TcpClient.Client zugewiesen
_mSocket = client.Client;
der Rest des Progs bleibt (bis auf das abmelden/zerlegen bei ProgEnd)

Wo ist der Unterschied?
Im Debugger -variablenview-  lässt sich kein Unterschied sehen.

aber es funktioniert somit die Kommunikation zu NetToPlcSim, 
im Wireshark sieht es gut aus und im Monitor von N2PSim ebenso.

jetzt werde ich noch ein wenig "rumprobieren".
Aber befriedigend ist das nicht und Lösung auch keine.

Kurt

Ende:
es funktioniert nach Grobtest anscheinend.
Zumindest der Datenaustausch im Merkerbereich.
Bei DB kommt für alle Elemente 0 (Wert) zurück - entweder mache ich was falsch oder die Soft hat ein Loch. Will ich jedoch nicht erforschen.
Rausfliegen tut er nirgends und auf der S7online Seite sind Bytes belegt ebenso auf der Client Seite (receivepuffer).
Die Kommunikation funktioniert sowohl lokal (alle progs isoliert auf einem Rechner im selben OS Win8.1/64) als auch wenn der Client über das Netz zugreift.

_etwas ratlos wie es weitergeht - werde das jedoch mal beenden und der Arbeit mit mehr Wirkleistung zuwenden._


----------



## Thomas_v2.1 (24 Februar 2015)

Ich fasse mal zusammen was ich aus deiner Beschreibung entnehme:

1) Du hast mit Nettoplcsim keine Probleme unter Windows XP oder Windows 7
2) Du hast keine Probleme dich mit Snap7 zur Nettoplcsim aus 1) zu verbinden
3) Nettoplcsim funktioniert unter Windows 8 nicht korrekt

Dann muss also irgendwas unter Windows 8 anders sein. Ich habe kein Windows 8, und soweit ich weiß ist Step7 auch nicht dafür freigegeben. netstat zeigt laut deinen Angaben zumindest an dass der TCP-Server von Nettoplcsim läuft. Dann kann es nur an der S7online-Schnittstelle liegen. Die ist seit dem Siemens SP4? unter 64 Bit nicht mehr stabil verwendbar, ich habe noch nicht rausgefunden was dort intern geändert wurde. Mal abgesehen davon, dass ich die Schnittstelle wohl noch nie 100% korrekt bedient habe, weil alle Funktionen die von der SPS initiierte Telegramme verwenden noch nie funktioniert haben. Es gibt leider keine offizielle Doku zu der Schnittstelle.

Die offizielle Schnittstelle zu Plcsim (S7ProSim) ist nur sehr eingeschränkt von der Funktion und auch schneckenlangsam. Kannst ja einfach mal testen ob diese unter Win8 noch funktioniert. Bei sourceforge kannst du dir auch die alte 0.7.2 herunterladen welche diese Schnittstelle verwendet.


----------



## Kurt (25 Februar 2015)

Hallo Thomas,

ok - da habe ich wohl zu verdreht geschrieben.

Es gibt *kein *Problem mit NetToPlcSim.
Es ist ein Problem im Client beim Connect (egal was im Host als Ziel angesprochen wird)
Für meine Versuche habe ich nur die Clientseite verändert.

Das Problem entsteht
wenn der Client ein Socket.connect verwendet und der Host/Server/Zielrechner ein Win8.1 (64) besitzt.
_es entsteht auch wenn man am Server einen Echoserver laufen lässt oder sonst was.
wenn die ClientSoft mit der Klasse Socket einen connect versucht wird diese vom OS nicht reingelassen. (man kommt also garnicht bis zum Ziel)_

Gelöst werden kann das:
wenn der Client (anstelle von Socket) die Klasse TcpClient für den Connect verwendet.

Das Problem entsteht, wenn bei mir nicht eine Sondersituation vorliegt, mit allen Clients die Socket verwenden und auf einen Win8.1 Rechner zugreifen wollen.


----------



## Jochen Kühner (25 Februar 2015)

Versuch mal den FullMangedConnect von meiner Connection Library, da wird glaub auch ein TcpClient verwendet!


----------



## Kurt (25 Februar 2015)

Hallo Jochen,

wäre zwar interessant, aber...
... meine mühsam aufgebaute Testumgebung hat der Partitionierer vernichtet.
Habe (bin dabei) die Kiste auf Win7 umgebaut und somit keinen Win8.x Rechner mehr zur Verfügung.

kurt


----------



## Kurt (26 Februar 2015)

Ergebnis:
ist fast etwas peinlich, möchte die Sache jedoch nicht offen hängen lassen.

a) Umrüstung des Rechners auf Win7/64.
b) Herstellung der Programmumgebung.
c) Test -> Ergebnis wie unter Win8.1/64
d) ...
e) Analyse
c) Ergebnis:

Host/Server und Konfig im N2PlcSim:
Networkadress: 192.168.1.10
PLC address:     192.168.1.20
_Clientadress: 192.168.1.199
_
Verbindung mit dem Clientprogramm (egal ob extern auf .199 oder lokal am .10):

Connect mit 192.168.1.10
-> es funktioniert die Verbindung mit der Klasse Socket.
-> es funktioniert die Verbindung mit der Klasse TcpClient.

Connect mit 192.168.1.20 (der falschen Adresse)
-> die Verbindung mit der Klasse Socket funktioniert nicht.
-> es funktioniert die Verbindung mit der Klasse TcpClient.

Ende
Kurt
_Das Problem sitzt vor dem Rechner_


----------

