CP343-1: UDP mit PC geht -- TCP mit PC geht nur eine Richtung (AG_SEND)

IBFS

Level-1
Beiträge
4.068
Reaktionspunkte
893
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, heute habe ich mal eine Frage,

Habe S7-300 + CP343-1

Kommunikation (siehe NETPRO) eingerichtet für UDP
alles geht perfekt AG_SEND + AG_RCV geht, d.h. beide Richtungen gehen


Kommunikation (siehe NETPRO) eingerichtet für TCP
alles andere gleich und das SPS - Programm ist gleich (Puffergrößen 240Byte) etc.

TCP geht nur in Senderichtung CP343 nach PC

Fehlercode am AG_RCV W#16#8184 obwohl der Empfangpuffer für UDP und TCP identisch ist.

Spezialdiagnose sagt - alles OK!!!

Was ist hier los?

Danke im voraus für eure Hilfe!


....
 

Anhänge

  • UDP_TCP.jpg
    UDP_TCP.jpg
    444 KB · Aufrufe: 94
Zuletzt bearbeitet:
Nachfrage:

Kann es sein das ich für das Senden SPS--->PC PORT 2000 und
das Empfangen PC --->SPS jeweils eine getrennte Verbindung aufbauen muss (getrennter PORT z.B. 2001)?

Das Senden und Empfangen (zum gleichen PC) ist zeitlich unabhängig voneinander.

...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Verbindung ?

Hallo,

IBFS schrieb:
Kann es sein das ich für das Senden SPS--->PC PORT 2000 und das Empfangen PC --->SPS jeweils eine getrennte Verbindung aufbauen muss (getrennter PORT z.B. 2001)?

Ich glaube ja...
Ganz aus dem Stegreif, aber wenn ich mich richtig erinnere, kann man das in Netpro so machen. Aber Du solltest noch ergänzen, welche Verbindung Du benutzt, z.B. ISO over TCP oder ???

Gruß

Question_mark
 
Hallo,



Ich glaube ja...
Ganz aus dem Stegreif, aber wenn ich mich richtig erinnere, kann man das in Netpro so machen. Aber Du solltest noch ergänzen, welche Verbindung Du benutzt, z.B. ISO over TCP oder ???

Gruß

Question_mark


Danke für deine Anwort,

ich brauche und benutze nur TCP pur!

ich Teste zwar auf CP343-1 (mit ISO-Möglichkeit) habe aber später
für das Realprojekt "nur" einen LEAN-CP!



Gruß
 
Noch ein paar Fragen...

Hallo,

wer ist denn der Koppelpartner deiner S7-300 : eine S5 oder ein PC (z.B. mit OPC-Server?) ???

Verbindung spezifiziert oder unspezifiziert, im gleichen Projekt oder nicht ?

Schau mal in Netpro nach, unter "Eigenschaften/Optionen". Was hast Du da projektiert ??
Send/Receive
Fetch/Aktiv
WriteAktiv

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wer ist denn der Koppelpartner deiner S7-300 : eine S5 oder ein PC (z.B. mit OPC-Server?) ???

Verbindung spezifiziert oder unspezifiziert, im gleichen Projekt oder nicht ?

Schau mal in Netpro nach, unter "Eigenschaften/Optionen". Was hast Du da projektiert ??
Send/Receive
Fetch/Aktiv
WriteAktiv

Gruß


Hy,


siehe Posting #1

ein ganz normaler PC mit (geöffneten PORTS in der FIREWALL)
redet mit S7-300 / CP343-1 LEAN


Bei UDP kann jeder von beiden unabh. voneinander senden wie er will,
es kommt immer auf der Gegenseite an. Es ist eine Verbindung projektiert
siehe Grafik #1

Bei TCP - PC ist SERVER - kann ich Sendungen von der SPS empfangen.
Ich weiß aber nicht wie der "RÜCKWEG" funktioniert, den das SENDEN zur
SPS geht nicht.

