Step 7 TCON Baustein und dauerhafte/ persistente Verbindung

A

avatter

Level-1
Beiträge
9
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich verstehe den TCON Baustein von Siemens nicht wirklich.

Wie lange soll eine TCP Verbindung (mit TCON, TSEND, TREC, TCLOSE) dauern? Sekunden, Minuten, Stunden, Tage, Monate, Jahre?

Normalerweise würde ich wie folgt vorgehen:

- Verbindung öffnen
- Anfrage senden
- Antwort erhalten
- Verbindung schließen

- Verbindung öffnen
- 2. Anfrage senden
- 2. Antwort erhalten
- Verbindung schließen

.....

Ich würde eine Verbindung nie länger als über eine kurze (Minutenlange) Session gehen lassen.
Schon wegen der vielen Stati die das TCP-Protokoll abgefangen haben will.

Auch wenn man für den Verbindungsau etwas länger braucht, kommt man immer in einen klar definierten Status (Closed oder Established).
Den Watchdog kann man sich unter Umständen somit komplett sparen.

Warum arbeitet man bei der SPS mit permanenten Verbindungen?
Die Performanz kann es doch nicht wirklich sein. Auch sollte die Last im Kommunikationsbaustein entstehen und nicht in der SPS.

Was verstehe ich da gerade nicht?

Gruß
 
avatter schrieb:
Aber so permanent kann dass nicht sein, sonst würde man den Ping (Watchdog) nicht senden!....
Zum Vergrößern anklicken....

Ein Ping, ist üblicherweise kein Watchdog. Die SPS kann einen Ping noch beantworten auch wenn die CPU ansich auf Stop ist.
Ein Watchdog überwacht neben der Verbindung auch ob die CPU noch rennt. Dafür müssen aber regelmässig Daten ausgetauscht werden.

Natürlich kann man eine Verbindung auch für jedes Telegramm aufbauen und dann wieder abbauen. Aber ein Verbindungsaufbau und Abbau dauert ihre Zeit. Stattdessen kann man die Verbindung auch stehen lassen (dann kann die CPU auch dafür sorgen das sie stehenbleibt) und jederzeit Senden und empfangen.
Btw. Empfangen geht ja sowieso nur wenn die Verbindung auch steht und bereit für den Empfang für daten ist, wie soll also das Programm wissen wann Daten kommen? Wenn der Empfang nicht auf einer Stehenden Verbindung auf Daten wartet?

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DeltaMikeAir schrieb:
???

Vielleicht erzählst du einmal, was du damit sagen möchtest.
Zum Vergrößern anklicken....

Ich hole mal weiter aus:

TCP hat mindestens 9 verschiedene Stati pro Verbindungsseite.
Im Idealfall sollte der Verbindungsstatus beim Sender und Empfänger auf "ESTABLISHED" stehen.

Nun ist die Welt nicht immer ideal. Es gibt EMV, Router, Switches, etc. die (zeitweise) fehlerhaft arbeiten.
Dann ist es unter Umständen mit den Schutzmechanismen von Ethernet (32 bit Checksum ) vorbei.
IP bildet entsprechend seiner Aufgabe die Checksum nur über den Header und nicht über die Daten.
Die Checksum von TCP ist schwach (16 Bit). Die Wahrscheinlichkeit liegt dann bei ca. 0,001% dass ein Fehler nicht erkannt wird. Bei 50% Fehlerquote der Pakete ist das viel.

Nun versucht man mit allen Mitteln und Konsequenzen die Verbindung auf Status "ESTABLISHED" zu belassen.
Das ergibt eine Pseudo-Sicherheit. Denn auch wenn die Verbindung "ESTABLISHED" ist kann der Stecker im schlechtesten Fall schon 30 Sekunden getrennt sein. Für einen (Echtzeit-)Not-Aus ist so ein Szenario z. B. überhaupt nicht zu gebrauchen.

Ich habe es nachgemessen: Die Verbindung wird alle 29 bis 30 Sekunden gepingt damit der Timeout nicht anschlägt,
Der Status ist auf "ESTABLISED", aber die Verbindung kann trotzdem zeitweise abgerissen sein.

Der Watchdog arbeitet normalerweise in Zeiten wo die CPU wenig oder gar nicht belastet ist. Weiss ich wie stark die Belastung der Komponenten in 30s ist? Nein!!! Ok Belastung ist erst mal gering.

Der TCP-Verbindungsaufbau dauert im schlechtesten Fall 6 ms ohne weitere Belastung der restlichen SPS. (OK für die SPS ist das mind. 1 Zyklus.)

Was machen wir da? Die SPS ist mit Sicherheit keit Echtzeitsystem! Ich frage mich nicht mehr wo so mancher Fehler herkommt...
 
Zuletzt bearbeitet:
Du hast hier viele Probleme in einen Topf geworfen:
1. Meines Wissens wird alle 30s ein TCP-Paket gesendet, um die Verbindung zu halten, und auch nur, wenn keine andere Kommunikation stattfindet. Ein Ping könnte das nicht, da anderes Protokoll (ICMP), er enthält auch keine Session-ID usw.
2. Ein entsprechend dimensionierter Watchdog erlaubt auch die Erkennung kürzester Verbindungsabbrüche (einige ms), sowas wird z.B. prinzipiell bei Profinet und erst recht Profisafe gemacht.
3. Das Senden des (von dir gebauten) Watchdogs darf mit der Auslastung der CPU nichts zu tun haben, sonst nützt er dir nichts. Er kann aber so gebaut sein, daß er nur in Übertragungspausen gesendet wird.
4. Die Eigenschaft der TCON-Bausteine, die Verbindung selbstständig zu halten bzw. wiederaufzubauen erspart dir viel Programmierarbeit, die du in anderen SPS-Systemen hast.
5. TCP ist ein grundlegendes Protokoll auf dem Sessionlayer, auf dem die meisten sicheren Protokolle aufbauen. Diese implementieren dann eben zusätzliche Prüfsummen u.ä. auf einem höheren Layer. (OSI-Modell)
6. Siemens stellt mit der LCom-Bibliothek eine Software kostenlos zur Verfügung, die so ziemlich alle deine Anforderungen erfüllen dürfte. (Außer NotAus über TCP, aber das ist eine Aufgabe für Profisafe!): Konfigurierbarer Watchdog, Prüfsumme über die Daten usw. Ich habe sie selbst im Einsatz, läuft auch zwischen 300er und 1500er Systemen, letztere allerdings erst ab V2.5.x!
7. Was ist ein Echtzeitsystem? Wenn die 1ms von Profinet nicht reichen, gibt es noch andere Lösungen, die dann mit Zeitstempeln in den EAs arbeiten. Die schnellste und unkomplizierteste Verbindung zwischen SPSen bei Siemens ist übrigens i-Device. Aber auch hier kann es natürlich Gründe geben, die dagegen sprechen (muß in der Hardware konfiguriert werden z.B.)
 
Ingmar64 schrieb:
Du hast hier viele Probleme in einen Topf geworfen:
1. Meines Wissens wird alle 30s ein TCP-Paket gesendet, um die Verbindung zu halten, und auch nur, wenn keine andere Kommunikation stattfindet. Ein Ping könnte das nicht, da anderes Protokoll (ICMP), er enthält auch keine Session-ID usw.
2. Ein entsprechend dimensionierter Watchdog erlaubt auch die Erkennung kürzester Verbindungsabbrüche (einige ms), sowas wird z.B. prinzipiell bei Profinet und erst recht Profisafe gemacht.
3. Das Senden des (von dir gebauten) Watchdogs darf mit der Auslastung der CPU nichts zu tun haben, sonst nützt er dir nichts. Er kann aber so gebaut sein, daß er nur in Übertragungspausen gesendet wird.
4. Die Eigenschaft der TCON-Bausteine, die Verbindung selbstständig zu halten bzw. wiederaufzubauen erspart dir viel Programmierarbeit, die du in anderen SPS-Systemen hast.
5. TCP ist ein grundlegendes Protokoll auf dem Sessionlayer, auf dem die meisten sicheren Protokolle aufbauen. Diese implementieren dann eben zusätzliche Prüfsummen u.ä. auf einem höheren Layer. (OSI-Modell)
6. Siemens stellt mit der LCom-Bibliothek eine Software kostenlos zur Verfügung, die so ziemlich alle deine Anforderungen erfüllen dürfte. (Außer NotAus über TCP, aber das ist eine Aufgabe für Profisafe!): Konfigurierbarer Watchdog, Prüfsumme über die Daten usw. Ich habe sie selbst im Einsatz, läuft auch zwischen 300er und 1500er Systemen, letztere allerdings erst ab V2.5.x!
7. Was ist ein Echtzeitsystem? Wenn die 1ms von Profinet nicht reichen, gibt es noch andere Lösungen, die dann mit Zeitstempeln in den EAs arbeiten. Die schnellste und unkomplizierteste Verbindung zwischen SPSen bei Siemens ist übrigens i-Device. Aber auch hier kann es natürlich Gründe geben, die dagegen sprechen (muß in der Hardware konfiguriert werden z.B.)
Zum Vergrößern anklicken....

