Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 11 bis 20 von 32

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

  1. #11
    Avatar von IBFS
    IBFS ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von MW Beitrag anzeigen
    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ß

  2. Folgender Benutzer sagt Danke zu IBFS für den nützlichen Beitrag:

    character (13.11.2007)

  3. #12
    Registriert seit
    28.10.2005
    Ort
    Ottweiler, Saar
    Beiträge
    940
    Danke
    259
    Erhielt 124 Danke für 109 Beiträge

    Standard

    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.

  4. #13
    Registriert seit
    27.11.2005
    Ort
    im Osten
    Beiträge
    1.183
    Danke
    141
    Erhielt 271 Danke für 248 Beiträge

    Standard

    Zitat Zitat von IBFS Beitrag anzeigen

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

  5. #14
    Avatar von IBFS
    IBFS ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von argv_user Beitrag anzeigen
    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...23&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ß

  6. #15
    Avatar von IBFS
    IBFS ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    Zitat Zitat von MW Beitrag anzeigen
    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)
    Geändert von IBFS (03.11.2007 um 23:03 Uhr)

  7. #16
    Registriert seit
    27.11.2005
    Ort
    im Osten
    Beiträge
    1.183
    Danke
    141
    Erhielt 271 Danke für 248 Beiträge

    Standard

    Zitat Zitat von IBFS Beitrag anzeigen
    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)
    Geändert von MW (03.11.2007 um 23:23 Uhr)

  8. #17
    Avatar von IBFS
    IBFS ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

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


    ...

  9. #18
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Beitrag

    Hallo,

    Zitat Zitat von MW"
    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.

    Zitat Zitat von MW"
    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
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)
    Zitieren Zitieren Der falsche Ansatz ...  

  10. #19
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Beitrag

    Hallo,

    Zitat Zitat von IBFS
    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
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)
    Zitieren Zitieren Aufgabe und Lösung  

  11. #20
    Avatar von IBFS
    IBFS ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    @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

Ähnliche Themen

  1. Antworten: 7
    Letzter Beitrag: 19.02.2008, 20:04
  2. Schneller als CP343-1, geht das ?
    Von argv_user im Forum Simatic
    Antworten: 26
    Letzter Beitrag: 16.02.2008, 19:48
  3. Antworten: 10
    Letzter Beitrag: 01.08.2006, 09:52
  4. FB alleine geht, FB 2x geht nicht?
    Von MSP im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 18.08.2005, 15:00
  5. CP343-1 IT und CP443-1 IT geht in Stopp
    Von Marc_3 im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 13.01.2005, 12:12

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •