TIA TCON bei S7-1500 als Server

Mephisto

Level-1
Beiträge
242
Reaktionspunkte
12
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Ich versuche nun schon seit Tagen, eine TCP-Verbindung zu einem PC herzustellen - leider ohne Erfolg.
Ich verwende dazu die Bausteine TCON, TSEND, TRCV und TDISCON.
Wenn ich die Verbindungsparameter so einstelle, dass die CPU der Client (aktiver Verbindungsaufbau) ist, dann funktioniert der Verbindungsaufbau wunderbar.
Getestet habe ich das ganze mit dem Port 7, der unter Windows alle Nachrichten retour sendet sowie mit zwei selbstschriebenen Servern mit dem Port 2000.

Wenn ich jedoch die CPU als Server konfiguriere (also passiver Verbindungsaufbau), dann kann die Verbindung nicht aufgebaut werden. Die CPU meldet am TCON BUSY und wartet.
Am PC (getestet mit zwei selbstgeschrieben Clients) erhalte ich nach versuchtem Verbindungsaufbau die Info, dass die Verbindung geschlossen wurde.
Die CPU kriegt davon aber nichts mit. Die bleibt stur auf BUSY stehen.

In der CPU habe ich das Testprogramm aus folgendem Siemens FAQ laufen:
https://support.industry.siemens.co...nem-fremd-controller-(clx-glx)?dti=0&lc=de-DE

Nach intensiver Suche im Forum und bei Google hab ich zwar mitbekommen, dass dieser Fehler öfters auftritt (wenn die CPU der Server ist), jedoch keine Lösung dazu. Könnt ihr mir weiterhelfen?
 
Hi,

vllt. probierst du es mal nur mit TSEND_C und TRCV_C, sparst du dir 2 Bausteine und kannst die Verbindung auch terminieren, wenn du das willst.

Mfg Clyde
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi.

Ich mache zur Zeit dann quasi das selbe wie du.
Das mit dem Busy ist mir heute ebenfalls aufgefallen nach dem ich die Verbindung gekillt habe auf Seiten PC ohne einen richtigen Verbindungsabbau. Nachdem ich aber die Ip-Adresse vom Partner auf 0.0.0.0 gestellt habe lief es dann aber immer ohne Probleme. Vielleicht kannst du das ja mal so testen.
 
Hallo!
vllt. probierst du es mal nur mit TSEND_C und TRCV_C
Möchte ich nicht, da ich einen Bausein benötige, der mir eine Verbindung auf- bzw. abbaut und weitere Bausteine, die über diese Verbindung Daten senden, bzw. empfangen. Zudem habe ich es testweise versucht und es hat genausowenig geklappt.
Ich mache zur Zeit dann quasi das selbe wie du.
Das mit dem Busy ist mir heute ebenfalls aufgefallen nach dem ich die Verbindung gekillt habe auf Seiten PC ohne einen richtigen Verbindungsabbau. Nachdem ich aber die Ip-Adresse vom Partner auf 0.0.0.0 gestellt habe lief es dann aber immer ohne Probleme. Vielleicht kannst du das ja mal so testen.
Wenn ich die Partner-IP auf 0.0.0.0 stelle, bekomme ich eine Fehlermeldung im Compiler. Wie hast du das hinbekommen? Das klingt interessant. Mir wäre es sowieso lieber, wenn Verbindungsanfragen von verschiedenen Teilnehmern akzeptiert werden würden.

Ich bin mitlerweile etwas weiter. Ich habe in der Verbindungsprojektierung den Remote-Port auf 0 gestellt und konnte mich ab da mit dem PC auf meine Steuerung verbinden. Leidergottes wurden im Siemens Beispiel sowohl Remote-Port als auch Local-Port vom selben Parameter versorgt und somit immer ident. Ich hab mich also offensichtlich - mal wieder - fälschlicherweise auf Siemens verlassen...
 
Hallo!

Bin jetzt weiter am testen und mal davon abgesehen, dass ich mich nach wie vor Frage, warum es NICHT so funktioniert, wie von Siemens beschrieben (und vom Siemens-Support bestätigt), bin ich gerade am Suchen einer Lösung für eine Verbindungsunterbrechungserkennung.
Also z.B.: Netzwerkkabel abgesteckt. Da läuft meine Verbinund nämlich gut und gern 10-15sec. weiter und bricht erst dann mit einer Fehlermeldung ab. Kann ich hier eine Diagnose beschleunigen? So im 500-1000ms Bereich? Das ganze sollte ohnen einen Watchdog funktionieren, da meine SPS nur Daten an den PC senden, jedoch keine empfangen soll. (genauer: Der PC soll keine Daten senden können).
 