Zu 1.: Ich glaube da habe ich mich missverständlich ausgedrückt. Ein U-Boot kann auch ein Ping aussenden. Ich meinte damit ein TCP-Kontrollpaket, kein 'ICMP. Sorry!

Zu 2.: Ist das dann ein permanentes Polling?

Zu 3.: Ich meinte die CPU und nicht die Verbindung.

Zu 4.: Connect / Close ist viel Programmierarbeit?

Zu 5.: TCP hat keepalive erst ab Version 1 bekommen soweit ich mich erinnern kann. Eine Session sollte dann auch nur so kurz wie möglich gehalten werden...

Zu 6.: Danke! Die LCom-Bibliothek werde ich mir mal anschauen. Gehört Profisafe zu industrial Ethernet oder doch eher zu Profi-Net? Für ältere Systeme 315, 316, 317 kommt das wohl eher nicht in Frage!

Zu 7: Wie kann Profi-Net 1 ms brauchen wenn ein SYN-Paket schon 3 ms braucht? Arbeitet ihr mit 1 bis 10 Gbit Netzwerk? Ich sehe momentan nur 100 Mbit Netzwerke (Industial Ethernet).

Vielen Dank für die ausführlichen Antworten!!!!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du sprichst über TCP, das ist weder Profinet noch Echtzeit. Damit kann man auch keine sicherheitsrelvanten Aufgaben erfüllen, dazu ist dann Profisafe da und die HArdware + Protkoll erfüllt die entsprechenden Anforderungen.
Für wichtige zeitkritische Dinge kann man z.B. auch per Profisafe Daten austauschen, entweder direkt oder per PN/PN-Koppler. Das geht natürlich nur mit Geräten, die Profisafe beherrschen.

P-S. 20ms sind auch Echtheit, wenn es immer 20ms sind, das Ganze also determiniert ist.
 
Zuletzt bearbeitet:
Noch eine Frage zum Komponententest: Wie testet man einen Server (passiv Connect) wenn eine permanente Verbindung zwischen zwei Komponenten besteht sobald man das System einschaltet? Am offenen Herzen?
 
Zuletzt bearbeitet:
Ralle schrieb:
Du sprichst über TCP, das ist weder Profinet noch Echtzeit. Damit kann man auch keine sicherheitsrelvanten Aufgaben erfüllen, dazu ist dann Profisafe da und die HArdware + Protkoll erfüllt die entsprechenden Anforderungen.
Für wichtige zeitkritische Dinge kann man z.B. auch per Profisafe Daten austauschen, entweder direkt oder per PN/PN-Koppler. Das geht natürlich nur mit Geräten, die Profisafe beherrschen.

P-S. 20ms sind auch Echtheit, wenn es immer 20ms sind, das Ganze also determiniert ist.
Zum Vergrößern anklicken....

Ist das so?

Und wenn nicht? (Wenn ich den Stecker herausziehe und einige Sekunden später wieder hineinstecke?)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@avatter:
- Industrial Ethernet (u.a. TCP) -> Profinet -> Profisafe
- Profisafe funktioniert auch mit 300er CPUs
- Profinet ist konfigurierbar bis 1ms, praktisch habe ich das noch nicht gemacht
- Profinet läuft im Betriebssystem der CPU, also außerhalb des Zyklus
- "Zu 3.: Ich meinte die CPU und nicht die Verbindung." Ich weiß nicht, worauf du raus willst.
- Arbeit macht nicht Connect/Close sondern das Abfangen der verschiedenen Fehlermöglichkeiten, warum dann nicht was fertiges nehmen?
- ja ein Watchdog ist permanentes Polling nach Zeitraster
- Komponententest: Ich verstehe das Problem nicht, die Verbindung kann doch abgebaut werden oder am Aufbauen gehindert werden, was soll eigentlich getestet werden?

