# Kommunikation S7<--> PC über Ethernet mit Send/Receive



## MW (25 Juni 2007)

Es gibt zwar schon ziemlich viele beiträge zu diesem Themenbereich, nur leider beantwortet keiner meine fragen

Ich möchte eine Kommunikation zwischen einem "standart" PC und einer S7(mit ethernet-CP) aufbauen und dies ohne verwendung von Siemens Software. Dabei soll die S7 die daten über eine projektierte ISO on TCP Verbindung senden bzw. empfangen. 
Auf der SPS Seite kein Prob., nur wie realisiere ich den PC Teil ??????

Soweit ich weis geht dies Mit den Windows Sockets.
Also connect aufrufen 
(mit den Parametern Remote IP und Remote port (=102))
und dann warten bis die SPS was sendet.
Nur die Sps sagt das die verbindung nicht aufgebaut ist. ????????


Hat jemand eine idee was ich falsch mach bzw. wie es richtig gemacht wird ????? 

Software: MS Visual Basic 2005


PS: mit Libnodave funktioniert es bestens, nur diesen Verkehr kann man ja von der SPS seite kaum(garnicht) beeinflussen. Deshalb wollte ich es auf diesem wege versuchen -- ich weiss, dass es funktioniert.


----------



## Ralle (25 Juni 2007)

Vielleicht hilft dir das etwas weiter:
http://support.automation.siemens.com/WW/skm/frameset.asp?url=%2FWW%2Fllisapi%2Edll%2F1853547%3Ffunc%3Dll%26objId%3D1853547%26objaction%3Dcsopen%26siteid%3Dcseus%26skm%3D1%26lang%3Dde&Query=2+CPU+vernetzen&SearchArea=alle&id=1853547&F11Marker=true&siteid=cseus&query2=&modelled=&lang=de

 Beitrags-ID: 1853547

Irgendwie bekomm ich das mit diesen besch... Siemens-Links nicht richtig hin :twisted:!


----------



## MW (26 Juni 2007)

Ja das hatte ich auch schon mal gelesen, da gehts aber hauptsächlich um Fetch/Write und das leider nur auf der S7 Seite. mein Problem is aber hauptsächlich die PC seite.
Oder gibts da hilfreiche zusammenhänge zwischen Fetch/Write und Send/Receive ???


----------



## afk (26 Juni 2007)

MW schrieb:


> Soweit ich weis geht dies Mit den Windows Sockets.
> Also connect aufrufen
> (mit den Parametern Remote IP und Remote port (=102))
> und dann warten bis die SPS was sendet.
> Nur die Sps sagt das die verbindung nicht aufgebaut ist. ????????


Wenn Du den Port 102 verwendest, dann mußt Du AFAIK das S7-Protokoll verwenden (wie libnodave), hast dann aber auch nicht mehr Einfluß auf die Kommunikation als mit libnodave.

Wenn Du mit Send/Receive auf der SPS arbeiten möchtest, dann mußt Du in Deinem SPS-Projekt dafür ja einen anderen Port definieren, da der Port 102 ja schon vom BS der SPS verwendet wird. Vom PC aus mußt Du dann diesen Port statt Port 102 ansprechen, damit sollte das funktionieren.


Gruß Axel


----------



## marcengbarth (26 Juni 2007)

Hallo!

Ich hänge mich hier mal ganz frech an....

Bin grad an dem gleichen Vorhaben... Ich bekomm aber keine Verbindung zur SPS (Socketfehler 10053 / 10061). Programmiersprach Delphi 7 Enterprise über TClientSocket...

Weiß jemand an was das liegt?


Gruß
  Marc


----------



## afk (26 Juni 2007)

marcengbarth schrieb:


> Ich bekomm aber keine Verbindung zur SPS (Socketfehler 10053 / 10061).



10053 (WSAECONNABORTED)	Eine bestehende Verbindung wurde softwaregesteuert durch den Hostcomputer abgebrochen

10061 (WSAECONNREFUSED)	Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte

Scheint so, als ob die SPS mit Deinem PC ganz einfach nicht reden will ...  


Gruß Axel


----------



## marcengbarth (26 Juni 2007)

Ja, ist echt seltsam... Muss da noch weiterprobieren, wenn's geklappt hat meld ich mich wieder...


----------



## MW (26 Juni 2007)

afk schrieb:


> Wenn Du den Port 102 verwendest, dann mußt Du AFAIK das S7-Protokoll verwenden (wie libnodave), hast dann aber auch nicht mehr Einfluß auf die Kommunikation als mit libnodave.
> 
> Wenn Du mit Send/Receive auf der SPS arbeiten möchtest, dann mußt Du in Deinem SPS-Projekt dafür ja einen anderen Port definieren, da der Port 102 ja schon vom BS der SPS verwendet wird. Vom PC aus mußt Du dann diesen Port statt Port 102 ansprechen, damit sollte das funktionieren.
> 
> ...


 
Bei den TCP Verbindungen kann man ja den Port definieren aber bei 
ISO on TCP will er in der Verbindungsprojektierung keinen Port haben, da ist nur ein eingabefeld für TSAP. Hat der TSAP damit was zu tun?


----------



## afk (26 Juni 2007)

Noch mal als Diskussionsbasis:



MW schrieb:


> PS: mit Libnodave funktioniert es bestens, nur diesen Verkehr kann man ja von der SPS seite kaum(garnicht) beeinflussen. Deshalb wollte ich es auf diesem wege versuchen -- ich weiss, dass es funktioniert.


Libnodave kommuniziert unter Anderem per ISO-over-TCP mit der SPS. Dafür wird das S7-Protokoll verwendet, die Kommunikation läuft auf SPS-Seite über Port 102 und wird dort vom Betriebssystem der SPS abgehandelt, darum muß/kann im SPS-Programm nichts getan werden.



MW schrieb:


> Bei den TCP Verbindungen kann man ja den Port definieren aber bei ISO on TCP will er in der Verbindungsprojektierung keinen Port haben, da ist nur ein eingabefeld für TSAP.


Wenn Du im SPS-Programm per Send/Receive Datenpakete senden und empfangen willst, dann mußt Du keine ISO-over-TCP, sondern eine TCP-Verbindung projektieren. AFAIK sind dann noch einige (teilweise zyklische) Aufrufe von (S)FBs bzw. (S)FCs notwendig, und dann sollte das funktionieren. Wie das im SPS-Programm genau aussehen muß, kann ich Dir aber nicht sagen, ist nicht mein Fachgebiet. Such ggf. einfach mal hier im Forum.


Gruß Axel


----------



## MW (26 Juni 2007)

Bei den Anlagen bei denen ich diese Kommunikation gesehen hab wird diese Variante benutzt um mit Visualisierungs- PC´s zu kommunizieren.
die haben auf ihren PC´s nix von Siemens. in der S7 sind ISO on TCP Verbindungen zu "Andere Station" projektiert mit Partner-IP und 
Partner-TSAP. Also muss es ja möglich sein.

Mein anderes Problem ist, dass meine Test SPS bei TCP-Verbindungen der 
Meinung ist, dass der dienst im CP nicht gestartet ist bzw. nicht verfügbar ist, was aber bei nem 6GK7 443-1EX11-0XE0 funktionieren müsste. Dann muss ich wohl weiter probieren (Wahrscheinlich bin ich nur zu blöd  )


----------



## Thomas_v2.1 (26 Juni 2007)

Mit einer S7-300 funktioniert die Verbindung mit einem Lantronix X-Port folgenermaßen:

- In NetPro eine unspezifizierte Verbindung anlegen, gewünschte Ports und IP-Adressen des Partners einstellen.

- Im Programm den AG_RECV zyklisch mit entsprechenden Parametern aufrufen.

- Am PC ein Socket mit den entsprechenden Verbindungsdaten (IPort) öffnen und Daten reinschieben.

-> Sich über die Daten im Datenbaustein freuen 

Da der TCP-Datenstrom keine Anfang- Endekennungen besitzt, müssen die Daten im DB noch entsprechend geparst werden.


----------



## pvbrowser (30 Juni 2007)

Das geht mit der rllib, die Teil von pvbrowser ist.

Seht euch die Klasse mal genauer an.
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlSiemensTCP.html


----------



## pvbrowser (30 Juni 2007)

Ich hatte schon einmal versucht, diese Funktionen zu beschreiben.
Leider ohne Resonanz :-(

http://sps-forum.de/showthread.php?t=13725&highlight=pvbrowser

Vielleicht probiert Ihr die Siemens SPS Kommunikation über
ISO on TCP ja jetzt mal mit ACControl aus.


----------



## Thomas_v2.1 (30 Juni 2007)

Also TCP-Verbindungen zumindest lassen sich mit ACControl nicht simulieren.
Dazu gab es auch schon einen Fred: http://www.sps-forum.de/showthread.php?t=10132 aber von Deltalogic kam noch keine Rückmeldung.

Zum PVBrowser-Spamming sag ich mal nix, das machst du ja auch in anderen Foren.


----------



## pvbrowser (30 Juni 2007)

> Also TCP-Verbindungen zumindest lassen sich mit ACControl nicht simulieren.
Falsch

> Zum PVBrowser-Spamming sag ich mal nix, das machst du ja auch in 
> anderen Foren.
Danke für die Blumen.
Was soll das jetzt ???


----------



## seeba (30 Juni 2007)

pvbrowser schrieb:


> Danke für die Blumen.
> Was soll das jetzt ???


Rainer, nicht aufregen.


----------



## zotos (30 Juni 2007)

seeba schrieb:


> Rainer, nicht aufregen.



Ja ruhe bewahren. Auch wenn einem die Lust am Helfen dabei vergehen könnte.


----------



## Thomas_v2.1 (30 Juni 2007)

Gut, in diesem Fall hatte der Link zum pvbrowser wenigstens mal Bezug zum Thema.
In dem Beispiel wird zu ACControl ja eine ISO on TCP Verbindung aufgebaut, ich hatte mal eine reine TCP-Verbindung getestet die mit der Simulation nicht zu funktionieren scheint.


----------



## MW (4 Juli 2007)

Bei den antworten muss ich ja drauf schließen, dass von euch auch keiner so recht weis wie die Send/Receive Kommunikation auf ISO on TCP Basis zwischen S7 und PC zurealisieren wäre. 
Auf reinen TCP-Verbindungen funktionieren die Standart Bausteine (FC 5, FC 6, FC 50 und FC60) ja meines wissens nicht oder lieg ich damit falsch???


----------



## Question_mark (4 Juli 2007)

*Mal wieder das Rad neu erfinden...*

Hallo,



			
				MW schrieb:
			
		

> Soweit ich weis geht dies Mit den Windows Sockets.



Ja, das kann man mit WinSock machen. Ist aber wirklich der unterste Level. Du musst nur noch einen TCP/IP Protokoll-Stack daraufsetzen...  
Und da Du mit ISO over TCP kommunizieren möchtest, pfriemelst Du dann das S7 - Kommunikationsprotokoll in das TCP-Protokoll, ganz einfach...



			
				MW schrieb:
			
		

> Nur die Sps sagt das die verbindung nicht aufgebaut ist.



Wundert mich nicht, da fehlt ein bißchen, um die S7 zur Kommunikation zu überreden, siehe oben.

Ach ja, das geht natürlich alles ohne die FB's oder FC's in der S7, solange die S7 nicht auf eigene Initiative mit Daten auf den PC losballern möchte (was übrigens auch keinen Sinn macht).

Ist Deine Frage damit hinreichend beantwortet ?

Gruß

Question_mark


----------



## MW (4 Juli 2007)

Question_mark schrieb:


> Hallo,
> Ja, das kann man mit WinSock machen. Ist aber wirklich der unterste Level. Du musst nur noch einen TCP/IP Protokoll-Stack daraufsetzen...
> Und da Du mit ISO over TCP kommunizieren möchtest, pfriemelst Du dann das S7 - Kommunikationsprotokoll in das TCP-Protokoll, ganz einfach...


 
Ja ganz einfach  das kann ja nich so einfach sein.

Wenn das so "einfach" is dann gib mir mal bitte nen Ansatz, denn momentan is bei mir Datenstau


----------



## Question_mark (4 Juli 2007)

*Rad neu erfinden ...*

Hallo,



			
				MW schrieb:
			
		

> momentan nur den Stink normalen (Unterste Level) Socket



Dann such Dir doch mal einen etwas höheren Level, z.B. ein OCX oder wie der Kram in VB heisst, mit TCP/IP Protokoll. Dann fehlt Dir immer noch das S7-Protokoll, das muss nämlich noch in dem TCP versteckt werden. Insgesamt hast Du dann einige hunderte Arbeitsstunden für eine etwas wackelige, laienhafte Kommunikationslösung vor Dir, die evtl. bei der kleinsten Störung/Fehler Deinen PC und die Kommunikation in das Nirwana schiesst.
Das S7-Protokoll ist nicht offengelegt, viel Spass bei der Forschung  
Du kannst jetzt ein halbes Jahr an einer unvollkommenen Lösung basteln und Zeit verschwenden, aber das lohnt sich nicht wirklich. Ich kann Dir wirklich nur Simatic.Net oder AGLink 4.0 von DeltaLogic zur S7 - Kommunikation empfehlen. Alles andere ist der Versuch, das Rad neu zu erfinden...

Gruß

Question_mark

PS : Wenn Du natürlich einige Monate Zeit hast und das Erforschen des S7-Protokolls Dir besonders viel Spass macht, dann nur zu. Aber finanziell und vom Arbeitsaufwand gesehen lohnt sich das nicht wirklich...


----------



## MW (5 Juli 2007)

Na gut,
Zwar haben das die Leute von M............ auch hin bekommen und den ihre kommunikation läuft auch auf dieser Basis und das wie ich bis jetzt weis auch nach Jahren SAU GUT, wenn nicht sogar besser wie das Siemens eigene Zeug.

Dann bleib ich eben weiterhin bei Libnodave, dass funktioniert jedenfalls und is auch recht einfach in der anwendung.


----------



## afk (5 Juli 2007)

MW schrieb:


> Auf reinen TCP-Verbindungen funktionieren die Standart Bausteine (FC 5, FC 6, FC 50 und FC60) ja meines wissens nicht oder lieg ich damit falsch???


Ich bin zwar kein SPS-Programmierer, aber ich würde mal vermuten, da liegst Du völlig falsch.

AFAIK mußt Du einfach entweder eine TCP-Verbindung projektieren, oder dynamisch eine TCP-Verbindung im SPS-Programm aufbauen (das geht zumindest bei PN-CPUs mit FB 65), und dann im SPS-Programm mit den entsprechenden Sende- und Empfangsbausteinen die Daten an den PC schicken bzw. vom PC empfangen. Wie das genau geht, mußt Du die SPS-Spezialisten hier fragen, oder Dir einfach mal von Siemens ein entsprechendes Beispielprojekt herunterladen. Du mußt nur aufpassen, daß Du das richtige Beispiel erwischt, bei PN-Systemen müssen z.B ganz andere Bausteine verwendet werden, als bei den Anderen.

Das macht aber IMHO nur dann Sinn, wenn Du im SPS-Programm bestimmen mußt, wann welche Daten an den PC gesendet werden. Sonst kannst Du einfach weiterhin libnodave nehmen, und gut is.


Gruß Axel


----------



## pvbrowser (5 Juli 2007)

Das geht !

Siehe:

http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlSiemensTCP.html

Beispiel dazu in:

http://pvbrowser.de/pvbrowser/tar/siemensdemo.tar.gz

Siehe auch meine erste Antwort.
Die Klasse kann fetch/write und send/receive.


----------



## afk (5 Juli 2007)

pvbrowser schrieb:


> Das geht !
> 
> Siehe:
> 
> http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlSiemensTCP.html


Wenn ich mich nicht täusche, dann wird da in etwa das gleiche gemacht wie in libnodave (Daten von der CPU pollen, ohne Einfluß durch das SPS-Programm).

Aber siehe erstes Posting:



MW schrieb:


> PS: mit Libnodave funktioniert es bestens, nur diesen Verkehr kann man ja von der SPS seite kaum(garnicht) beeinflussen. Deshalb wollte ich es auf diesem wege versuchen -- ich weiss, dass es funktioniert.


MW arbeitet demnach schon mit libnodave, aber will die übertragenen Daten in seinem SPS-Programm bestimmen.


Gruß Axel


----------



## MW (5 Juli 2007)

afk schrieb:


> MW arbeitet demnach schon mit libnodave, aber will die übertragenen Daten in seinem SPS-Programm bestimmen.
> 
> 
> Gruß Axel


 
GENAAAAUUU

Libnodave funktioniert, 
die SPS kann sich aber nicht "einmischen"


----------



## afk (5 Juli 2007)

MW schrieb:


> GENAAAAUUU


Schön, ich dachte fast schon, ich hätte es falsch verstanden, weil alle Anderen irgendwie über ein anderes Thema geschrieben haben ...  

Dann probier doch einfach mal, wie ich hier schon erwähnt habe, mit einer TCP-Verbindung auf irgendeinem Port > 1024, ob's dann funktioniert.


Gruß Axel


----------



## seeba (5 Juli 2007)

und das ist in .NET doch echt das allerleichteste


----------



## afk (5 Juli 2007)

seeba schrieb:


> und das ist in .NET doch echt das allerleichteste


Jetzt bin ich schon wieder am Grübeln, ob wir hier über das gleiche Thema schreiben ... 
	

	
	
		
		

		
			





Gruß Axel


----------



## MW (5 Juli 2007)

afk schrieb:


> Jetzt bin ich schon wieder am Grübeln, ob wir hier über das gleiche Thema schreiben ...
> 
> 
> 
> ...


 
:lol::lol: Is glaub ich noch das richtige, mit .net meint er hoffentlich 
meine Visual Studio Version


----------



## afk (5 Juli 2007)

MW schrieb:


> :lol::lol: Is glaub ich noch das richtige, mit .net meint er hoffentlich
> meine Visual Studio Version


Puh, da bin ich aber beruhigt ...  

Gruß Axel


----------



## MW (5 Juli 2007)

afk schrieb:


> Dann probier doch einfach mal, wie ich hier schon erwähnt habe, mit einer TCP-Verbindung auf irgendeinem Port > 1024, ob's dann funktioniert.
> 
> 
> Gruß Axel


 
Werde ich mal probieren !


----------



## seeba (5 Juli 2007)

afk schrieb:


> Jetzt bin ich schon wieder am Grübeln, ob wir hier über das gleiche Thema schreiben ...
> 
> 
> 
> ...


Visual Basic 2005 dürfte zum Bereich .NET gehören.


----------



## MW (13 Juli 2007)

Wer lesen kann is klar im Vorteil !!!!!! ICH MUSS NOCH ÜBEN  

Ich hab ja versucht, erstmal testweise 25 Bytes, per Send an einen normalen PC zu schicken. Das hab ich auf S7 seite mit dem FC 5 (AG_SEND) gemacht. Dieser hat aber bei der TCP-Verbindung total wirre Fehlermeldungen ausgespuckt.

Nun hab ich folgendes in der doku gelesen:

Hinweis:
Beachten Sie bitte folgende Besonderheit für TCP-Verbindungen:
Bei den S7-CPs für S7-400 müssen Sie auf TCP-Verbindungen den FC AG_LSEND verwenden!


Also am PC über einen Socket mit der SPS connecten und auf der S7-Seite nich den FC 5 sondern den FC 50 verwenden und siehe da die Byts wackeln los. :s18:


----------