Ich vermute, hierbei muß die SPS dann der SERVER - auf einer 2.Verbindung (logisch nicht physikalisch) - sein.

Aber an der Stelle komme ich mit probieren dann nicht mehr weiter.

...
 
Ich nehme an, Du hast die Verbindung als "Send/Recv" konfiguriert.
In diesem Fall ist das SPS-Programm für die Datenabwicklung
zuständig. Send- und Recv-Kommandos müssen vom Gegenüber (PC)
beantwortet werden.
Im Umkehrschluss heißt das aber auch, das der PC auf dieser
Verbindung nicht initiativ werden kann.
Das ist ein Unterschied zur UDP-Verbindung.

Falls der PC aktiv Daten senden soll, so richte eine zweite TCP-Verbindung
mit der Betriebsart "Write Passiv" ein.
(Dann arbeitet die SPS als Server).

Am Rande: Welche PC-Software verwendest Du ?
 

Anhänge

  • TCP2.jpg
    TCP2.jpg
    383,7 KB · Aufrufe: 37
Ich nehme an, Du hast die Verbindung als "Send/Recv" konfiguriert.
In diesem Fall ist das SPS-Programm für die Datenabwicklung
zuständig. Send- und Recv-Kommandos müssen vom Gegenüber (PC)
beantwortet werden.
Im Umkehrschluss heißt das aber auch, das der PC auf dieser
Verbindung nicht initiativ werden kann.

Heißt das also, dass man bei einer Send/Receive Verbindung zwischen PC - SPS nicht vom PC aus senden kann/darf ??????

Wie bekommt man dann Daten über Send/Receive vom PC wieder zur SPS ??

Ich hab zu Testzwecken auch mal sowas Programieriert, Senden von SPS-->PC funktioniert aber beim Receive bin ich noch nicht angekommen, deshalb die frage wie das den geht
 
Heißt das also, dass man bei einer Send/Receive Verbindung zwischen PC - SPS nicht vom PC aus senden kann/darf ??????

Wie bekommt man dann Daten über Send/Receive vom PC wieder zur SPS ??

Ich hab zu Testzwecken auch mal sowas Programieriert, Senden von SPS-->PC funktioniert aber beim Receive bin ich noch nicht angekommen, deshalb die frage wie das den geht

In den letzten Tages habe ich mich geradezu vollgesaugt mit INFOs zu dem Thema.


Mein derzeitiger Wissensstand (wenn was falsch, ist bitte berichtigen)


1.
UDP entspricht etwa einer 3draht RS232 ohne Flußkontrolle und Handshake

Dehalb ist hier SPS (1ne Verbindung SEND/RVC ID:1 ) <--> PC (UDP-Hyperterminal) gleichberechtigt bei Senden und Empfangen.
Jeder darf senden wann er will. Die Daten werden dann mit der empfangen Länge in der RCV-Richtung ggf. in der VAT oder in der SEND Richtung auf dem PC (Terminalprogramm) angezeigt.

D.h. für UDP wird NUR eine Verbindung im NetPro projektiert


2.
TCP nativ

1. Verbindung projektiert als SEND/RECEIVE ---- der PC ist TCP-SERVER

http://www.hw-group.com/products/hercules/index_de.html

Serverfenster PORT eintragen ---> TASTE LISTEN

Der PC kann NICHTS über DIESE Verbindung eigenmächtig an die SPS senden.
Das wusste ich zu beginn dieses Themas noch nicht !!
Daher logisch SPS-kann SENDEN und (über diese Verb.-ID) nichts Empfangen

2. Verbindung projektiert als WRITE passiv --- die SPS ist TCP-SERVER

Es wird eine 2te Verbindungsresource benötigt.

Nur über diese Verbindung kann die der PC - ungefragt was senden (überbraten) d.h. die SPS ist SERVER


http://www.hw-group.com/products/hercules/index_de.html

