libnodave und PDU-Größe

mabi

Level-1
Beiträge
8
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich möchte in meiner (C# .NET) Anwendung mit möglichst optimaler Geschwindigkeit Daten mit libnodave (wahlweise S7Online oder Ethernet).

Hierzu habe ich mir nun ein Konzept überlegt, wie ich meine Daten intelligent in Blöcke aufteile. Das klappt auch soweit, nur habe ich nun nirgends gefunden, wie viele Byte an Nutzdaten ich genau in ein Paket packen kann.

Die PDU-Größe kann ich mir ja mit getMaxPDULen() holen. Nun ist das aber ja die Gesamtgröße inkl. Header etc.
Bei der S7-300 habe ich gelesen, dass 22Byte für Header etc. draufgehen. Zur S7-400 habe ich nirgends einen eindeutigen Wert gefunden...ich habe aber hinweise darauf gefunden, dass es mehr ist.... ich müsste aber unbedingt den Wert wissen!
Außerdem stellt sich mir die Frage, wie es bei Read/Write-Multiple ist. Da müsste sich ja die Nutzdatengröße verringern, je mehr Items/Blöcke ich in den Request packe. Ich müsste diesen Wert genau wissen, um eine Formel aufstellen zu können, Wieviel byte ich genau in einen Request packen kann....

Kennt jemand die Werte und kann mir Weiterhelfen? Die Informationen zu PDU sind im Internet irgendie recht spärlich...

Ein weiteres Problem ist, dass ich mit getMaxPDULen() an meiner S7-315 sporadisch manchmal 240 und manchmal aber auch 256 zurückgeliefert bekomme...Weiß jemand woran das liegen könnte?!

Gruß
Markus
 
Ich kann dir das nicht sicher beantworten, Zottel ist da bestimmt der bessere Ansprechpartner. Da ich aber vor einiger Zeit ein WinCC-Problem mit Rohdatenvariablen hatte, war ich in der Hilfe zu WinCC auf folgendes gestoßen:

Code:
Rohdatenvariablen als Byte-Array dienen zur Übertragung von
Anwenderdatenblöcken zwischen WinCC und AS und hantieren nur die
Nutzdaten.

Eine Rohdatenvariable als Byte-Array wird im Kanal wie eine normale
Prozessvariable behandelt, die über Adresse und Länge des Datenbereichs
(z.B. DB 100, DW 20, Länge 40 Byte) adressiert wird.

Die Länge der Rohdaten ist auf einen zu übertragenden Datenblock begrenzt
und muss mit einer PDU (Protocol Data Unit) vollständig übertragbar sein.
Die maximale Länge der vom Kommunikationstreiber übertragbaren
Datenblöcke richtet sich nach der beim Verbindungsaufbau ausgehandelten
PDU-Länge abzüglich der Header- und Zusatzinformationen. Bei den bei
SIMATIC S7 üblichen PDU-Längen ergeben sich somit folgende maximale
Längen:

S7-300: PDU-Länge 240/480 Byte; Datenblocklänge max. 208/448 Byte; jeweils abhängig vom CPU-Typ

S7-400: PDU-Länge 480 Byte; Datenblocklänge max. 448 Byte

Vielleicht hilft dir das vorerst mal weiter.
 
ok, der overhead scheint also bei beiden 32 Byte zu sein. (in den docs von libnodave steht allerdings bei s7-300 etwas von mehr als 208 Byte, aber seis drum)

Bleibt noch die Frage, wie es sich bei einem Request mit mehreren Blöcken verhält. Weis da jemand etwas?
 
ok, der overhead scheint also bei beiden 32 Byte zu sein. (in den docs von libnodave steht allerdings bei s7-300 etwas von mehr als 208 Byte, aber seis drum)

Bleibt noch die Frage, wie es sich bei einem Request mit mehreren Blöcken verhält. Weis da jemand etwas?
22 meinst du. Oder 18. Bei mehreren Blöcken gibt es einen Overhead für das ganze Telegramm und einen anderen für jede Variable.
Um es dir genau zu sagen, muß ich auch in den Quellcode schauen und zählen. Da ich keine Lust habe, schlage ich dir vor:
Starte eine Anfrage für 5 Blöcke, z.B. 4 a 40Byte (oder 4 a 100 Byte für ne 400) und einen machst du bei jeder Anfrage länger (for-next-Schleife), bis du einen Fehler kriegst. Wenn du dasselbe mit 3 oder 4 oder 6 Blöcken machst, kannst du selbst ausrechnen, wieviel Byte Telegramm-Header und Variablenblock header haben. Ach ja, manche (alle?) CPUs hängen bei ungerader Anzahl ein 0-Byte an...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für die Antwort.

Ich meinte schon 32. Zumindest würde ich aufgrund von Ralles Antwort auf 32 schließen...und für die 400er habe ich auch an anderer Stelle schon mal etwas von 448 gelesen... Leider habe ich zur Zeit keine 400er zur Verfügung, so dass ich das nicht testen kann...
 
PDU Länge

Hallo,

mabi schrieb:
Die PDU-Größe kann ich mir ja mit getMaxPDULen() holen. Nun ist das aber ja die Gesamtgröße inkl. Header etc.

Leute, was soll die Diskussion über so einen Driss. Ein ordentlicher Protokolltreiber wie OPC-Server, AGLink etc. wickelt das für Euch unsichtbar selbsttätig ab, eine PDULength sollte ab einer gewissen Schicht im OSI Modell wirklich nicht mehr interessieren..

Rainer Hönle schrieb:
Der Header ist bei der S7-400 genau so groß wie bei der S7-300.
Rainer, ich kann förmlich sehen, wie Du bei der Antwort gegrinst hast ....
Und die Frage hat Ralle schon beantwortet.

Gruß

Question_mark
 
PDU Length

Hallo,

mabi schrieb:
bei s7-300 etwas von mehr als 208 Byte, aber seis drum)

