TIA TCON Verbindung S7-1500

Kleidukos

Level-1
Beiträge
16
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hey,

ich wollte mich mal erkundigen wie viele Verbindungen pro TCON möglich sind ?
Kann ich pro TCON immer nur eine Verbindung aufbauen oder gehen auch mehrere, z.b. wenn ich drei CPUs (slave) mit einer CPU (master) verbinden möchte, brauche ich für den Master 1 oder 3 TCON Bausteine ?

Mit freundlichen Grüßen
Kleidukos
 
Eine Verbindung pro TCON. Du musst auch noch schauen, wie viele Verbindungen deine CPU überhaupt zulässt. 3 sollten aber kein Problem sein.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
TCON baut keine Verbindungen auf, sondern registriert nur dynamisch die Verbindungs-Beschreibung/Projektierung im System. Und das immer nur für eine Verbindung. Sollen mehrere Verbindungen registriert werden, dann für jede Verbindung ein eigener TCON-Aufruf. Der Fehlerstatus von TCON sollte ausgewertet werden, darüber wird z.B. mitgeteilt, wenn die maximale Anzahl von Verbindungen bereits eingerichtet wurde.
 
TCON baut keine Verbindungen auf, sondern registriert nur dynamisch die Verbindungs-Beschreibung/Projektierung im System. Und das immer nur für eine Verbindung. Sollen mehrere Verbindungen registriert werden, dann für jede Verbindung ein eigener TCON-Aufruf. Der Fehlerstatus von TCON sollte ausgewertet werden, darüber wird z.B. mitgeteilt, wenn die maximale Anzahl von Verbindungen bereits eingerichtet wurde.
Danke das war sehr aufschlussreich. Das heißt um zu prüfen ob die CPUs noch eine "Verbindung" haben müsste ich ein packet/daten senden und prüfen ob die auch wieder bei der ausgangs CPU ankommen. Liege ich da richtig ?
 
Danke das war sehr aufschlussreich. Das heißt um zu prüfen ob die CPUs noch eine "Verbindung" haben müsste ich ein packet/daten senden und prüfen ob die auch wieder bei der ausgangs CPU ankommen. Liege ich da richtig ?
Falls es dir um den Status des Datenversands geht: den bekommst du über die Ausgangsparameter von TCOn (DONE/ERROR/STATUS) mit oder mit weiteren Funktionen =>T_DIAG.
Natürlich kannst du auch einfach einen INT im Kreis schicken, der bei jeder "Runde" inkementiert wird ¯\(°_o)/¯
Damit bekommst du dann aber nur ein "Kommunikation läuft ja/nein" ohne weitere Infos wieso nicht...
Was die max. Anzahl an Verbindungen angeht, steht in der Hilfe:
1693373648356.png

Im Datenblatt steht dann Beispielsweise bei der S7-1516F-3 PN
1693373963462.png


Online kannst du in der Netzsicht auch sehen wer sonst noch was für eine Verbindung gerade in deiner Anlage unterhällt:
1693374156547.png


Für alles weitere empfehle ich die TIA-Hilfe mit den Programmbeispielen zu den "T..." Bausteinen:
1693374465446.png
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Falls es dir um den Status des Datenversands geht: den bekommst du über die Ausgangsparameter von TCOn (DONE/ERROR/STATUS) mit oder mit weiteren Funktionen =>T_DIAG.
Natürlich kannst du auch einfach einen INT im Kreis schicken, der bei jeder "Runde" inkementiert wird ¯\(°_o)/¯
Damit bekommst du dann aber nur ein "Kommunikation läuft ja/nein" ohne weitere Infos wieso nicht...
Was die max. Anzahl an Verbindungen angeht, steht in der Hilfe:
Anhang anzeigen 71147

Im Datenblatt steht dann Beispielsweise bei der S7-1516F-3 PN
Anhang anzeigen 71148


Online kannst du in der Netzsicht auch sehen wer sonst noch was für eine Verbindung gerade in deiner Anlage unterhällt:
Anhang anzeigen 71149


Für alles weitere empfehle ich die TIA-Hilfe mit den Programmbeispielen zu den "T..." Bausteinen:
Anhang anzeigen 71150
Danke, aber da gibt es etwas das ich noch nicht ganz verstehe mit dem TCON Baustein, wenn ich den REQ Input von 0->1 schalte wird Busy 1, erst beim zweiten mal 0->1 wird Done 1. Soll das so sein ?

Mit REQ steigende flanke starte ich einen Auftrag, soweit habe ich das verstanden.
 
Danke, aber da gibt es etwas das ich noch nicht ganz verstehe mit dem TCON Baustein, wenn ich den REQ Input von 0->1 schalte wird Busy 1, erst beim zweiten mal 0->1 wird Done 1. Soll das so sein ?

Mit REQ steigende flanke starte ich einen Auftrag, soweit habe ich das verstanden.
Vergesst das, hab meinen Fehler gefunden...
 
Falls es dir um den Status des Datenversands geht: den bekommst du über die Ausgangsparameter von TCOn (DONE/ERROR/STATUS) mit oder mit weiteren Funktionen =>T_DIAG.
Natürlich kannst du auch einfach einen INT im Kreis schicken, der bei jeder "Runde" inkementiert wird ¯\(°_o)/¯
Damit bekommst du dann aber nur ein "Kommunikation läuft ja/nein" ohne weitere Infos wieso nicht...
Was die max. Anzahl an Verbindungen angeht, steht in der Hilfe:
Anhang anzeigen 71147

Im Datenblatt steht dann Beispielsweise bei der S7-1516F-3 PN
Anhang anzeigen 71148


Online kannst du in der Netzsicht auch sehen wer sonst noch was für eine Verbindung gerade in deiner Anlage unterhällt:
Anhang anzeigen 71149


Für alles weitere empfehle ich die TIA-Hilfe mit den Programmbeispielen zu den "T..." Bausteinen:
Anhang anzeigen 71150
T_Diag braucht aber relativ lange bis sich im Status der State von 0x04 nach 0x02 wechselt und umgekehrt. Ich soll das ganze so umsetzen das es möglichst Echtzeit basiert funktioniert.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
T_Diag braucht aber relativ lange bis sich im Status der State von 0x04 nach 0x02 wechselt und umgekehrt. Ich soll das ganze so umsetzen das es möglichst Echtzeit basiert funktioniert.
Ja, was bedeutet denn "Echtzeit"? Dazu muss ja irgendeine Information gesendet und wieder empfangen werden. Dies muss ja zyklisch geschehen, kann also bei azyklischem Datenverkehr nicht über die Sende-/Empfangsdaten geschehen.
Bleibt nur, dass das System die Verbindung abfragt. Das macht T_Diag. Wie soll das schneller geschehen?
 
um zu prüfen ob die CPUs noch eine "Verbindung" haben müsste ich ein packet/daten senden und prüfen ob die auch wieder bei der ausgangs CPU ankommen. Liege ich da richtig ?
Ja, ein toggelndes Lebensbit oder ein inkrementierender Sendezähler ist die einfachste Variante, um zu sehen, ob die Verbindung noch "lebt". Der eine Kommunikationspartner toggelt/erhöht den Sendewert, wenn er die Antwort erhalten hat, und der andere Partner sendet den Wert unverändert zurück. So kann man auch die Kommunikationsgeschwindigkeit messen.
 
T_Diag braucht aber relativ lange bis sich im Status der State von 0x04 nach 0x02 wechselt und umgekehrt. Ich soll das ganze so umsetzen das es möglichst Echtzeit basiert funktioniert.
Jo.. Echtzeit.. wenn das so ein kritisches System ist, dass eine TCP Verbindung in "Echtzeit" abgefragt werden muss.. Ein Handshake ist vollkommen ausreichend.. zum überprüfen der Verbindung und was ist "relativ lange"?
 
Ja, ein toggelndes Lebensbit oder ein inkrementierender Sendezähler ist die einfachste Variante, um zu sehen, ob die Verbindung noch "lebt". Der eine Kommunikationspartner toggelt/erhöht den Sendewert, wenn er die Antwort erhalten hat, und der andere Partner sendet den Wert unverändert zurück. So kann man auch die Kommunikationsgeschwindigkeit messen.
Das setzt aber einen zyklischen Datenaustausch voraus. Wir senden nicht zyklisch, sondern ereignisgetriggert und die Ereignisse können viele Sekunden bis hin zu Minuten auseinander liegen. Da nutzen wir den T_DIAG um zeitnah zu diagnostizieren, ob die Verbindung noch aufgebaut ist. Für unseren Partner (idR ein PC-basiertes System) gibt es dann entweder Quittungen für die empfangenen Daten oder es werden "Lebenstelegramme" gesendet. Diese aber idR nur alle 30s.
 
Das setzt aber einen zyklischen Datenaustausch voraus.
Man muß das Lebensbit bzw. den Nachrichtenzähler nicht zyklisch senden. Es reicht auch, wenn man den nur als Handshake/Empfangsbestätigung nur beim Senden eines Telegramms erhöht und mitsendet und schaut, daß die Zeit nicht zu lange dauert, bis der gleiche Wert zurückgesendet wurde. Das ist so simpel und genial und man merkt nach weniger als einer Sekunde, daß irgendwas nicht in Ordnung ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man muß das Lebensbit bzw. den Nachrichtenzähler nicht zyklisch senden. Es reicht auch, wenn man den nur als Handshake/Empfangsbestätigung nur beim Senden eines Telegramms erhöht und mitsendet und schaut, daß die Zeit nicht zu lange dauert, bis der gleiche Wert zurückgesendet wurde. Das ist so simpel und genial und man merkt nach weniger als einer Sekunde, daß irgendwas nicht in Ordnung ist.
Ja, genau. Es muss nicht zyklisch sein (danke für den Hinweis!), aber es braucht eine direkte Bestätigung (bei uns die Quittungstelegramme).
 
Zurück
Oben