Clientfenster Module IP + PORT eintragen ---> TASTE CONNECT

diese Verbindung kann durch FC7 "AG_LOCK" und FC8 "AG_UNLOCK"
geziehlt gesperrt oder freigegeben werden.




3.
Zusatz

leider beziehen sich viele Beispiele nur auf die TCP-Kommunikation
zwischen 2 SPSen. Da hier der CP (z.B. 343-1) aus Sicht der anderen
SPS der jeweils der SERVER ist, braucht man deshalb jeweils beim
Senden nur SND/RCV und kein FETCH/WRITE, aber das ist schon
wieder ein neues Thema.


Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die S7-SPS kann pro TCP (native) Verbindung entweder Client oder Server sein.

- Client: SEND/RECEIVE (SPS schickt Daten/fordert Daten an)
- Server: FETCH (zb ein anderer HOLT aktiv Daten per RECEIVE)
- Server: WRITE (zb ein anderer SCHREIBT aktiv Daten per SEND)
(leider kann die Serververbindung nicht beides gleichzeitig,
warum ist mir nicht ganz klar).

Zwei S7 auf diese Art koppeln geht auf mehrere Arten:

Beispiel 1.
- SPS1 ist aktiv für Senden und Empfang
- SPS2 muss darauf reagieren, wird aber selber nicht aktiv.
In diesem Fall braucht SPS1 eine Verbindung Send/Receive,
SPS2 jedoch zwei Verbindungen: FETCH und WRITE.

Beispiel 2.
- SPS1 und SPS2 senden dem anderen Daten.
Hier benötigen beide jeweils eine Client- und eine Serverbindung.


Für SPS1 kann man auch einen PC benutzen.
Für SPS2 einen PC zu benutzen geht auch, ist aber eher
ungewöhnlich.
 
2. Verbindung projektiert als WRITE passiv --- die SPS ist TCP-SERVER

Es wird eine 2te Verbindungsresource benötigt.

Nur über diese Verbindung kann die der PC - ungefragt was senden (überbraten) d.h. die SPS ist SERVER


http://www.hw-group.com/products/hercules/index_de.html

dann kann man aber auch gleich die erste Verbindung FETCH passiv machen und alles vom PC machen lassen.

Bei FETCH/WRITE muss man aber auch noch den Telegrammkopf zusammenbauen damit die SPS weiß was man von ihr will.


Beim Send/receive von SPS-Seite kann man sich das hoffentlich sparen
(beim send brauch man das jedenfalls nicht).

Ich hoffe die PC-Progies melden sich hier nochmal zu wort
(ich denk da z.b. an QM, Zottel, volker usw.)
 
Die S7-SPS kann pro TCP (native) Verbindung entweder Client oder Server sein.

- Client: SEND/RECEIVE (SPS schickt Daten/fordert Daten an)
- Server: FETCH (zb ein anderer HOLT aktiv Daten per RECEIVE)
- Server: WRITE (zb ein anderer SCHREIBT aktiv Daten per SEND)
(leider kann die Serververbindung nicht beides gleichzeitig,
warum ist mir nicht ganz klar).

Zwei S7 auf diese Art koppeln geht auf mehrere Arten:

Beispiel 1.
- SPS1 ist aktiv für Senden und Empfang
- SPS2 muss darauf reagieren, wird aber selber nicht aktiv.
In diesem Fall braucht SPS1 eine Verbindung Send/Receive,
SPS2 jedoch zwei Verbindungen: FETCH und WRITE.

Beispiel 2.
- SPS1 und SPS2 senden dem anderen Daten.
Hier benötigen beide jeweils eine Client- und eine Serverbindung.


Für SPS1 kann man auch einen PC benutzen.
Für SPS2 einen PC zu benutzen geht auch, ist aber eher
ungewöhnlich.





Wie gesagt:


Meine SPS (als Client mit SEND/RVC) muß JEDERZEIT aktiv an den Leitrechner senden können.

Meine SPS (als WRITEpassiv) muß JEDERZEIT Kommandos bekommen können


d.h 2 Verbindungen

im PC muß man dann für das WRITE an die SPS den

VERBINDUNGSSTRING entsprechend zusammenbauen können
siehe: http://www.sps-foren.de/showpost.php?p=53723&postcount=9 und ff.

Diese Applikation ist bzugegebenermaßen etwas ungewöhnlich, aber
derzeit meine Anforderung.

Ich versuche derzeit noch den anderen "Schaumeiern", die da denken TCP zw. PC und S7 ist nur "geringfügig" aufwändiger als UDP zw. PC und S7 meine UDP-Variante einzureden.

Die Absicherung sollte dabei mit hochzählenden Zyklenzählern erfolgen.


Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
dann kann man aber auch gleich die erste Verbindung FETCH passiv machen und alles vom PC machen lassen.

Woher soll der Rechner (PC) wissen, wann ich geFETCHed werden will?
Wir wollen doch gerade den TRAFFIC sparen, den man bei "ZYKLISCHEN"
OPC-ZUGRIFF ständig auf dem Hals hat!

Datenverkeht nur "ON DEMAND" und das in beide Richtungen.
Sonst müßte ich den Kult ja gar nicht machen.

Aber ich hoffe, das ich denen noch UDP "einreden" kann - alles viel einfacher und mit Hausmitteln auch "sicher" zu machen!

gruß


P.S.

Bei "Send/receive von SPS-Seite" muß man nichts zusammenbauen, Verhält sich exakt wie bei UDP (getestet, siehe Thema-Text)
 
Zuletzt bearbeitet:
Woher soll der Rechner (PC) wissen, wann ich geFETCHed werden will?
Wir wollen doch gerade den TRAFFIC sparen, den man bei "ZYKLISCHEN"
OPC-ZUGRIFF ständig auf dem Hals hat!

JA Ne is klar, dat hab ich ja gecheckt, wäre doch aber bedeutend komfortabler, wenn man über eine Send/Receive Verbindung den ganzen kramm erledigen könnte.


Verkehr is doch gut !!!!!!!!!!!!!!
(solange er zwischen mann und frau stattfindet ;-)



Ich hoffe ja Q_M antwortet doch noch, bei "Wer ist Online" stand zumindest 22:51 noch drin, dass er auf das thema antworten tut (er hat mir beim letzten Problem gut weitergeholfen)
 
Zuletzt bearbeitet:
Ich hatte mich zu Beginn schon gewundert, das bei dem

Hercules-Tool http://www.hw-group.com/products/hercules/index_de.html

für UDP nur 1 Reiter existiert

bei TCP aber jeweils ein Reiter für

TCP-CLINT und
TCP-SERVER

spätestens als bei mir das Empfangen von der PC-Seite nicht ging
- ich hatte den TCP-SERVER aktiviert (TCP-Client ging logischerweise nicht) -
hat ich schon so eine Vorahnung, das es nicht ganz so einfach ist!!


...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der falsche Ansatz ...

Hallo,

MW" schrieb:
dann kann man aber auch gleich die erste Verbindung FETCH passiv machen und alles vom PC machen lassen.

Genau richtig... Wir reden hier von einer Kopplung PC <--> SPS.
Die SPS hat die Fresse zu halten, die Kommunikation sollte hier durch den PC bestimmt werden. Wenn beide Verbindungspartner munter drauf los senden, wird man ganz schnell Probleme bei der Kommunikation bekommen. Die Kommunikation sollte nur vom PC bestimmt werden. Wenn die SPS neue Daten für den PC bereit hat, darf die SPS mir durch das Setzen z.B. eines Merkers mitteilen. Der OPC-Server teilt durch einen Event meiner Applikation auf dem PC mit, dass die SPS neue Daten hat, die lese ich dann mit meiner Applikation aus dem vereinbarten Datenbereich der SPS aus und verarbeite diese (z.B. Weitergabe an die BDE-Datenbank etc.).
Umgekehrt schreibe ich neue Daten ungefragt in die SPS, ich erwarte von der SPS dass sie diese Daten entsprechend verarbeitet.
Dafür sind in der S7-SPS für die Kommunikation keine zusätzlichen FBs, FCs, SFBs, SFCs und Konsorten aufzurufen, egal ob welches Protokoll. Nur bei der Kommunikation mit einer S5 müssen die HTB's "SEND-ALL" und "RECV_ALL" im S5-AG aufgerufen werden.
Bei der Kommunikation zwischen zwei oder mehreren Koppelpartnern (egal ob z.B. SPS <--> SPS oder SPS <--> PC) darf nur ein Partner die Kommunikation koordinieren, sonst gibt es immer Probleme. Von daher ist hier schon völlig falsch an die Aufgabenlösung herangegangen worden, bei der Kopplung SPS <--> PC sollte immer der PC die Kommunikation koordinieren. Aber einfach nur, weil man das auf dem PC z. Zt. mit geringerem Aufwand realisieren kann.

MW" schrieb:
Bei FETCH/WRITE muss man aber auch noch den Telegrammkopf zusammenbauen damit die SPS weiß was man von ihr will.

Nööö, eigentlich nicht ...

Und UDP sollte man bei dieser Art von Kommunikation sowieso vergessen, UDP ist im Gegensatz zu TCP verbindungslos. Ist ungefähr so, als wenn ich einen Brief nicht in den Briefkasten werfe sondern auf der Strasse ablege. Wenn jemand den Brief findet und bei der Post einwirft, habe ich Glück gehabt. Aber was noch schlimmer ist, ich werde nie erfahren, ob der Brief angekommen ist.

Als Kommunikationstreiber auf dem PC sind bei mir aus langer Erfahrung folgende Produkte zu empfehlen :

1) OPC-Server z.B. Simatic-Net oder Deltalogic
Vorteil : Events in meiner Applikation, wenn sich Daten in der SPS ändern
Nachteil : Projektierung in der SPS(z.B. NetPro) erforderlich

2) AG-Link 4.0 von Deltalogic
Vorteil : Keine Projektierung in der SPS erforderlich, du bist sozusagen "on the fly" auf der SPS
Nachteil : Evtl. Änderungen in der SPS müssen durch Polling erfasst werden.

Beide Varianten funktionieren aber bei meinen abgewickelten Projekten schon jahrelang in der Industrie ohne Probleme.

Gruß

Question_mark
 
Aufgabe und Lösung

Hallo,

IBFS schrieb:
Diese Applikation ist bzugegebenermaßen etwas ungewöhnlich, aber derzeit meine Anforderung.

Das ist zwar derzeit Deine Anforderung, ob diese sinnvoll ist und sich Deine Aufgabe nicht besser lösen lässt, steht auf einem anderem Blatt.

Gruß

Question_mark
 
@Question_mark

1. Das TCP-Protokoll ist KUNDENWUNSCH
vorher wollten sie OPC, war aber zu langsam - dann UDP, zu unsicher.
Telegrammaufkommen: jeweils 1 Telegramm pro 30 Sekunden (PRO SPS)


und jetzt kommts:

2. Bei 32 SPSen ist bei einem OPC-SERVER Schluß!

es sollen vielleicht 80 SPSen werden, oder ggf. mehr


FAZIT:

Bei Betrachtung des Gleichzeitigkeitsfaktors und OHNE "UDP-Verschluckende" ROUTER ist m.E. UDP nach wie vor für mich
die beste Lösungen für das konkrete Projekt (wenn es keine OPC sein darf)




Wie gesagt - der Kunde ist immer Schuld :D :confused:
 
Zurück
Oben