Es liegt aber im Prinzip von TCP begründet, dass wenn ein gesendetes Paket vom Empfänger nach einer Zeit x nicht bestätigt wird, dieses erneut gesendet wird. Und das Ganze wird mindestens 3 Mal versucht (retransmit). Bei Windows ist der Timeout für ein retransmit beispielsweise 3 Sekunden, wobei diese Zeit auch noch variabel berechnet wird und üblicherweise nach jedem retry etwas erhöht wird. Erst nachdem das retrylimit überschritten wurde wird eine Verbindung als abgebaut festgestellt.

Wenn du definiert nach 500ms Daten benötigst, dann ist Profinet wohl eher die richtige Wahl. Oder du erzeugst dir einen eigenen Watchdog in deinen Paketen, viel anders ist das bei Profinet-IO auch nicht gelöst.
 
Hab jetzt mit T_DIAG rumgespielt. Auch hier bekomme ich einen Verbindungsabbruch erst nach ca. 10-20sec. mit. Das würde sich dann auch mit der Aussage von Thomas_v2.1 decken.
Ich muss über TCP senden, Profinet ist nicht weil das die PC-Software nicht kann.
Wenn sich keine andere Lösung anbietet, dann werde ich wohl oder übel mit den 10-20sec. leben müssen. Dazu brauch ich dann aber keinen T_Diag. Das erkenn ich mit meinen TCON, TSEND, etc. auch...
Watchdog ist nicht, weil ich lediglich Daten sende, nicht aber empfange.

Oder hat noch jemand eine geniale - weil einfache - Idee?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Mephisto,

Das Beispiel verwendet ja intern auf der S7 die genannten Bausteine. Der T_CON benoetigt ja eine Projektierung ueber so eine Variable TCON_Param oder so. Welche Parameter hast Du da wie gesetzt, damit die S7 als Server agiert?
Das Thema Verbindungsueberwachung ist, wie durch Thomas_V2.1 bereits gesagt, eine TCP Sache. Das TimeOut ist durch den TCP Standard vorgegeben und sollte nur in Ausnahmefaellen veraendert werden. Da ist der RFC ziemlich deutlich. Also keine Schuld von Dir oder Siemens oder sonstwem. Wenn Du ein schnelles TimeOut benoetigst, bleiben Dir zwei Optionen:
* WatchDog --> Hattest du bereits ausgeschlossen
* Den Sendepuffer der SPS voll laufen lassen --> Sende hierzu ein grosses Paket (ca. 1k) alle 60ms. Das fuehrt dazu dass bei einer Verbindungsstoerung von laenger als 500ms der SPS interne Sendepuffer volllaeuft. Das erkennt der T_SEND und wirft einen Fehler. Das funktioniert bei 8k Puffergroesse mit den Werten.
Wenn der Puffer groesser oder kleiner ist, dauert es laenger oder weniger lang zum Fehler.;)
 
Zuletzt bearbeitet:
Warum soll der PC nichts senden? Wenn der PC schon aktiv die Verbindung aufbauen muß, kann er da nicht auch eine Request-Nachricht senden und die S7 antwortet immer nur auf einen empfangenen Request?
Muß denn die Verbindung vom PC aufgebaut bleiben?

Harald
 
Hallo!
Der T_CON benoetigt ja eine Projektierung ueber so eine Variable TCON_Param oder so. Welche Parameter hast Du da wie gesetzt, damit die S7 als Server agiert?
ActiveEstablished auf FALSE setzen, dann ist der Verbindungsaufbau passiv
RemotePort auf 0 setzen, sonst konnte ich mich mit einem PC nicht verbinden (lt. Siemens geht es zwischen zwei Steuerungen auch dann, wenn RemotePort und LocalPort ident sind)
LocalPort auf die Portnummer setzen, die der PC zu kontaktieren versucht

* Den Sendepuffer der SPS voll laufen lassen
Hört sich interessant an. Wie meinst du das genau? Selbst wenn ich das NW-Kabel abstecke, gibt mir der TSEND ein DONE retour worauf ich den Sendepuffer mit neuen Daten befülle. Somit kann ich diesen Überlauf ja gar nicht provozieren?!

Warum soll der PC nichts senden? Wenn der PC schon aktiv die Verbindung aufbauen muß, kann er da nicht auch eine Request-Nachricht senden und die S7 antwortet immer nur auf einen empfangenen Request?
Muß denn die Verbindung vom PC aufgebaut bleiben?
Weil die PC-Software eigentlich für einen anderen Steuerungstyp geschrieben wurde und nun nur für Siemens angepasst wird. Große Änderungen sind nicht erwünscht um die Kompatibilität nicht zu verlieren. Letztendlich soll es egal sein, welcher SPS-Typ (also welcher Hersteller) da via TCP am PC hängt.
 
Zurück
Oben