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



## IBFS (1 November 2007)

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!


....


----------



## IBFS (1 November 2007)

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.

...


----------



## Question_mark (1 November 2007)

*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


----------



## IBFS (1 November 2007)

Question_mark schrieb:


> Hallo,
> 
> 
> 
> ...


 

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ß


----------



## Question_mark (2 November 2007)

*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ß


----------



## IBFS (2 November 2007)

Question_mark schrieb:


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


 

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.

...


----------



## argv_user (2 November 2007)

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 ?


----------



## IBFS (2 November 2007)

argv_user schrieb:


> 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 ?


 

Ich verwende "Hercules"

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


einer der wenigen UDP-"HyperTerminals" die es gibt.






Bedeutet Betriebsart "Write Passiv"  == kein aktiver Verbindungsaufbau???



Gruß und Danke


----------



## argv_user (2 November 2007)

IBFS schrieb:


> Bedeutet Betriebsart "Write Passiv"  == kein aktiver Verbindungsaufbau???
> 
> 
> 
> Gruß und Danke




Ganz genau. Wenn WRITE  Passiv oder FETCH  Passiv eingestellt sind,
ist diese TCP-Verbindung für AG_SEND/AG_RECV nicht mehr nutzbar.


----------



## MW (3 November 2007)

argv_user schrieb:


> 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.
> ...


 
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


----------



## IBFS (3 November 2007)

MW schrieb:


> 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ß


----------



## argv_user (3 November 2007)

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.


----------



## MW (3 November 2007)

IBFS schrieb:


> *2. Verbindung* projektiert als WRITE passiv --- die SPS ist TCP-SERVER
> 
> Es wird eine 2te Verbindungsresource benötigt.
> 
> ...


 
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.)


----------



## IBFS (3 November 2007)

argv_user schrieb:


> 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)
> ...


 




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ß


----------



## IBFS (3 November 2007)

MW schrieb:


> 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 ge*FETCH*ed 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)


----------



## MW (3 November 2007)

IBFS schrieb:


> Woher soll der Rechner (PC) wissen, wann ich ge*FETCH*ed 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)


----------



## IBFS (3 November 2007)

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!!


...


----------



## Question_mark (3 November 2007)

*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


----------



## Question_mark (3 November 2007)

*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


----------



## IBFS (3 November 2007)

@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


----------



## Question_mark (4 November 2007)

*Und das Konzept noch mal überdenken ...*

Hallo,



			
				IBFS schrieb:
			
		

> Wir wollen doch gerade den TRAFFIC sparen, den man bei "ZYKLISCHEN" OPC-ZUGRIFF ständig auf dem Hals hat!



Den "TRAFFIC" (schon bei dem Wort könnte ich kotzen, hört sich nach Klugscheisserei aus der EDV-Abteilung an, sorry) kann man eigentlich bis zu einer Größe von mehreren zehntausend Variablen vernachlässigen. Wenn der "TRAFFIC" bedeutsam ist, stimmt irgendetwas anderes nicht. Der PC bei mir hat selbstverständlich zwei NIC, eine für die Kommunikation mit der SPS und eine für die Kommunikation mit dem Büro-Netzwerk der Kunden.



			
				IBFS schrieb:
			
		

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



Datenverkehr "ON DEMAND" geht dann ganz gut mit AGLink von Deltalogic. Da gibt es nur "TRAFFIC" "ON DEMAND"...
Aber in beide Richtungen ist definitiv der falsche Ansatz, siehe meinen obigen Post. Und UDP vergess mal lieber, wenn eine gesicherte Kommunikation erforderlich ist.

Gruß

Question_mark

PS : und noch "AGOODNIGHT"


----------



## Question_mark (4 November 2007)

*Ich verstehe das nicht*

Hallo,



			
				IBFS schrieb:
			
		

> und jetzt kommts:
> 
> 2. Bei 32 SPSen ist bei einem OPC-SERVER Schluß!
> 
> es sollen vielleicht 80 SPSen werden, oder ggf. mehr



Ja gut, aber doch wohl nicht alle 80 SPS'sen auf einen PC gleichzeitig loslassen ??? Ein bisschen dezentralisieren, vielleicht je nach Funktionsgruppe an einen PC bis ca. max 8-10 SPS anbinden und diese PC's dann mit der EDV über ein separates Netzwerk anbinden. Wer bis zu 80 SPS an einen PC (egal über welchen Kommunikationsweg oder Protokoll) anbinden und deren Daten verarbeiten will, hat wohl den Urknall überhört  
Wie ich schon oben in vorigen Posts angedeutet habe, stimmt hier irgendwie das ganze Konzept nicht (oder Du hast eben noch nicht alles beschrieben und erläutert). Unter diesen Voraussetzungen würde ich sowas nicht mal mit der Kneifzange anpacken. 
So wie ich das bis jetzt verstanden habe, soll der eine popelige PC die Kommunikation zu 80 SPS und deren Datenverarbeitung übernehmen ??? Bitte sag mir, dass ich das falsch verstanden habe ...
Wie gesagt, das Konzept von Kommunikation und Datenverarbeitung ist m.E. sehr zweifelhaft. 



			
				IBFS schrieb:
			
		

> Wie gesagt - der Kunde ist immer Schuld


Stimmt nicht, laut Vertrag als Auftragnehmer ist immer alles meine Schuld  

Gruß

Question_mark


----------



## IBFS (4 November 2007)

...Ich habe etwa 10 Kontaktpersonen - jeder sagt was anderes - das ist aber bei den US-Boys immer so - Meetings bis der Arzt kommt - Ergebnisse Null.

Ich frage schon seit Monaten nach einem "Vernetzungsplan".

Zum Glück flieg ich in 8 Tagen "rüber", da werde ich denen mal endlich Licht ans Fahrrad machen. 
Die wechseln ihre Meinung und die Kommunikationsprotokolle und -ideen jeden zweiten Tag.

Guts Nächtle!


----------



## Question_mark (4 November 2007)

*Nicht böse sein, aber ..*

Hallo,



			
				IBFS" schrieb:
			
		

> Telegrammaufkommen: jeweils 1 Telegramm pro 30 Sekunden (PRO SPS)



Dann soll doch die SPS nach 30 Sekunden einen Merker setzen und der OPC-Server holt sich dann die Daten. Die Netzwerkbelastung dadurch kann man sich dahinschieben, wo keine Sonne hinkommt, meine Fresse....
Sorry, ich rege mich gerade über soviel Ahnungslosigkeit fürchterlich auf. Aber zum Glück ist ja Dein Kunde schuld  

Gruß

Question_mark


----------



## Question_mark (4 November 2007)

*Nee, da hasse jetzt aber Pech ..*

Hallo,



> Zum Glück flieg ich in 8 Tagen "rüber",



Äcchhhzz, wieso zum Glück ??? Eher mein Beileid. Die Pappnasen haben für alles einen Experten, und am Ende kommt nur Sch...se raus. (Hast Du auch schön brav die Fingerabdrücke abgegeben und die Anzahl der Achselhaare amtlich bestätigen lassen ??? ).
Nimm einfach als Ratschlag von mir mit "rüber", dass hier kein schlüssiges Konzept vorliegt. Mit der von Dir bisher beschriebenen Konfiguration wird das niemals rundlaufen. So geht es definitiv nicht ...

Gruß

Question_mark


----------



## MW (4 November 2007)

MW schrieb:


> 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 ??


 
Hallo Q_M ich muss da nochma nachhacken, fällt dir dazu was ein ???


----------



## IBFS (4 November 2007)

Schlaflos in Deutschland - oder macht ihr durch


----------



## Question_mark (4 November 2007)

*Dat jeht janz einfach  ...*

Hallo,



			
				MW schrieb:
			
		

> Zitat:
> Zitat von MW
> 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 ??



Eine Send/Receive Verbindung muss im allgemeinen zweiseitig aufgebaut werden, d. h. also eine Verbindung zum Lesen und eine zum Schreiben von Daten zur SPS (mal aus der Sicht vom PC gesehen).
Wenn die Verbindung zweiseitig aufgebaut wird, kann man vom PC aus Daten aus der SPS lesen und genauso natürlich auch Daten in die SPS schreiben. Das ist eigentlich der Normalfall. Zu Deinen Fragen :

1) Natürlich kann man bei einer Send/Receive Verbindung (sofern zweiseitig aufgebaut) vom PC Daten in die SPS schreiben und dementsprechend aus der SPS auslesen.
2) Du solltest natürlich dabei die unterschiedlichen Verbindungsarten wie Write/Active, Fetch/Active, Write/Passive etc. berücksichtigen, hieraus ergibt sich eigentlich, wer die Kommunikation steuert /siehe einige Beiträge nach oben).

Gruß

Question_mark


----------



## Question_mark (4 November 2007)

*Na dann gute Nacht ...*

Hallo,



			
				IBFS schrieb:
			
		

> Schlaflos in Deutschland - oder macht ihr durch



Naja, nach Seattle möchte ich heute nicht mehr unbedingt...
Ich mache lieber durch, aber für heute ist genug. Es gibt doch auch noch Foren, in denen Poppen das eigentlich Thema #1 ist  

Gruß

Question_mark


----------



## MW (4 November 2007)

Question_mark schrieb:


> Hallo,
> 
> Eine Send/Receive Verbindung muss im allgemeinen zweiseitig aufgebaut werden, d. h. also eine Verbindung zum Lesen und eine zum Schreiben von Daten zur SPS (mal aus der Sicht vom PC gesehen).
> Wenn die Verbindung zweiseitig aufgebaut wird, kann man vom PC aus Daten aus der SPS lesen und genauso natürlich auch Daten in die SPS schreiben. Das ist eigentlich der Normalfall. Zu Deinen Fragen :
> ...


 
Gut dat bringt mich jetz scho ä stückle weida

Nu is auch bei mir schluss, mein Bier is auch schon wieder alle :twisted: und ich find kein neues:sm23:


----------



## Question_mark (4 November 2007)

*Prost*

Hallo,



			
				MW schrieb:
			
		

> und ich find kein neues



Na dann reich ich Dir mal ein frisches, aber leider virtuelles Pils durch den TCP-Tunnel rüber .... Prost  

Gruß

Question_mark


----------



## MW (4 November 2007)

:sm19: Schmeckt auch gut so nen Virtuelles, besser wie garnix :-D :-D


----------

