Hallo,
ich möchte eine S7-416 Software-SPS mit einer S7-315 Insevis verbinden. Dazu habe ich bisher mit PUT/GET gearbeitet, allerdings reichen die Anzahl der übertragbaren Bytes für die Zukunft nicht aus.
Deshalb habe ich mich mit Tsend und Trecv beschäftigt. Ich konnte auch erfolgreich folgende Verbindung realisieren:
S7-416 Tsend (passiv) --> S7-315 Trecv (aktiv) (8192 Bytes - bestehend aus einen großen Datenbaustein)
Danach wollte ich in die andere Richtung schreiben:
S7-315 Tsend --> S7-416 Trecv (auch wieder 8192 Bytes)
Beim Beobachten des zugehörigen DB ist mir folgendes aufgefallen:
Ein Sekundenzähler, welcher in diesen DB übertragen wird, wird kurz angezeigt und danach nimmt alles wieder den Wert 0 an. Nach einer Sekunde (das ist die REQ-Zeit des Tsend) erscheint wieder kurz der zu übertragende Wert und geht bis zum nächsten REQ wieder auf 0.
Sobald ich die Anzahl unter 1470 Bytes setzte funktioniert es richtig. Mir ist jetzt allerdings unklar, woran das liegt. In die andere Richtung gehen ja auch 8192 Bytes.
In Wireshark habe ich die Daten mal beobachtet. Von der S7-315 kommen die Daten in 6 Paketen und ergeben im gesamten die 8192 Bytes Nutzdaten.
Der Trecv-Baustein scheint aber das erste Paket zu bearbeiten und in den Datenbaustein zu schreiben. Die anderen 5 Pakete innerhalb dieser Anfrage werden dann auch wieder am Anfang des DB´s geschrieben. Deshalb hab ich zwischenzeitlich auch die 0-Werte.
Die Länge bzw. Bytes an den Bausteinen steht überall auf 8192. Liegt das Problem somit am Trecv der 416er CPU?
Könnt ihr mir sagen, warum der Trecv-Baustein nicht den gesamten Datenblock mit 8192 in den DB schreibt?
Bei der 416er Software-CPU ist die CP 443-1 in NetPro konfiguriert.
Die 315er Insevis SPS hat eine eigene Software zur Netzprojektierung, prinzipjell aber ähnlich.
Den FB65 T-CON habe ich nicht verwendet. Dort gibt es aber den "Connection type", der etwas mit den 1400 Bytes bzw. 8192 Bytes zu tun hat. Liegt hier der Schlüssel zu meinen Problem?
ich möchte eine S7-416 Software-SPS mit einer S7-315 Insevis verbinden. Dazu habe ich bisher mit PUT/GET gearbeitet, allerdings reichen die Anzahl der übertragbaren Bytes für die Zukunft nicht aus.
Deshalb habe ich mich mit Tsend und Trecv beschäftigt. Ich konnte auch erfolgreich folgende Verbindung realisieren:
S7-416 Tsend (passiv) --> S7-315 Trecv (aktiv) (8192 Bytes - bestehend aus einen großen Datenbaustein)
Danach wollte ich in die andere Richtung schreiben:
S7-315 Tsend --> S7-416 Trecv (auch wieder 8192 Bytes)
Beim Beobachten des zugehörigen DB ist mir folgendes aufgefallen:
Ein Sekundenzähler, welcher in diesen DB übertragen wird, wird kurz angezeigt und danach nimmt alles wieder den Wert 0 an. Nach einer Sekunde (das ist die REQ-Zeit des Tsend) erscheint wieder kurz der zu übertragende Wert und geht bis zum nächsten REQ wieder auf 0.
Sobald ich die Anzahl unter 1470 Bytes setzte funktioniert es richtig. Mir ist jetzt allerdings unklar, woran das liegt. In die andere Richtung gehen ja auch 8192 Bytes.
In Wireshark habe ich die Daten mal beobachtet. Von der S7-315 kommen die Daten in 6 Paketen und ergeben im gesamten die 8192 Bytes Nutzdaten.
Der Trecv-Baustein scheint aber das erste Paket zu bearbeiten und in den Datenbaustein zu schreiben. Die anderen 5 Pakete innerhalb dieser Anfrage werden dann auch wieder am Anfang des DB´s geschrieben. Deshalb hab ich zwischenzeitlich auch die 0-Werte.
Die Länge bzw. Bytes an den Bausteinen steht überall auf 8192. Liegt das Problem somit am Trecv der 416er CPU?
Könnt ihr mir sagen, warum der Trecv-Baustein nicht den gesamten Datenblock mit 8192 in den DB schreibt?
Bei der 416er Software-CPU ist die CP 443-1 in NetPro konfiguriert.
Die 315er Insevis SPS hat eine eigene Software zur Netzprojektierung, prinzipjell aber ähnlich.
Den FB65 T-CON habe ich nicht verwendet. Dort gibt es aber den "Connection type", der etwas mit den 1400 Bytes bzw. 8192 Bytes zu tun hat. Liegt hier der Schlüssel zu meinen Problem?