Ist halt abhängig von der 300-er CPU, also bei der 315-er stimmt das schon, aber ab 318 sind wir schon im Bereich der 400-er CPU's, aber das hat Ralle schon in seinem Beitrag erklärt. Man muss nur genau und aufmerksam lesen.

Gruß

Question_mark

PS : Nur falls es es noch Verständnisprobleme gibt, hier das Zitat von Ralle (und er hat Recht) :
Ralle schrieb:
S7-300: PDU-Länge 240/480 Byte; Datenblocklänge max. 208/448 Byte; jeweils abhängig vom CPU-Typ
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
Leute, was soll die Diskussion über so einen Driss. Ein ordentlicher Protokolltreiber wie OPC-Server, AGLink etc. wickelt das für Euch unsichtbar selbsttätig ab, eine PDULength sollte ab einer gewissen Schicht im OSI Modell wirklich nicht mehr interessieren..
Libnodave tut das auch, wenn man die Funktion daveReadManyBytes() benutzt. Ob ein OPC Server so schlau ist, Tags optimierend zusammenzufassen und wie gut, dürfte herstellerabhängig schwanken.

Bloß mag sich einer, der sich für den darunterliegenden Driss nie interessiert hat, wundern warum 1 Byte mehr Daten plötzlich doppelt so lange dauert. Und wenn er das gewußt hätte, hätte er ja vielleicht woanders auch 2 Byte sparen können...
 
Ein Blick in das Handbuch der S7 Kommunikation ....

Hallo,

Zottel schrieb:
Libnodave tut das auch, wenn man die Funktion daveReadManyBytes() benutzt.
Ja, ich weiss. Hab es leider versäumt, darauf hinzuweisen. Mich ärgert eigentlich nur, dass manche Fragesteller sich mit der S7 Kommunikation beschäftigen wollen und nur leider nicht die Energie aufbringen, die wirklich ausführlichen Handbücher von Siemens zur Datenkommunikation durchzulesen. Oder wenigstens die Suchfunktion im Forum zu benutzen, denn das ist hier alles schon ausführlich und im Detail durchgekaut worden.

Zottel schrieb:
Ob ein OPC Server so schlau ist, Tags optimierend zusammenzufassen und wie gut, dürfte herstellerabhängig schwanken.

Zumindest für den Simatic OPC-Server kann ich eine gute und optimale Zusammenfassung der Tags bestätigen. Und bei den anderen Herstellern gehe ich jetzt auch mal davon aus, denn eigentlich bemühen sich alle Hersteller Ihre Produkte zu optimieren und ständig zu verbessern.

Ich glaube aber, der Vergleich LibNoDave und OPC-Server hinkt doch sehr stark. Das sind m.E. zwei unterschiedliche Kommunikationswege und kann man nicht direkt vergleichen (obwohl ich den Vergleich selbst angezettelt habe :oops:).

Gruß

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie kommen denn die 32 Byte Headerdaten zustande?

Ich rechne für eine Read-Anfrage:
- PDU-Header: 10 (bzw. 12 Byte, struct PDUHeader)
- Parameter, einmalig für einen Request 2 Byte
- pro Request 12 Byte (das Array pa[] in daveAddToReadRequest)

Also ich komme da auf 24 Byte, das gibt mir auch das Testprogramm testISO_TCP mit --debug=1024 aus.
 
Level ??

Hallo,

Thomas_v2.1 schrieb:
Wie kommen denn die 32 Byte Headerdaten zustande?

Die hat der Mabi mal hier reingeworfen. Vielleicht gibt er ja seine Quelle über die 32 Byte hier preis. Letztendlich als Anwender sollte Dir das mit MaxPDULength oder HeaderBytes völlig egal sein, benutze einen OPC-Server z.B. von Siemens, Softing oder Deltalogic. Oder alternativ den AGLink von Deltalogic, auch eine sehr gute und zuverlässige Lösung, besonders empfehlenswert wegen dem guten Support. Den habe ich zwar noch nicht sehr oft in Anspruch genommen, aber die Reaktionszeit und Kompetenz hat mich überzeugt.
Ok, ich kenne alle Levels des OSI Modells eigentlich ganz gut, bis runter zum Level1, aber im täglichen Alltag und zur Steigerung der Produktivität/Effektivität im beruflichen Bereich sollte man schon irgendwo ab Level4 aufsetzen und die unteren Levels den Herstellern professioneller Programmierwerkzeuge überlassen. Spart Zeit/Geld und Stress, die kann man ja dafür verwenden, die Levels 1-4 mal zu erkunden und zu erforschen.
Ich erwarte ganz einfach von einem Protokolltreiber, dass er mir die angeforderten Daten unabhängig von deren Grösse, Datenbereichen, CPU-Typ, MaxPDULength oder sonstwas liefert und will meine Energie nicht damit verschwenden, irgendwo uneffektiv im Low-Level Bereich rumzupopeln.
Also, was soll das ? Entweder ich kaufe ein Tool im Größenbereich von ca. 500,- Euro und habe die fertigen, erprobten Routinen drin. Oder bastele ein halbes Jahr (oder auch ggf. länger) an einer kostenlosen :)ROFLMAO:) Lösung rum.
Ich muss allerdings zugeben, dass ich im Alltag gerne aus Gründen der Effizienz diese fertigen Lösungen einsetze, aber manchmal mir gerne auch einen Level2 Treiber programmiere, aber nur um das ganze, was sich unter den professionellen Lösungen verbirgt, bis in das letzte Detail zu verstehen.
Denn nur daraus kann Kompetenz für einen Fachbereich entstehen.

Gruß

Question_mark
 
Zuletzt bearbeitet:
Dass ein Protokolltreiber das intern Abwickeln sollte sehe ich auch so. Aber dafür ist libnodave ja denk ich mal auch nicht da. Ich habs zwar nicht getestet, aber theroretisch kann ich es ja auch benutzen um von einem AVR 8-Bit µC mit einer SPS zu kommunizieren.

Dann habe ich im letzten Jahr eine größere Anlage mit mehreren S7400 in Betrieb genommen. Das PLS wurde von einer anderen Firma projektiert, und ich habe dann quasi das PLS mit in Betrieb genommen.
Bei diesem PLS ist es im Jahre 2008 immer noch so, dass ich die Variablen in Blöcken anlegen muss. Also wie in libnodave die Telegramme von Hand zusammenstellen. Ich konnte das auch nicht glauben, und habe mich ehrlich gesagt mit dem Hersteller etwas angelegt ob das heutzutage noch sein muss (ich musste einige Variablen verschieben, bzw. Datentypen geändert was dann im PLS ein Riesenaufwand war). Na wie dem auch sei.
Aber um zu sehen wie viel Aufwand denn in sowas drinsteckt habe ich mir auf Basis von libnodave sowas mal selber programmiert. Bei dem kann ich alle Variablen S7-like anlegen, und mein Treiber baut die Telegramme zusammen. Ist zwar sicher nicht bullet-proof, aber das sind insgesamt in C++ keine 1000 Zeilen Code.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bullet-Proof, das ist echt gut ..

Hallo,

Thomas_v2.1 schrieb:
Ist zwar sicher nicht bullet-proof, aber das sind insgesamt in C++ keine 1000 Zeilen Code.
Aber immerhin noch 800 Zeilen zuviel ...
Und wenn es nicht bullet-proof ist (schöner Ausdruck, gefällt mir :ROFLMAO:r), dann ab in die Mülltonne. Wenn meine Software nicht bullet-proof ist, stellt mir leider der Kunde die Schaltschränke mit dem Gabelstapler vor das Werkstor mit der dezenten Aufforderung zur baldmöglichsten Abholung.

Thomas_v2.1 schrieb:
Bei diesem PLS ist es im Jahre 2008 immer noch so, dass ich die Variablen in Blöcken anlegen muss.
Was heisst "in Blöcken anlegen muss" ? Etwa, dass Datenbereiche konsekutiv hintereinander liegen müssen ? Ist nicht wirklich störend, beschleunigt nur die Datentransferrate. Eigentlich normal, wer sich nicht daran hält bekommt den schwarzen Peter...Ok, wenn man sich nicht daran hält, funktioniert es trotzdem, wenn auch etwas langsamer ... Aber wer merkt das schon.

Gruß

Question_mark
 
