TCP zu langsam

[Kahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo ,

ich schreibe über TCP Daten in die SPS DB's dabei stellt sich raus, das es sehr langsam geht.

Ich verwende die NoDaveLib auf einem HochleistungsPC Auch über andere TCP Interfaces
dauert es mir zu lange 200 Bytes in 50ms zu senden und abzuholen.

Gibt es eine HighSpeed SPS mit extra schneller TCP Anbindung es ist eine 317-2 DP , externes CP343-1 LEAN TCP Modul

Danke für Hinweise

 

[Jochen Kühner]

Jo, du musst auf der sps eine tcp verbindung einrichten und daten mit agrecieve empfangen, das geht schneller...

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die aktuelle 317-2 PN/DP ist wesentlich schneller als die Kommunikation über die Lean-CP.
Noch eine Frage: Wie werden die Daten genau geschrieben? Einzelne Variablen in einzelnen Aufträgen, einzelne Variablen in einem Auftrag oder ein Bytepuffer am Stück?

 

[Kahn]

Hallo Reiner,

ich schreibe ~200 bytes im Stück raus, muß aber vorher einen DWERT lesen, um das Handshake zu checken das ich mit dem SPS-Mann ausgehandelt habe..

Was man sich wünscht sind Übertragungszeiten um die ~10ms , denn solange braucht die SPS ca für eine Runde..

Also danke für den Tip 317-2 PN/DP Das ist eine mit TCP neben dem MPI Anschluss ? Da schau ich sogleich.

Gruß
k.

 

[Kahn]

Hallo Jochen,

wie meinst Du das ?

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber darauf achten, dass es die 6ES7317-2EK14-xxxx ist, die ist wirklich schnell.
Jochen meint, dass Du auf natives TCP/IP wechseln und in der SPS mit T_SEND bzw. T_RECEIVE (oder ähnlichen Bausteinen) arbeiten sollst.

 

[Kahn]

Danke sehr,

http://support.automation.siemens.c...objaction=csview&extranet=standard&viewreg=WW


Das umginge das Modbusprotokoll, das ja via nodave.lib in etwa zum Zuge kommt.

thx

 

[Rainer Hönle]

Genau die.
In libnodave steckt kein Modbus-Protokoll drin sondern RFC1006. Einfach libnodave verwenden wie bisher nur die schnellere Kommunikation einsetzen.
Ich schätze einmal, dass damit die 10 msec fast erreicht werden können.

 

[uncle_tom]

Zuviel Werbung?
-> Hier kostenlos registrieren

bei deiner 317-2 DP mit CP343-1 LEAN steckt der Flaschenhals im Rückwandbus der 300er - der läuft mit MPI-Geschwindigkeit (187,5 kBit).

Bei den PN-CPU´s entfällt dieser Flaschenhals dank der Onboard Ethernet-Schnittstelle.

 

[Kahn]

Okay,
Dank!

 

[mnuesser]

bei deiner 317-2 DP mit CP343-1 LEAN steckt der Flaschenhals im Rückwandbus der 300er - der läuft mit MPI-Geschwindigkeit (187,5 kBit).

Bei den PN-CPU´s entfällt dieser Flaschenhals dank der Onboard Ethernet-Schnittstelle.

aber auch nur bei den neueren mit der einfachen CPU Breite, die alten mit der doppelten Breite (hab grad keine nummer zur hand) sind auch nur an den Rückwandbus gekoppelt intern.

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auch die breite Version (EK13 und älter) ist über PN schon deutlich schneller als über externe CP. Deshalb gehe ich davon aus, dass die interne Anbindung nicht an den Rückwandbus gekoppelt ist.

 

[mnuesser]

Auch die breite Version (EK13 und älter) ist über PN schon deutlich schneller als über externe CP. Deshalb gehe ich davon aus, dass die interne Anbindung nicht an den Rückwandbus gekoppelt ist.

kann sein dass die dafür den mpi anschluß vorne geopfert haben, der ist ja nicht an den rückwärtigen bus gekoppelt. hatten mal das problem dass ein opc-server die daten nicht schnell genug abfragen konnte,
sind dann auf die neuen 315-2 PN/DP mit einfacher breite umgestiegen und die war flott wie sau

 

[shadowdb]

Die "externen CP343" sind grotten lahm. Die Kommunikation wird da über den Rückwandbus (auf ca. 1Mbit, IMHO?) ausgebremst.
MAcht keinen Spass mit denen, ist viel zu lahm.
Wie angesprochen agreceive ist fixer, aber löst das eigentliche Problem der externen CP343 nicht.

Mehr Tempo bekommst erst mit einer CPU, die Ethernet "on Board" hat, sprich bei welcher der Kommunikationskram nicht über den Rückwand I/O Bus muß.

Direkt mit der CPU reden ... nicht mit dem Nachbarn ... bist die Notiz an der Tür hängt vergeht Zeit,
mehr fällt mir da nicht ein.

Ich hab für diese Fälle gern die Vipa Cpus genommen, z.B.:
315-4NE12

http://www.vipa.de/nc/de/produkte/system-300s/cpus/?tx_sbinclude_pi1[page]=315-4NE12.html

oder die "original" CPU317F-2PNDP (ist aber guten tausi teuerer als der Vipa-kollege, ohne CP343 Lean "onboard".

Euer Schatten

PS: Nachtrag
Es kann auch sein, das Du auf ein anderes Protokoll ausweichen musst, die PN Cpus kennen alle "Open Communication", da geht dann auch via UDP, Latenz und Ovberhead freier. Die Blockgröße der Kommunikation legt auch richtig zu. Die CP343 extern sind auf die typischen 240 Byte Blöcke begrenzt.

 

[erdmann]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe gerade eine neue 6ES7317-2EK14 im Einsatz. Die ist wirklich schnell.
Ich muss dort grössere Mengen Daten aus der CPU auslesen und habe
das jetzt erstmal über direkte UDP- Verbindung auf der integrierten Schnittstelle realisiert.
TUSEND / TURCV auf der S7 und ganz normales UDP send und receive
auf der PC- Seite, maximale Telegrammlänge 1472 Byte.
Erfahrungen:
Die Antwortzeit der S7 liegt bei etwa 2ms, es lassen sich Daten mit etwa 300kByte/s
übertragen.
Mit längerem AWL- Zyklus lässt sich ein Telegramm alle zwei AWL- Zyklen realisieren.

mfg
Erdmann

 

[shadowdb]

Die neue 6ES7317-2EK14 steckt hier auch im Test-Modell.
Die ist echt rasant im TCP/IP.

Genauso fix war auch die VIPA 315-4NE12
Die ist nur erheblich preiswerter und kann IMHO deutlich mehr. Vorteizudem, ein CP343-1 Lean ist opn Board am schnellen internen Bus, hängt den externen CP343-1 deutlich ab.

Euer Schatten