TIA TRCV_C: Daten aus anderem Subnetz empfangen / Fehler 80C4

[Sali]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo.
Ich will via Send/Receive mit einem Server/Leitrechner in einem anderen Subnetz kommunizieren, was laut Siemens-Support kein Problem sein sollte.

Mein X2-Port:
IP: xxx.xxx.77.40 Subnetzmaske 255.255.255.0
Router verwenden: ja --> Router Adresse xxx.xxx.77.1 (Firmennetz)

IP-Adresse mit der Send/Receive kommunizieren soll: xxx.xxx.67.10 (anderer Server/Leitrechner)
Port Send: 2001, ID: 1/ Port Receive: 2000, ID: 2
ConnectionType: 11 (TCP/IP)

TSEND_C funktioniert ohne Probleme, TRCV_C zeigt kurz 7006 (Daten werden gerade empfangen),
dann 80C4:

Temporärer Kommunikationsfehler: Die Verbindung kann derzeit nicht aufgebaut werden. Die Verbindung kann nicht aufgebaut werden, weil auf dem Verbindungsweg liegende Firewalls für die benötigten Ports nicht freigeschaltet sind. Die Schnittstelle empfängt gerade neue Parameter oder die Verbindung wird gerade aufgebaut. Die projektierte Verbindung wird gerade von einer Anweisung "TDISCON" entfernt. Die benutzte Verbindung wird gerade durch einen Aufruf mit COM_RST = 1 beendet

Wenn das Masquerading das Problem ist, was muss ich dann an der CPU einstellen, oder geht das nur mit einem Scalance dazwischen?

 

[PN/DP]

TSEND_C funktioniert ohne Probleme, TRCV_C zeigt kurz 7006 (Daten werden gerade empfangen),
dann 80C4

Verwende für TRCV_C ---> TRCV (ohne _C). Nur eine der beiden Anweisungen TSEND und TRCV darf sich um den Verbindungsaufbau kümmern und die _C Erweiterung haben. Oder verwende TSEND und TRCV und explizit TCON.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Verwende für TRCV_C ---> TRCV (ohne _C). Nur eine der beiden Anweisungen TSEND und TRCV darf sich um den Verbindungsaufbau kümmern und die _C Erweiterung haben. Oder verwende TSEND und TRCV und explizit TCON.

Hinweis dazu:
Das "C" an den Bausteinen von TRCV_C und TSEND_C steht für Connection. Da hat SIEMENS den TCON und T_DIAG in die Bausteine TSEND und TRCV integriert. Damit spart man sich ein oder zwei Bausteinaufrufe.
M.E. ist es aber etwas unübersichtlicher. Ist es denn soooo schlecht vier eindeutige Bausteine (TRCV, TSEND, TCON und T_DIAG) aufzurufen?
Ich finde es auch nicht besonders klar, wenn der STATUS die Informationen von drei Bausteinen enthält.

TCON ist nötig für das Registrieren der Verbindung im Betriebssystem (oder TRCV_C oder TSEND_C). Das muss eigentlich nur einmalig beim CPU-Start erfolgen.

T_DIAG ist nicht unbedingt notwendig, aber sinnwoll. Er sollte regelmäßig (vielleicht 1s) getriggert werden.

TRCV holt empfangene Informationen aus dem Puffer ab. Sollte ständig aktiv sein. Wenn neue Daten vorhanden sind, meldet er das.

TSEND triggert man, wenn man senden möchte. Entweder ereignisgetriggert, z.B., wenn Telegramme gesendet werden sollen. Oder in einem schnellen Intervall (nicht zu klein, weil der Baustein azyklisch arbeitet), wenn man ständig Signale austauschen will/muss.

 

[PN/DP]

M.E. ist es aber etwas unübersichtlicher. Ist es denn soooo schlecht vier eindeutige Bausteine (TRCV, TSEND, TCON und T_DIAG) aufzurufen?

Jaaa, die ..._C Anweisungen wurden wohl für TIA-Anwender eingeführt, die lieber komplett fertige Bausteine ohne viel Logik drumrum einsetzen wollen. Speziell bei der Verwendung der ..._C Anweisungen muss der Anwender aber doch noch ein ganz kleines bisschen mitdenken. Ich benutze die nie, sondern immer explizit TCON + TSEND + TRCV (manchmal + TDISCON). TDIAG habe ich noch nie gebraucht.

 

[MFreiberger]

TDIAG habe ich noch nie gebraucht.

Damit zeige ich auf dem HMI einen Text an, ob die Verbindung aufgebaut ist oder woran es liegt, dass sie nicht aufgebaut ist:

STATUS = 1: Verbindung ist abgebaut.
STATUS = 2: Der aktive Verbindungspunkt versucht, die Verbindung zum remoten Kommunikationspartner aufzubauen.
STATUS = 3: Der passive Verbindungspunkt wartet auf den Verbindungsaufbau des remoten Kommunikationspartners.
STATUS = 4: Verbindung ist aufgebaut.
STATUS = 5: Die Verbindung wird gerade abgebaut.