EthernetSerial Kommunikation optimieren für begrenzte Datenmenge.

vollmi

vollmi

Level-3
Power-User
Beiträge
5.848
Reaktionspunkte
1.774
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab hier ne S7-1500 dadrauf läuft eine TCP Kommunikation zu einem EthernetRS485 Wandler.
Das heisst Telegramme die ich über die TCP Verbindung schicke werden an den RS485 Port durchgereicht und viceversa.

Im programm läuft das so.
Ich habe einen TRCV_C der die Verbindung aufbaut und hält.
der TSEND sendet dann Telegramme auf die dann das Zielgerät antwortet und über TRCV_C kriege ich dann das Antworttelegramm.

Soweit sogut.
Ich schick die Telegramme üblicherweise so oft es geht. Also wenn grad keine Befehlstelegramme anstehen, überwache ich die Geräte per POLL Telegramme auf die das Gerät dann ein ACK Telegramm schickt.

Das funktioniert tip top. Jetzt kommt aber ne neue Anforderung dazu. Der EthernetRS485 Wandler soll ne SimKarte bekommen mit dem er sich in ein VPN einwählt in dem sich auch die SPS wiederfindet.
Die Simkarte soll aber auf 200MB Monatlich gedeckelt sein.

Ist ja kein Problem. Sende ich die Polls halt auch nur noch alle 5 Minuten um ein Update zu kriegen. Und wenn ein Befehl rausgeht polle ich alle paar Sekunden nochmal um die auf den Befehl folgende Statusupdates zu bekommen. An Gesendeten und empfangenen Daten komme ich dann auf 200 Byte die Stunde. über die TSEND TRECV längen addierten Daten.

Jetzt ist es ja aber so das über die TCP Transportstrecke ja noch ein TCP Header um das Serielle Telegramm gebaut wird, was das Ganze sicher grösser macht. Darum hab ich mal noch Wireshark drangehängt. Um rauszufinden wieviele mehr da generiert wird und sicherzustellen, dass die Karte dann nicht einfach trotzdem geleert wird.

hier mal ein kurzer Auszug
rot sind die Telegramme die ich effektiv schicke. das nächste Grün ist dann jeweils die Antwort.

