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

Results 1 to 8 of 8

Thread: TCP Kommunikation mit PC über TCON und TSEND/TRCV (s7-1500)

  1. #1
    Join Date
    10.08.2018
    Posts
    3
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Guten Tag zusammen,

    ich frage mich, ob es für den TCON Baustein irgendeine Möglichkeit gibt den aktuellen Verbindungsstatus abzufragen.

    Ich bekomme immer nur den 80A3 Status, egal ob der Kommunikationspartner online ist oder nicht.

    Meine Idee war, über den TSEND Baustein den Status abzufragen und bei Verbindungsproblemen die Verbindung zu disconnecten..

    Allerdings klappt das auch nicht optimal..

    Hat jemand vielleicht ein Beispiel, wie man sowas am besten aufbaut? Oder welche Möglichkeit es gibt, vor dem Senden den Status der Verbindung zu überprüfen?

    MfG und ein schönes Wochenende,

    Paul
    Reply With Quote Reply With Quote Answered: TCP Kommunikation mit PC über TCON und TSEND/TRCV (s7-1500)  

  2. "
    Quote Originally Posted by paba View Post
    Darum habe ich mir gedacht, dass sobald TSend einen Kommunikationsfehler ausgibt, TCon erneut solange einen Request bekommt, bis DONE erneut 1 gesetzt wird. Dies funktioniert leider nicht, ich bekomme immer nur den Fehlercode 80A3 ("Verbindung mit derselben ID aktiv" oder so ähnlich) und keinen Status darüber, ob nun wieder eine Verbindung besteht oder nicht..
    Wie bereits geschrieben: TCON baut die Verbindung nicht auf, sondern registriert die Verbindung nur (*). Deshalb soll TCON auch nur einmal requested werden - dann ist die Verbindung registriert und die Firmware der CPU kümmert sich um den Verbindungsaufbau, auch nach einem späteren Verbindungsabbruch. Den Verbindungsaufbau(-Versuch) kann man nicht mit TCON forcieren/"erzwingen". Ein erneuter TCON-Request wird zu einer Fehlermeldung führen, weil die Verbindung bereits registriert ist.

    Will man TCON erneut mit REQ=1 aufrufen, dann muß man vorher mit TDISCON die Verbindung deregistrieren/abmelden (*) (dabei wird die Verbindung abgebaut falls aufgebaut, und die Sendepuffer und Empfangspuffer verworfen).

    Um den Verbindungsstatus VOR dem Sende-Request auszuwerten, muß man den Verbindungsstatus mit TRCV oder T_DIAG (oder mit einem TSEND mit REQ=0 ?) ermitteln.

    (*) Tip: zur Wirkungsweise von TCON und TDISCON beobachte den Verbindungsstatus im Webserver der CPU


    Quote Originally Posted by paba View Post
    Das Problem bei der Sache ist, dass, solange keine Verbindung besteht, die versendeten Zeichen anscheinend in irgendeinem Buffer zwischengespeichert werden und, sobald wieder eine Verbindung besteht (TCon kümmert sich ja selbstständig um den Verbindungsaufbau), die in der Zwischenzeit gesendeten Daten alle auf einmal vom PC-Programm empfangen werden und dieses dadurch abstürzt.
    Warum stürzt das PC-Programm da ab? Hast Du Einfluß auf das PC-Programm bzw. das verwendete Nachrichten-Protokoll? Vielleicht kann man ein geeigneteres Protokoll oder Protokoll-Rahmen verwenden, daß der Empfänger unerwartete Zeichen einfach verwirft?

    Harald"


  3. #2
    Join Date
    24.01.2018
    Posts
    169
    Danke
    30
    Erhielt 40 Danke für 36 Beiträge

    Default

    was sagt den das Handbuch zu "80A3"
    TCON stellt eine Verbindung her, je nach Einstellung passiv oder aktiv
    Wenn als TCON den Fehler wirft kann dein Partner Online sein wie er möchte...
    Da brauchst auch nicht mit anderen Baustein auf der Schnittelle rumdatteln, hilft da nicht weiter - Fehlercode lesen, nachlesen was er aussagt und daran kann man es dann hoffentlich festmachen wo es hängt

    Schau mal hier:
    https://support.industry.siemens.com...dti=0&lc=de-WW
    Beste Grüße und happy coding
    RedCali

  4. #3
    Join Date
    22.06.2009
    Location
    Sassnitz
    Posts
    14,179
    Danke
    1,145
    Erhielt 4,174 Danke für 3,374 Beiträge

    Default

    Vielleicht ist die Anweisung T_DIAG hilfreich?

    Übrigens baut TCON keine Verbindung auf, sondern registriert nur die Verbindungsbeschreibung - und nur wenn da drin steht, daß das eine Verbindung mit aktivem Verbindungsaufbau ist, dann versucht die Firmware der CPU eine Verbindung aufzubauen.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  5. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    MFreiberger (11.11.2019)

  6. #4
    Join Date
    22.06.2009
    Location
    Sassnitz
    Posts
    14,179
    Danke
    1,145
    Erhielt 4,174 Danke für 3,374 Beiträge

    Default

    Quote Originally Posted by paba View Post
    ich frage mich, ob es für den TCON Baustein irgendeine Möglichkeit gibt den aktuellen Verbindungsstatus abzufragen.

    Ich bekomme immer nur den 80A3 Status, egal ob der Kommunikationspartner online ist oder nicht.
    TCON ist zur Verbindungsdiagnose nicht geeignet. TCON sollte nur einmal solange aufgerufen werden, bis DONE=1 ist (Verbindung wurde erfolgreich eingerichtet/registriert) (oder ein Fehler auftrat, dann schauen welcher Fehler das ist und reagieren).

    Empfängst Du auch von dem Kommunikationspartner? Dann kannst Du zur Verbindungsdiagnose den Status von TRCV verwenden.
    TSEND sollte auch ohne Sendeauftrag (REQ=0, BUSY=0) trotzdem einen Status zur Verbindung liefern (mit der S7-1500 kenne ich mich allerdings nicht aus).

    Oder halt den neuen T_DIAG für Warmduscher verwenden

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  7. #5
    paba is offline Neuer Benutzer
    Themenstarter
    Join Date
    10.08.2018
    Posts
    3
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Default

    danke für die Antworten. Vielleicht sollte ich das Problem etwas detaillierter erläutern.

    Der erste Verbindungsaufbau zu dem Programm auf dem Computer funktioniert ohne Probleme, der Baustein TCON ist aktiver Kommunikationspartner und bekommt bei Erfolg auch keinen weiteren Request.
    Bei erfolgreicher Verbindung wird jede Sekunde ein Zeichen gesendet und auf eine Antwort vom Computer gewartet. Das läuft soweit auch alles wie gewünscht, Probleme treten jedoch auf, wenn das Computer Programm neu gestartet wird oder abstürzt..
    Läuft das Programm nicht mehr, bekomme ich durch den TSend Baustein eine Fehlermeldung, dass der Kommunikationspartner nicht erreichbar ist.

    Jetzt könnte ich natürlich einfach weiter versuchen das Zeichen zu schicken bis kein Kommunikationsfehler mehr auftritt und TRcv wieder aktiviert werden kann.
    Das Problem bei der Sache ist, dass, solange keine Verbindung besteht, die versendeten Zeichen anscheinend in irgendeinem Buffer zwischengespeichert werden und, sobald wieder eine Verbindung besteht (TCon kümmert sich ja selbstständig um den Verbindungsaufbau), die in der Zwischenzeit gesendeten Daten alle auf einmal vom PC-Programm empfangen werden und dieses dadurch abstürzt.

    Aus diesem Grund würde ich TSend gerne nur aufrufen, wenn auch sicher eine Verbindung besteht.

    Darum habe ich mir gedacht, dass sobald TSend einen Kommunikationsfehler ausgibt, TCon erneut solange einen Request bekommt, bis DONE erneut 1 gesetzt wird. Dies funktioniert leider nicht, ich bekomme immer nur den Fehlercode 80A3 ("Verbindung mit derselben ID aktiv" oder so ähnlich) und keinen Status darüber, ob nun wieder eine Verbindung besteht oder nicht..

    Ich bin relativ neu in Sachen SPS Programmierung und deshalb hier etwas hilflos.. Werde mir mal T_Diag genauer anschauen und zusätzlich überprüfen, ob TSend auch einen nutzbaren Status ausgibt wenn kein Request aktiv ist.

    Paul

  8. #6
    Join Date
    22.06.2009
    Location
    Sassnitz
    Posts
    14,179
    Danke
    1,145
    Erhielt 4,174 Danke für 3,374 Beiträge

    Default

    Quote Originally Posted by paba View Post
    Darum habe ich mir gedacht, dass sobald TSend einen Kommunikationsfehler ausgibt, TCon erneut solange einen Request bekommt, bis DONE erneut 1 gesetzt wird. Dies funktioniert leider nicht, ich bekomme immer nur den Fehlercode 80A3 ("Verbindung mit derselben ID aktiv" oder so ähnlich) und keinen Status darüber, ob nun wieder eine Verbindung besteht oder nicht..
    Wie bereits geschrieben: TCON baut die Verbindung nicht auf, sondern registriert die Verbindung nur (*). Deshalb soll TCON auch nur einmal requested werden - dann ist die Verbindung registriert und die Firmware der CPU kümmert sich um den Verbindungsaufbau, auch nach einem späteren Verbindungsabbruch. Den Verbindungsaufbau(-Versuch) kann man nicht mit TCON forcieren/"erzwingen". Ein erneuter TCON-Request wird zu einer Fehlermeldung führen, weil die Verbindung bereits registriert ist.

    Will man TCON erneut mit REQ=1 aufrufen, dann muß man vorher mit TDISCON die Verbindung deregistrieren/abmelden (*) (dabei wird die Verbindung abgebaut falls aufgebaut, und die Sendepuffer und Empfangspuffer verworfen).

    Um den Verbindungsstatus VOR dem Sende-Request auszuwerten, muß man den Verbindungsstatus mit TRCV oder T_DIAG (oder mit einem TSEND mit REQ=0 ?) ermitteln.

    (*) Tip: zur Wirkungsweise von TCON und TDISCON beobachte den Verbindungsstatus im Webserver der CPU


    Quote Originally Posted by paba View Post
    Das Problem bei der Sache ist, dass, solange keine Verbindung besteht, die versendeten Zeichen anscheinend in irgendeinem Buffer zwischengespeichert werden und, sobald wieder eine Verbindung besteht (TCon kümmert sich ja selbstständig um den Verbindungsaufbau), die in der Zwischenzeit gesendeten Daten alle auf einmal vom PC-Programm empfangen werden und dieses dadurch abstürzt.
    Warum stürzt das PC-Programm da ab? Hast Du Einfluß auf das PC-Programm bzw. das verwendete Nachrichten-Protokoll? Vielleicht kann man ein geeigneteres Protokoll oder Protokoll-Rahmen verwenden, daß der Empfänger unerwartete Zeichen einfach verwirft?

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  9. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    paba (11.11.2019)

  10. #7
    Join Date
    04.08.2011
    Posts
    43
    Danke
    1
    Erhielt 4 Danke für 4 Beiträge

    Default

    Hallo,

    ich habe auch in einigen Anlagen Kommunikation über TCON/TSEND/TRECV laufen.

    Ich mache es wie von PN/DP Beschrieben.
    Ich aktiviere den TCON bis ich einmal ein Done ohne Fehler erhalten habe und speichere mir diesen Status.
    Mit diesem gespeicherten Status aktiviere ich die Freigabe für den TSEND.
    Zusätzlich frage ich über den T_DIAG die Verbindung ab um das Senden zu sperren und dem Bediener eine Fehlermeldung ausgeben zu können.
    Dies fuktioniert sehr gut.
    Sobald ich den TDISCON aktiviere wird das Senden sowie die Verbindungsüberwachung deaktiviert bis die Verbindung erneut aufgeabaut wurde.

  11. #8
    paba is offline Neuer Benutzer
    Themenstarter
    Join Date
    10.08.2018
    Posts
    3
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Quote Originally Posted by PN/DP View Post
    Um den Verbindungsstatus VOR dem Sende-Request auszuwerten, muß man den Verbindungsstatus mit TRCV oder T_DIAG (oder mit einem TSEND mit REQ=0 ?) ermitteln.
    Dank dir, ich hatte zuvor Trcv nur aufgerufen wenn ein bestimmtes Zeichen gesendet wurde.. Jetzt, wo der Baustein aktiviert bleibt sobald die Verbindung über TCon registiert ist, kann ich überprüfen ob die Verbindung aktiv ist oder nicht. Klappt auch ohne T_Diag

    Quote Originally Posted by PN/DP View Post
    Warum stürzt das PC-Programm da ab? Hast Du Einfluß auf das PC-Programm bzw. das verwendete Nachrichten-Protokoll? Vielleicht kann man ein geeigneteres Protokoll oder Protokoll-Rahmen verwenden, daß der Empfänger unerwartete Zeichen einfach verwirft?
    Da könnte ich mal genauer nachhaken, allerdings läuft es jetzt ohne Probleme, da keine größeren Datenpakete mehr gesendet werden.


    Jetzt kann es beruhigt mit der Bachelorarbeit weitergehen

Similar Threads

  1. Replies: 7
    Last Post: 13.09.2019, 23:56
  2. Replies: 1
    Last Post: 14.03.2018, 10:50
  3. Replies: 1
    Last Post: 29.06.2012, 09:18
  4. Replies: 0
    Last Post: 17.01.2011, 17:54
  5. Replies: 4
    Last Post: 24.08.2009, 09:06

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •