Komm. Zeitverhalten TCP/IP S7 <--> C++ App

[derbenny]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich hab mal eine Frage. Schätzfrage eher.
Es geht darum dass ein Kunde seine Kommunikation zwischen Leitrechner und Maschine deutlich schneller machen will. Folgender Plan:

Leitrechner sendet über Ethernet (TCP/IP) eine XML-Nachricht an eine C++ Applikation auf einem IPC (Client-Server Verbindung). Diese wird dort gegen eine xsd validiert und geparsed, die Daten in S7 Format gewandelt. Der Dateninhalt wird dann als kompletter S7-DB (ca 3500 BYte) ebenfalls per TCP/IP an eine 319er CPU geschickt über PN-IO (mit TSEND/TREC).

Jetzt die Preisfrage: Wie lange dauert das etwa?

 

[Question_mark]

Das kann man doch nicht so pauschal beantworten

Hallo,

ein Kunde seine Kommunikation zwischen Leitrechner und Maschine deutlich schneller machen will.

Den Wunsch kann ich verstehen, welcher Kunde will das nicht ?

[QUOTE="derbenny]eine XML-Nachricht an [/QUOTE]

Aber dann ist XML der völlig falsche Weg. Da entsteht ein Datenaufkommen über den Transportweg, der genau dem eigentlichen Ziel zur schnelleren Kommunikation entgegen steht.

Also besser immer nur Rohdaten in möglichst großen Paketen übertragen, aber nicht den XML-Ballast in die Kommunikation einbinden.

Jetzt die Preisfrage: Wie lange dauert das etwa?

Kann ich nicht ganz exakt sagen, kommt darauf an, ob jemand den RJ45 Stecker an der Baugruppe abgezogen hat oder nicht ..
Oder ob euer Netz 10MB oder 1000MB kann, inclusiver aller am Datentransport beteiligten Komponenten (NIC, CPs, Switches etc.).

Habe ich jetzt den ersten Preis gewonnen :?:

Gruß

Question_mark

 

[derbenny]

Zuviel Werbung?
-> Hier kostenlos registrieren

Am XML kann man leider nichts ändern, die ganze Linie ist so aufgebaut mit vielen Prozessanlagen. Dass das Konzept absoluter Mist ist sehen die inzwischen auch mehr oder weniger ein, können aber nichts daran ändern.

Es ist ein 100MBit Netz mit voraussichtlich einem Switch.

 

[Question_mark]

Die XML Basis bremst, daran kannst Du nichts mehr ändern

Hallo,

Am XML kann man leider nichts ändern,

Wenn man die Ursache für die erhebliche Kommunikationslast nicht beseitigen kann, bleibt das Problem eben unlösbar, so einfach ist das Leben.
Ein vor einiger Zeit geschaffenes Problem durch die Entscheidung für XML (warum springen die Leute eigentlich immer auf jeden neuen Hype auf ?) ist die Ursache für die hohe Kommunikationslast. Und wenn man daran nichts ändern kann, so muss man eben damit Leben. So ist das nun mal ...
Also entweder XML raus und gegen handliche Rohdatenpakete ersetzen, oder vergiss es einfach.

Hast Du schon mal z.B. bei einem OPC-Server Rohdatenpakete gegen XML Pakete verglichen ? Da werden Dir die Augen übergehen, aber XML war mal ein tolles Modewort für Ahnungslose mit einer Tendenz zu neuen Schlagwörtern.

Wobei ich anmerken muss, das XML natürlich grundsätzlich seine Berechtigung hat, aber wenn man eine Kommunikation auf XML-Basis schneller machen will (oder muss), da hat man eine schlechte Ausgangsbasis

Gruß

Question_mark

 

[Question_mark]

???

Hallo,

die ganze Linie ist so aufgebaut

mit voraussichtlich einem Switch

"Ist so aufgebaut" und "mit voraussichtlich einem Switch", ist es nun so aufgebaut oder nur so geplant, gedacht oder was ???

Gib einfach noch ein paar Infos ...

Gruß

Question_mark

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

@QM
Woher meinst du in diesem Fall den XML-Overhead beurteilen zu können, obwohl du die Beschreibung seiner Struktur garnicht kennst?

 

[Question_mark]

Wat soll dat denn nun ?

Hallo,

obwohl du die Beschreibung seiner Struktur garnicht kennst?

Und warum sollte ich die Beschreibung der XML Struktur nicht kennen ?
Und wie genau kennst Du mich, um beurteilen zu können, ob ich die XML Struktur kenne ?

Irgendwie kann ich Dir jetzt nicht ganz folgen, mach doch einfach ganz weiter mit Deinen Mutmassungen ...

Gruß

Question_mark

 

[vierlagig]

@QM
Woher meinst du in diesem Fall den XML-Overhead beurteilen zu können, obwohl du die Beschreibung seiner Struktur garnicht kennst?

der XML-"overhead" beträgt immer ein vielfaches des eigentlichen nutzdaten ... IMMER! einfach schroot das ganze, aber ini bekommste mittlerweile fast gar nicht mehr etabliert...

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

der XML-"overhead" beträgt immer ein vielfaches des eigentlichen nutzdaten ... IMMER! einfach schroot das ganze, aber ini bekommste mittlerweile fast gar nicht mehr etabliert...

Wieso immer?
Es sollen ja 3500 Bytes aus einem DB gelesen werden. Man könnte dann auch nur ein XML-Element machen, welches den kompletten DB z.B. Base64 codiert überträgt. Dann habe ich nur den XML overhead für die Deklaration und ein einzelnes Element + 137% im ungünstigsten Fall für die Base64 Codierung.
Es kann ja auch sein dass in dem DB der SPS nur Textdaten stehen, dann brauche ich nichtmal zu codieren. Aber das hat der OP eben alles noch nicht geschrieben.

Ich sage ja nicht dass XML das Beste der Welt ist, aber wenn eine Siemens SPS im Spiel ist, ist normalerweise diese Stelle der Flaschenhals. Aber das gilt es zu überprüfen, und solche Pauschalaussagen wie "XML bäh" helfen da auch nicht weiter.

 

[vierlagig]

Wieso immer?
Es sollen ja 3500 Bytes aus einem DB gelesen werden. Man könnte dann auch nur ein XML-Element machen, welches den kompletten DB z.B. Base64 codiert überträgt. Dann habe ich nur den XML overhead für die Deklaration und ein einzelnes Element + 137% im ungünstigsten Fall für die Base64 Codierung.
Es kann ja auch sein dass in dem DB der SPS nur Textdaten stehen, dann brauche ich nichtmal zu codieren. Aber das hat der OP eben alles noch nicht geschrieben.

na klar, und genau deswegen wird xml verwendet, weil man die daten eigentlich auch ohne dem ganzen kram hätte versenden können - das glaubste doch selber nicht, gib es zu!

 

[Thomas_v2.1]

na klar, und genau deswegen wird xml verwendet, weil man die daten eigentlich auch ohne dem ganzen kram hätte versenden können - das glaubste doch selber nicht, gib es zu!

Ich glaubs nicht, ich weiß es aber nicht.

Ich weiß aber, dass 3500 Bytes, und nehmen wird jetzt mal den 10 fachen Overhead, also 35.000 byte für 100 Mbit Ethernet ein Witz ist. 3500 Bytes aus einer SPS z.B. über S7-Kommunikation zu popeln dauert allerdings relativ lange, hat er hier aber nicht. Ich würde darum prüfen, wie schnell die TSEND/TRECV Bausteine in der SPS arbeiten.

 

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nee Thomas, das akzeptiere ich nicht ...

Hallo,

Ich sage ja nicht dass XML das Beste der Welt ist, aber wenn eine Siemens SPS im Spiel ist, ist normalerweise diese Stelle der Flaschenhals. Aber das gilt es zu überprüfen, und solche Pauschalaussagen wie "XML bäh" helfen da auch nicht weiter.

Nein, in jedem Fall ist XML der Flaschenhals. Punktum ...

Ich habe vorher schon angedeutet, dass XML einen gewaltigen Overhead mitschleppt, so kann also ein im Rohdatenpaket übertragenes Wort eben nur zwei Bytes belegen oder je nach Konfiguration des XML-Paketes auch einige hundert Bytes belegen. Und aus der Nummer kommt niemand heraus, so einfach ist das.

Wie schon oben geschrieben, XML hat für manche Sachen durchaus seine Berechtigung, aber nicht mehr im Hinblick auf eine geschwindigkeitsoptimierte Kommunikation, da ist der Sack einfach zu . Und fertig ..

Gruß
Question_mark

 

[Question_mark]

Thomas, werde mal wach ..

Hallo,

Ich würde darum prüfen, wie schnell die TSEND/TRECV Bausteine in der SPS arbeiten.

Kannst Du ja gerne prüfen, und stelle bitte nach der Prüfung neue und schnellere TSEND/RECV hier im Forum ein. Der User "derbenny" ist dann sehr glücklich

Gruß

Question_mark

 

[Question_mark]

Thomas, lese doch noch mal von vorne durch

Hallo,

dass 3500 Bytes, und nehmen wird jetzt mal den 10 fachen Overhead, also 35.000 byte für 100 Mbit Ethernet ein Witz ist.

Und dann möchte ich gerne mal die Ausgangsfrage vom TE wiederholen : wie lange dauert das etwa ?

Die Geschwindigkeit der Kommunikation soll erhöht werden, das war die Vorgabe. Ergo neue Preisfrage :

Was geht schneller : 3500 Bytes oder 35000 Bytes zu übertragen ?

Was meinst Du dazu, kannst Du das ausreichend beantworten ?

Gruß

Question_mark

 

[pvbrowser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich auch meinen Senf dazu geben soll ...

Warum baut Ihr nicht eine Benutzer definierte TCP Verbindung auf und
sendet die Daten am Ende des SPS Zyklus, wenn sich die Daten geändert haben ?

In die andere Richtung kann der PC quasi gleichzeitig Ausgaben senden.
TCP ist ja schon dafür verantwortlich eine gesicherte Kommunikation ohne Datenverlust zu gewährleisten.

Dabei würde man sich den schlechten PING der S7 Abfragen sparen (request/response). Man braucht also gar kein request/response.