Code: 
No.	Time	Source	Destination	Protocol	Length	Info251	07:10:42.880009	192.168.1.20	192.168.1.1	TCP	60	63354 → 48500 [RST, ACK] Seq=1 Ack=2 Win=0 Len=0
308	07:10:44.881707	192.168.1.20	192.168.1.1	TCP	60	55253 → 48500 [SYN] Seq=0 Win=8192 Len=0 MSS=1460
309	07:10:44.881788	192.168.1.1	192.168.1.20	TCP	60	48500 → 55253 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
310	07:10:44.881931	192.168.1.20	192.168.1.1	TCP	60	55253 → 48500 [ACK] Seq=1 Ack=1 Win=8192 Len=0
477	07:10:49.882835	192.168.1.1	192.168.1.20	TCP	60	48500 → 55253 [FIN, ACK] Seq=1 Ack=1 Win=29200 Len=0
478	07:10:49.883014	192.168.1.20	192.168.1.1	TCP	60	55253 → 48500 [ACK] Seq=1 Ack=2 Win=8192 Len=0
479	07:10:49.884001	192.168.1.20	192.168.1.1	TCP	60	55253 → 48500 [RST, ACK] Seq=1 Ack=2 Win=0 Len=0
532	07:10:51.885157	192.168.1.20	192.168.1.1	TCP	60	56850 → 48500 [SYN] Seq=0 Win=8192 Len=0 MSS=1460
533	07:10:51.885573	192.168.1.1	192.168.1.20	TCP	60	48500 → 56850 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
534	07:10:51.885775	192.168.1.20	192.168.1.1	TCP	60	56850 → 48500 [ACK] Seq=1 Ack=1 Win=8192 Len=0
[COLOR=#ff0000]713	07:10:56.023921	192.168.1.20	192.168.1.1	TCP	71	56850 → 48500 [PSH, ACK] Seq=1 Ack=1 Win=8192 Len=17[/COLOR]
714	07:10:56.024232	192.168.1.1	192.168.1.20	TCP	60	48500 → 56850 [ACK] Seq=1 Ack=18 Win=29200 Len=0
[COLOR=#00ff00]715	07:10:56.071276	192.168.1.1	192.168.1.20	TCP	63	48500 → 56850 [PSH, ACK] Seq=1 Ack=18 Win=29200 Len=9[/COLOR]
[COLOR=#ff0000]717	07:10:56.144048	192.168.1.20	192.168.1.1	TCP	71	56850 → 48500 [PSH, ACK] Seq=18 Ack=10 Win=8192 Len=17[/COLOR]
718	07:10:56.144151	192.168.1.1	192.168.1.20	TCP	60	48500 → 56850 [ACK] Seq=10 Ack=35 Win=29200 Len=0
[COLOR=#00ff00]719	07:10:56.191304	192.168.1.1	192.168.1.20	TCP	63	48500 → 56850 [PSH, ACK] Seq=10 Ack=35 Win=29200 Len=9[/COLOR]
720	07:10:56.333401	192.168.1.20	192.168.1.1	TCP	60	56850 → 48500 [ACK] Seq=35 Ack=19 Win=8192 Len=0
905	07:11:01.191692	192.168.1.1	192.168.1.20	TCP	60	48500 → 56850 [FIN, ACK] Seq=19 Ack=35 Win=29200 Len=0
906	07:11:01.191789	192.168.1.20	192.168.1.1	TCP	60	56850 → 48500 [ACK] Seq=35 Ack=20 Win=8192 Len=0
907	07:11:01.192518	192.168.1.20	192.168.1.1	TCP	60	56850 → 48500 [RST, ACK] Seq=35 Ack=20 Win=0 Len=0
972	07:11:03.193835	192.168.1.20	192.168.1.1	TCP	60	63887 → 48500 [SYN] Seq=0 Win=8192 Len=0 MSS=1460
973	07:11:03.194178	192.168.1.1	192.168.1.20	TCP	60	48500 → 63887 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460
974	07:11:03.194253	192.168.1.20	192.168.1.1	TCP	60	63887 → 48500 [ACK] Seq=1 Ack=1 Win=8192 Len=0
1012	07:11:04.331419	192.168.1.1	192.168.1.20	TCP	60	[TCP ACKed unseen segment] 48500 → 63887 [ACK] Seq=1 Ack=18 Win=29200 Len=0
[COLOR=#ff0000]1013	07:11:04.332133	192.168.1.20	192.168.1.1	TCP	71	[TCP Spurious Retransmission] 63887 → 48500 [PSH, ACK] Seq=1 Ack=1 Win=8192 Len=17[/COLOR]
[COLOR=#00ff00]1014	07:11:04.379225	192.168.1.1	192.168.1.20	TCP	63	48500 → 63887 [PSH, ACK] Seq=1 Ack=18 Win=29200 Len=9[/COLOR]
[COLOR=#ff0000]1016	07:11:04.453748	192.168.1.20	192.168.1.1	TCP	71	63887 → 48500 [PSH, ACK] Seq=18 Ack=10 Win=8192 Len=17[/COLOR]

Aber wie muss ich die anderen Daten Verstehen? Zählt das alles auch zu den Daten die von so einem Sim Datenpaket abgezogen wird? Das sind ja dann jeweils 200 bytes pro sekunde oder?
Wenn ja, wie könnte ich das verhindern?
 
Moin vollmi,

mit Netzwerkanalyse hab ich mich noch nicht befaßt, aber vielleicht andere Denkanstöße:
  • Warum bei heutigen GB-Flatrates auf 200MB begrenzen?
  • Ist das eine "200MB Flatrate"? Dann bedeutet das ja, daß nach dem Verbrauch der 200MB trotzdem aber noch Daten durchgehen: Nur laaaaaaangsamer. Sollte aber ja bei Deinen paar Bytes dann kein Problem sein!?
  • In welche Richtung gehen die Informationen? RS485 schickt Stati an SPS? SPS schickt Befehle an RS485? Wenn das nur Stati sind, vielleicht kann man ja dem Gateway sagen, daß er bei Statusänderung selbsttätig schickt und ansonsten nur 1x die Stunde ein Update? Also aktiver Verbindungsaufbau und Du bist nur Datensenke.
  • Hilft es was, die Verbindung von der SPS nach Erhalt der Daten abzubauen und vor jedem Abruf neu aufzubauen?
  • Ich vermute, grundsätzliches Pollen und Hintergrundrauschen wirst Du immer im Netzwerk haben. Und so lange die SPS denkt (VPN!), daß der Partner im eigenen Netzwerk hängt, wird sie das weiter machen und natürlich wird das dann zum Datenverkehr zählen. Aber wie kommst Du auf 200Byte pro Sekunde? Wenn ich auf meinem Handy VPN an habe (da wird ja der Verkehr mitgezählt), dann kommt da eigentlich nicht viel zusammen, auch wenn man Apps hat, die dann ins Heimnetzwerk telefonieren und Stati abrufen. Das sollte bei Dir noch deutlich weniger sein.

Gruß
Jens
 
Zuviel Werbung?
-> Hier kostenlos registrieren
JSEngineering schrieb:
Moin vollmi,

mit Netzwerkanalyse hab ich mich noch nicht befaßt, aber vielleicht andere Denkanstöße:
  • Warum bei heutigen GB-Flatrates auf 200MB begrenzen?
Zum Vergrößern anklicken....
Bei mir ist es mit Netzwerkanalyse eben auch noch nicht so weit her. bzw mir fehlt noch das Verständnis was für Pakete wozu sind. etc.

Da kauf der Staat halt mehrere 100 Karten mit Abo für diesen Zweck um im Feld ne RS485 Schnittstelle zu betreiben.
Da machts vermutlich schon einen Unterschied ob diese Teilnehmer das Mobilfunknetz mit Datenstreams zumachen.

  • Ist das eine "200MB Flatrate"? Dann bedeutet das ja, daß nach dem Verbrauch der 200MB trotzdem aber noch Daten durchgehen: Nur laaaaaaangsamer. Sollte aber ja bei Deinen paar Bytes dann kein Problem sein!?
Zum Vergrößern anklicken....

Das ist ein guter Punkt, das weiss ich noch gar nicht.

  • In welche Richtung gehen die Informationen? RS485 schickt Stati an SPS? SPS schickt Befehle an RS485? Wenn das nur Stati sind, vielleicht kann man ja dem Gateway sagen, daß er bei Statusänderung selbsttätig schickt und ansonsten nur 1x die Stunde ein Update? Also aktiver Verbindungsaufbau und Du bist nur Datensenke
Zum Vergrößern anklicken....
Die SPS schickt eine Anfrage und die Slaves auf dem RS485 Bus am LTE Modem antworten. Von sich aus sendet keiner dieser Slaves. Das ist gewöhnliches Single Master konzept auf RS485. Das Gateway kann von sich aus nichts an die SPS schicken, da es ja ohne stehende TCP verbindung ja keinen Partner hat die IP des Senders kann sich auch jederzeit ändern.

  • Hilft es was, die Verbindung von der SPS nach Erhalt der Daten abzubauen und vor jedem Abruf neu aufzubauen?
Zum Vergrößern anklicken....

das war auch schon mein gedanke. Nur wie? Ich will was senden. Dann bau ich ne Verbindung mit TCON auf sobald DIAG sagt Verbindung steht, geht das Telegramm raus und dann? Lass ich die verbindung offen bis eine Antwort kommt? oder bis zu einem Zeitpunkt X?
Und schliesse dann mit Discon?
Das muss ich irgendwie noch durchdenken.
 
vollmi schrieb:
[/LIST]
Das ist ein guter Punkt, das weiss ich noch gar nicht.
Zum Vergrößern anklicken....
Ich glaube, Tarife, die komplett dicht machen, gibt es garnicht...

vollmi schrieb:
[/LIST]
Die SPS schickt eine Anfrage und die Slaves auf dem RS485 Bus am LTE Modem antworten. Von sich aus sendet keiner dieser Slaves. Das ist gewöhnliches Single Master konzept auf RS485. Das Gateway kann von sich aus nichts an die SPS schicken, da es ja ohne stehende TCP verbindung ja keinen Partner hat die IP des Senders kann sich auch jederzeit ändern.
Zum Vergrößern anklicken....

Ja, kann man denn die Master-Server-Beziehung nicht umdrehen? Oder fragt eine SPS mehrere RS485-Gateways ab?
Was sind das denn für Daten? Alarme, auf die man reagieren muß oder nur historische Meßwerte? Dann könnte man die Slaveseitig ja ggf. auflaufen lassen und nur ein paar Mal am Tag komprimiert abholen.
Und wenn Du über VPN ständig verbunden bist, kann ja auch das Gateway senden.
Eventuell kannst Du auch auf UDP umstellen, um Protokoll-Overhead für die Übermittlungskontrolle abzuschalten.

vollmi schrieb:
[/LIST]
Ich will was senden. Dann bau ich ne Verbindung mit TCON auf sobald DIAG sagt Verbindung steht, geht das Telegramm raus und dann? Lass ich die verbindung offen bis eine Antwort kommt? oder bis zu einem Zeitpunkt X?
Und schliesse dann mit Discon?
Das muss ich irgendwie noch durchdenken.
Zum Vergrößern anklicken....

Verbindung offen lassen, bis Du Deine Antwort hast - länger brauchst Du die doch nicht, oder? Warum also bis Zeitpunkt X offen halten?
 
Hallo vollmi,

Bei den s7 300 gab es doch mal die Einstellung Keep Alive Telegramme für TCP Verbindungen. Dies wird es im Tia vermutlich auch noch gegeben, evtl verursachen diese die Telegramme.
bei der 300er konnte der Zeitliche Abstand eingestellt werden.

Gruß Tia
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Deine schwarzen Telegramme sind die TCP Handshakes vom Verbindungsauf- und Abbau. Ein Ethernet Frame besitzt min. 64 Bytes. Die Frame Check Sequence wird in Wireshark mit normaler Netzwerkhardware nicht erfasst, darum siehst du dort min. 60 Bytes.

Die Verbindung offen zu halten würde hier etwas Bandbreite sparen. Aber gerade bei einer Mobilfunkverbindung ist es manchmal sinnvoller, die Verbindung für jedes Telegramm neu aufzubauen und nach dem Transfer wieder zu trennen, im Besonderen wenn du nur alle paar Minuten Daten austauschen willst. Ansonsten dauert es nach dem Senden etliche Sekunden bis du dann die z.B. durch einen Verbindungsabbruch weggefallene Verbindung als nicht mehr funktionierend erkennen kannst.
 
Hallo,

für den Aufbau des VPN Tunnel werden auch Daten übertragen, die müssen auch noch mitgezählt werden.

Habe hier mal eine interessante Übersicht gefunden: https://256.insys-icom.de/VPN-Overhead vielleicht hilft die ja mit zur Abschätzung.

Zusätzlich muß Du auch noch darüber nachdenken wer die Verbindung aufbaut. Das wird ja wohl mit über das internet laufen und keine direkte Datenverbindung zu dem Gerät. Dabei muß man bedenken, daß inzwischen viele mobilen Datenverbindung keine eigene IP bekommen sondern in den mobilen Netzen auch mit NAT etc. gearbeitet wird. D.h. daß Endgerät wird wohl die Verbindung aufbauen müssen.

Gruß
 
Zurück
Oben