Wenn meine Software nicht bullet-proof ist, stellt mir leider der Kunde die Schaltschränke mit dem Gabelstapler vor das Werkstor mit der dezenten Aufforderung zur baldmöglichsten Abholung.
Das war quasi ein Freizeit-Projekt. Hat auch einige Monate gedauert.
In meiner Anfangszeit war ich auch öfters der Meinung dass man einiges genausogut selber programmieren könnte. Für den professionellen Einsatz ist es aber wirklich in 95% der Fälle günstiger sich etwas fertiges zu kaufen (wenn es denn was gibt).

Was heisst "in Blöcken anlegen muss" ? Etwa, dass Datenbereiche konsekutiv hintereinander liegen müssen ? Ist nicht wirklich störend, beschleunigt nur die Datentransferrate. Eigentlich normal, wer sich nicht daran hält bekommt den schwarzen Peter...Ok, wenn man sich nicht daran hält, funktioniert es trotzdem, wenn auch etwas langsamer ... Aber wer merkt das schon.
Genau so. Es funktionierte quasi genau wie bei nodave. Ich gebe die Anfangsadresse des Blocks an, und dann jeweils den Offsets der einzelnen Variablen dazu. Ich finde zumindest dass so etwas heutzutage der Treiber erledigen muss, genau wie das Optimieren der Blöcke worum es hier ja ebenfalls geht.
Es durften in den Blöcken auch nur immer die gleichen Datentypen liegen, Real Adressen immer auf einem Vielfachen von 4 etc worin ich auch keinen Grund sehe. Das bestehende System zu erweitern oder was zu ändern ist dabei ein Riesenaufwand der mMn nicht sein müsste.
 
Hallo,


Ja, ich weiss. Hab es leider versäumt, darauf hinzuweisen. Mich ärgert eigentlich nur, dass manche Fragesteller sich mit der S7 Kommunikation beschäftigen wollen und nur leider nicht die Energie aufbringen, die wirklich ausführlichen Handbücher von Siemens zur Datenkommunikation durchzulesen. Oder wenigstens die Suchfunktion im Forum zu benutzen, denn das ist hier alles schon ausführlich und im Detail durchgekaut worden.


Hast du vielleicht einen Link für die Kommunikationshandbücher?

[OT] Bist du nicht auch in der Delphi-Praxis unterwegs? [/OT]
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Griff in das Klo ...

Hallo,

Thomas_v2.1 schrieb:
Real Adressen immer auf einem Vielfachen von 4 etc worin ich auch keinen Grund sehe. Das bestehende System zu erweitern oder was zu ändern ist dabei ein Riesenaufwand der mMn nicht sein müsste.
Da gebe ich Dir mal ein 100% ACK ...
Da hast Du leider das falsche PLS-System erwischt, einfach Pech gehabt ...

Gruß

Question_mark
 
Dafür habe ich leider keine Zeit ...

Hallo,

marcengbarth schrieb:
[OT] Bist du nicht auch in der Delphi-Praxis unterwegs? [/OT]

Eigentlich nein, ich lese zwar gerne und regelmässig mit in der Delphipraxis, aber für ernsthafte Antworten habe ich eigentlich keine Zeit, leider ...
Der Tag hat eben nur 24 Stunden, und einige dieser Stunden habe ich vorrangig für meine Freizeit reserviert, und das bleibt auch so.

Gruß

Question_mark
 
Wech mit de Driss ...

Hallo,

Thomas_V2.1 schrieb:
Ich gebe die Anfangsadresse des Blocks an, und dann jeweils den Offsets der einzelnen Variablen dazu. Ich finde zumindest dass so etwas heutzutage der Treiber erledigen muss, genau wie das Optimieren der Blöcke worum es hier ja ebenfalls geht.
Es durften in den Blöcken auch nur immer die gleichen Datentypen liegen, Real Adressen immer auf einem Vielfachen von 4 etc worin ich auch keinen Grund sehe. Das bestehende System zu erweitern oder was zu ändern ist dabei ein Riesenaufwand der mMn nicht sein müsste.
Also bei Deinem Eröffnungsfred habe ich zuerst wirklich nicht verstanden, worauf das hinauslaufen soll. Aber Du hast das ja jetzt nachgereicht, habe Dein Problem nun hoffentlich verstanden. Ich denke mal, der Hersteller deiner Visu hat mal irgendwann vor Urzeiten einen recht uneffektiven Kommunikationstreiber selbst entwickelt und du musst Dich nun mit den Mängeln abfinden. Eine Weiterentwicklung (oder gar Neuentwicklung) eines besc...enen Treibers kostet Geld und wird vom Hersteller daher nicht unterstützt. Die Forderungen an einen Treiber hast Du ja gem. obigen Zitat schon erläutert und da gebe ich Dir absolut Recht...
Mein Tip dazu, schmeiss so eine Visu raus, reduziert den Stressfaktor für die Instandhaltung ungemein...

Gruß

Question_mark
 
Zurück
Oben