CP343-1 Lean Socket via Programm öffnen/schliessen

chrigu

Level-2
Beiträge
68
Reaktionspunkte
8
Zuviel Werbung?
-> Hier kostenlos registrieren
Habe Momentan eine funktionierende TCP/IP Verbindung von einer Cp343-1 lean zu einem PC. Der CP ist der aktive, das heisst er baut die Verbindung auf.
Nun ist es erforderlich, dass aus dem Programm heraus die Verbindung abgebrochen werden kann, und auch wieder neu aufgebaut.(Socket schliessen/öffnen) Gibt es dazu spezielle Bausteine, und ist das mit dem CP343-1 Lean überhaupt möglich?
Habe bis jetzt nur solche für die integrierte Schnittstelle gefunden.(FB65, FB66)

chrigu
 
Die CP´s egal ob lean oder normal unterstützen nur projektierte TCP/UDP Verbindungen via Net-Pro.
Diese projektierten Verbindungen werden selbständig vom Betriebssystem beim Start bzw. bei Reconnect aufgebaut.
Man kann diese projektierten Verbindungen zur Laufzeit nicht beeinflussen.

Die integrierten Ethernet-Schnittstellen (PN-CPU´s) unterstützen dagegen keine projektierten TCP/UDP Verbindungen.
Bei diesen Schnittstellen kann bzw. muss die Verbindung zur Laufzeit über FB´s (TCON, TDISCON - FB65, FB66) aufgebaut werden.
Weiterhin kann man bei den integrierten Schnittstellen dann natürlich die Verbindung zur Laufzeit auch wieder abbauen.

Mit dem CP343-1 LEAN ist dein Vorhaben also nicht möglich.

Warum willst du die Verbindung wieder abbauen ?
Das macht eigentlich nur Sinn, wenn du z.B. mit mehreren Teilnehmern kommunizieren musst, und die Anzahl der max. möglichen Verbindungen des CP´s ausgeschöpft ist - dann kann man evtl. mit Verbindungsmultiplexing tricksen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es hat mehret Gründe. Es ist so, dass wir zum Partner 2 Port's öffnen. Quasi einen zum Senden und einer zum Empfangen. (Wurde von der Gegenstelle so definiert, weil relativ viele Telegramme versendet werden) Nun möchte aber die Gegenstelle den Verbindungsaufbau so haben, dass der 1. Socket geöffnet wird, ein Initialisierungstelegramm gesendet wird, und erst anschliessend der 2. Port geöffnet wird.

Der 2. Grund, wenn Beispielsweise keine Antwort innerhalb von 160ms kommt soll der DB-Server ein Problem haben und in dem Fall muss ich die Verbindung abbrechen, und versuchen neu aufzubauen und so die Startsequenz wieder durchmachen.

Aber in dem Falle muss ich mal mit der Gegenstelle schauen ob es reicht die Initialisierung nur über Telegramme zu machen, ohne vorher die Verbindung neu aufzubauen.
 
... wenn Beispielsweise keine Antwort innerhalb von 160ms kommt soll der DB-Server ein Problem haben und in dem Fall muss ich die Verbindung abbrechen, und versuchen neu aufzubauen ...

Die S7 versucht in diesem Fall (also bei den projektierten CP Verbindungen) selber zyklisch die Verbindung wieder aufzubauen.
Selbst bei der PN-Schnittstelle und den T-Bausteinen brauchst du die Verbindung bei einem Ausfall des Partners nicht ab- und wieder aufzubauen - auch hier wird automatisch versucht die Verbindung wieder herzustellen.

Ich wüsste also nicht, warum hier zur Laufzeit Verbindungen auf- und abgebaut werden sollten.

Die Sache mit den 2 Ports kann man sich eigentlich auch sparen - damit verbraucht man nur unnötig Verbindungsressourcen (der LEAN-CP unterstützt "nur" 8 Verbindungen).


Bei den Telegrammen bitte aufpassen - am besten fixe Telegrammlängen mit dem Kommunikationspartner (Gegenstelle) aushandeln !
Der Receive-Baustein der S7 benötigt eine Längenangabe (Bytes) - der CP liefert erst dann Daten, wenn diese Anzahl in seinem Empfangspuffer erreicht bzw. überschritten ist - wurden mehr Bytes empfangen, liefert er aber auch nur soviele Bytes, wie beim Receive-Baustein anparametriert wurden - der Rest verbleibt im Empfangspuffer des CP´s - somit werden deine Empfangsdaten verschoben bzw. "zerhackt".

Wenn fixe Telegrammlängen nicht möglich sind, dann gibt es noch die Möglichkeit mittels fixem Telegrammheader und variablen nachfolgenden Nutzdaten.
Dann brauchst du 2 Receive-Bausteine im Programm, die gegeneinander verriegelt sind - der 1. Receive-Baustein empfängt dann den fixen Header und prüft gemäß der Info im Header ab, wieviele Nutzdaten noch über den 2. Receive-Baustein empfangen werden müssen.

Bei der integrierten PN-Schnittstelle kann man dem Receive-Baustein auch angeben, dass er immer die volle Empfangsdatenlänge liefert - hier sind variable Telegrammlängen also einfacher zu handeln.

Bzgl. deinen 160ms bitte ebenfalls aufpassen - bei den Ethernet-CP´s steckt der Flaschenhals im Rückwandbus der 300er CPU, der läuft nur mit MPI Geschwindigkeit.
Hier ist man mit der integrierten PN-Schnittstelle ebenfalls besser bedient.
 
Zurück
Oben