Ich weiß auch nicht so recht, wo eigentlich dein Problem ist. TCon nutzt TCP und hat damit alle Eigenschaften davon geerbt. Dies kann man durch aufgesetzte Protokolle in gewissem Maße verbessern. Reicht das nicht, muß man nach anderen Lösungen suchen. Es gibt auch andere Systeme, die mehr Echtzeitfähigkeit versprechen, wobei etliche das mit Zeitstempeln erreichen bis dahin, der Ausgangsbaugruppe einen Auftrag zu schicken "schalte den Ausgang um xx:xx:xx,xxxxxx Uhr"
Und kein nichtdediziertes System kann garantieren, zu einer bestimmten Zeit soundsoviel Ressourcen zu haben, das können nur dedizierte oder völlig überdimensionierte. Das einfachste dedizierte System ist eine direkte Punkt-zu-Punkt-Verbindung, z.B. ein Schaltdraht zur Übertragung eines Signals.
 
(Wenn ich den Stecker herausziehe und einige Sekunden später wieder hineinstecke?)

Das ist eine Unterbrechung, da muß dein Programm damit umgehen können. Bei Profisafe führt das Überschreiten eines gewissen Antwortzeit eben deshalb zum Stillstand der Anlage.
 
Ralle schrieb:
Du sprichst über TCP, das ist weder Profinet noch Echtzeit. Damit kann man auch keine sicherheitsrelvanten Aufgaben erfüllen, dazu ist dann Profisafe da und die HArdware + Protkoll erfüllt die entsprechenden Anforderungen.
Für wichtige zeitkritische Dinge kann man z.B. auch per Profisafe Daten austauschen, entweder direkt oder per PN/PN-Koppler. Das geht natürlich nur mit Geräten, die Profisafe beherrschen.

P-S. 20ms sind auch Echtheit, wenn es immer 20ms sind, das Ganze also determiniert ist.
Zum Vergrößern anklicken....


Ja, so sehe ich das auch! Ich muss halt auch nur anwenden was schon da ist. Alledings würde ich Echtzeit mit 30s ansetzen! ;-)
 
Ingmar64 schrieb:
@avatter:
- Industrial Ethernet (u.a. TCP) -> Profinet -> Profisafe
- Profisafe funktioniert auch mit 300er CPUs
- Profinet ist konfigurierbar bis 1ms, praktisch habe ich das noch nicht gemacht
- Profinet läuft im Betriebssystem der CPU, also außerhalb des Zyklus
- "Zu 3.: Ich meinte die CPU und nicht die Verbindung." Ich weiß nicht, worauf du raus willst.
- Arbeit macht nicht Connect/Close sondern das Abfangen der verschiedenen Fehlermöglichkeiten, warum dann nicht was fertiges nehmen?
- ja ein Watchdog ist permanentes Polling nach Zeitraster
- Komponententest: Ich verstehe das Problem nicht, die Verbindung kann doch abgebaut werden oder am Aufbauen gehindert werden, was soll eigentlich getestet werden?

Ich weiß auch nicht so recht, wo eigentlich dein Problem ist. TCon nutzt TCP und hat damit alle Eigenschaften davon geerbt. Dies kann man durch aufgesetzte Protokolle in gewissem Maße verbessern. Reicht das nicht, muß man nach anderen Lösungen suchen. Es gibt auch andere Systeme, die mehr Echtzeitfähigkeit versprechen, wobei etliche das mit Zeitstempeln erreichen bis dahin, der Ausgangsbaugruppe einen Auftrag zu schicken "schalte den Ausgang um xx:xx:xx,xxxxxx Uhr"
Und kein nichtdediziertes System kann garantieren, zu einer bestimmten Zeit soundsoviel Ressourcen zu haben, das können nur dedizierte oder völlig überdimensionierte. Das einfachste dedizierte System ist eine direkte Punkt-zu-Punkt-Verbindung, z.B. ein Schaltdraht zur Übertragung eines Signals.
Zum Vergrößern anklicken....

Ich suche gerade meine "Best Practices" heraus was die SPS-Welt betrifft.
Also ich arbeitete mal mit SPS da war an Ethernet noch nicht zu denken. Was mich ein bissl nervt ist dass alles genauso wie im Internet/auf dem PC ist; nur halt ganz anders.

Das fängt schon mit der Client Port Adresse an. Normalerweise ist die größer 1024 und variable. OK, bei der SPS ist es halt fest.
Wie bereits erwähnt habe ich eine Internet-Verbindung noch nie länger als über eine Session geöffnet. Un das machte nie Probleme bzw. zusätzlichen Aufwand. Vielmehr konnte ich auf diese Weise stabilere Software schreiben die sich vom Aufwand her in Grenzen hielt. Jedes Client Programm auf dem PC schliesst die Verbindung bevor es beendet wird automatisch.

Ich denke echte "Echtzeitübertragung" erreicht man wie bereits beschrieben nur mit einem direkten Kabel (z.B. für den Notaus). Alles andere führt zu einer enormen Erhöhung des Datenverkehrs (extrem schnelles Polling) und erreicht nie die Signallaufzeiten eines direkt angeschlossenen Kabels.

Profisafe hört sich jetzt richtig gut an, da hier alle Werte mit einer Checksum versehen werden. Damit lassen sich alle genannten Fehlermöglichkeiten weitgehend eliminieren. Ob da Polling im Spiel ist konnte ich bislang nicht herausfinden. (Polling ist immer die schlechtere Alternative....) :-(

Ob man größere Datenmengen mit Profisafe übertragen soll/kann bleibt auszutesten. Ich denke da an Messergebnis-Daten die nahe an die max. Übertraqgungsrate von 12 MByte (100 Mbit) gehen. So wie ich las hat man da mit 30% zusätzlicher Redundanz zu rechnen.

Zu Connect/Close: Auch wenn man die Verbindung öffnet und schliesst ist der Baustein schon fertig programmiert. ;-)

zum Watchdog: s.o. Polling

zum Komponententest: Eine Turbine wird auch erst mal getestet bevor sie nach einer Reparatur wieder für den Flugbtrieb zugelassen wird. (Beispiel) Somit könnte man bestimmte Funktionen vorab oder im Betrieb testen.

Danke für die Antworten!!!!
 
Moin avatter,

avatter schrieb:
Wenn ich etwas nicht brauche, dann packe ich es nicht weg. "TDISCON" ist zum Verwenden vor dem kontrollierten Herunterfahren gedacht?
Zum Vergrößern anklicken....

TDISCON (disconnect) ist zum Abbauen einer Verbindung
TCON ist zum Aufbauen einer Verbindung
TRCV ist zum Empfangen von Daten bei einer aufgebauten Verbindung
TSEND ist zum Senden von Daten bei einer aufgebauten Verbindung
T_DIAG ist für die Diagnose einer Verbindung

In TIA gibt es jetzt TRCV_C und TSEND_C. C steht für connection.
Damit kann man den Umfang der Programmierung reduzieren. Wichtig ist dabei, dass es das *_C nur einmal pro Verbindung gibt:

TRCV_C + TSEND
oder
TRCV + TSEND_C

Des weiteren gibt es jetzt vorgefertigte Parameterstrukturen (für UDP TCP_on_UDP, TCP mit IPv4 usw.).

VG

MFreiberger
 
avatter schrieb:
Ich denke echte "Echtzeitübertragung" erreicht man wie bereits beschrieben nur mit einem direkten Kabel (z.B. für den Notaus). Alles andere führt zu einer enormen Erhöhung des Datenverkehrs (extrem schnelles Polling) und erreicht nie die Signallaufzeiten eines direkt angeschlossenen Kabels.
Zum Vergrößern anklicken....

Naja, ein echtes Kabel auf dem SPS Rack ist vermutlich gleich schnell wie ein Kabel auf einem RemoteIO 100m Weit weg. Denn Kommunikationszyklus für PNIO überschreitet den CPU Zyklus normalerweise sowieso. Kriegste also eh erst beim nächsten Programmzyklus mit.
Es seidenn du arbeitest mit Interrupts. Aber auch da dürfte es keine grosse Rolle spielen wo das Kabel angeschlossen ist.
 

Similar threads

M
TIA S7-1500 Modbus TCP Verbindung mit Fremdgerät
2
Antworten
21
Aufrufe
9K
MaNuE
M
M
TIA SIMATIC S7 - OUC Verbindung/ Kommunikation zu Dashboard Server (Universal Robot UR10e)
Antworten
4
Aufrufe
4K
Mogli
M
N
TIA TCP/IP SPS <-> Roboter (bidirektional)
Antworten
1
Aufrufe
5K
PN/DP
PN/DP
P
TIA 1500er -> 1200er: ISO-on-TCP Verbindung ist elend langsam
Antworten
15
Aufrufe
5K
Hoffy
H
A
TCON erkennen ob Verbindung besteht
Antworten
7
Aufrufe
10K
Superkater
S
Zurück
Oben