mit libnodave komplette Bausteine sichern

Zuviel Werbung?
-> Hier kostenlos registrieren
@ Question_mark

Also ich habe es damals mit ISO over TCP und libnodave hinuntergeschossen.

welchen Weg hast Du den Baustein up- und downgeloaded (MPI, IsoOnTCP ???), sowie die Größe des Bausteins in Byte lt. Windows Explorer und die Größe des Bausteins lt. Simatic Manager. WIe groß sind die Bausteine (in Bytes) ?


Ich glaube ich weiß was du damit sagen willst und das könnte gut sein - leider habe ich das damalige libnodaveprojekt nicht mehr.
Das wäre jetzt aber dann auch vielleicht für Zottel interessant.

Bei dem Runtergeschossenen Baustein fehlen definitiv
Autor, Version.... also all das was am Footer also am Ende des Bausteins stehen müsste. Ich weiß aber nicht ob es damals eingetragen war.???

Es könnte sein, dass beim abzug des Bausteins nicht der ganze Baustein abgezogen wurde. Und deshalb auch nur ein Teil wieder runtergeschossen wurde.

Korrigiert mich falls ich was falsches sage:

Annahme:
Je nach CP antwortet die SPS auf eine Anfrage einen Bausteinauszulesen
wie du schon sagtest entweder:

1. Nur mit einem Paket:
03 00
xx xx
02 F0
00

2. Mit 2 Paketen
03 00
xx xx
02 F0
00

03 00
xx xx
02 F0
80

Fakt:
Antwortet die SPS mit 2 Paketen, darf das erste Paket nicht mit der Funktion 1e bestätigt werden.
Das funktioniert zwar bei kurzeren Bausteinen, bei längeren wir die Verbindung jedoch dann von der SPS abgebrochen.

Vielleicht kann Zottel da weiterhelfen wie das in Libnodave realisiert wurde

Welche S7 wurde verwendet :
Es ist eine ältere, kleine 416er: 416-2XK01-0AB0.


SZL
Ich suche dringend schon seint längerem eine SZL(SSL) Dokumentation
Im Internet habe ich nur eine kurze gefunden in der die Funktion
SZL 0232 mit dem Index 04 z.B. auch garnicht enthalten ist.

Weiß jemand wo ich die herkriegen könnte (zu Siemens habe ich leider keinen direkten Kontakt)



Vielen Dank nachmal für eure Unterstützung
Gruß Tupo13
 
Tupo13 schrieb:
SZL
Ich suche dringend schon seint längerem eine SZL(SSL) Dokumentation
Im Internet habe ich nur eine kurze gefunden in der die Funktion
SZL 0232 mit dem Index 04 z.B. auch garnicht enthalten ist.

Weiß jemand wo ich die herkriegen könnte (zu Siemens habe ich leider keinen direkten Kontakt)
Im Handbuch "Standardsoftware für die S7-300/400 System- und Standardfunktionen" Kapitel 31 "Systemszustandsliste". Dort ist eine Beschreibung der aktuell dokumentierten SZLs enthalten.
 
Hallo,
Tupo13 schrieb:
Antwortet die SPS mit 2 Paketen, darf das erste Paket nicht mit der Funktion 1e bestätigt werden.
Genau richtig. Mehrere Pakete werden dann verschickt, wenn die Daten > als die ausgehandelte TPDU-Größe sind. Je nach Anzahl der Daten und ausgehandelter TPDU-Größe kann das durchaus noch mehr als 2 Pakete sein.
Die neue TPDU wird durch die o.a. Zeichenfolge gekennzeichnet. Diese ist quasi in den Nutzdaten eingebettet und muss natürlich daraus entfernt werden.
03 00 xx xx 02 F0 00 kennzeichnet, dass noch weitere TPDU's folgen.
03 00 xx xx 02 F0 80 markiert die letzte TPDU. Erst danach darf zur S7 mit Telegramm "1E" quittiert werden.

Gruß
Question_mark
 
Question_mark schrieb:
Genau richtig. Mehrere Pakete werden dann verschickt, wenn die Daten > als die ausgehandelte TPDU-Größe sind. Je nach Anzahl der Daten und ausgehandelter TPDU-Größe kann das durchaus noch mehr als 2 Pakete sein.
Die neue TPDU wird durch die o.a. Zeichenfolge gekennzeichnet. Diese ist quasi in den Nutzdaten eingebettet und muss natürlich daraus entfernt werden.
03 00 xx xx 02 F0 00 kennzeichnet, dass noch weitere TPDU's folgen.
03 00 xx xx 02 F0 80 markiert die letzte TPDU. Erst danach darf zur S7 mit Telegramm "1E" quittiert werden.
Laut Siemens ist die Bausteinschreibefunktion Layer 7 (ich sag dazu Layer 5, es gibt ja noch etwas darüber :wink: ), RFC1006 befindet sich auf Layer 4. Der L4 hat nun die Aufgabe, ein L5-Paket zu übertragen. Dies muss ggf. auf mehrere Pakete verteilt werden, wenn die L4-Paketgröße kleiner ist als die L5-Paketgröße+7 Bytes RFC-Header. Nur das letzte L4-Paket darf mit dem EOT-Flag (0x80) gekennzeichnet sein. Alte CPs bis 1EX02 haben das Problem, dass sie trotz großer L4-Paketgröße (512 oder 1024) ein L5 Paket mit 480 Bytes auf mehrere RFC-Pakete verteilen. Sie sind aber in der Lage, ein komplettes RFC-Paket auf einmal zu empfangen.
Dies hat insgesamt noch nichts mit der 0x1E zu tun. 0x1E o.a. spielen sich auf der L5-Ebene ab.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
Rainer Hönle schrieb:
Dies hat insgesamt noch nichts mit der 0x1E zu tun. 0x1E o.a. spielen sich auf der L5-Ebene ab
ja, schon. Aber Zottels LibNoDave bildet ja Layer 4 und 5 nach, oder ???
Rainer Hönle schrieb:
Alte CPs bis 1EX02 haben das Problem, dass sie trotz großer L4-Paketgröße (512 oder 1024) ein L5 Paket mit 480 Bytes auf mehrere RFC-Pakete verteilen.
Ist mir bisher noch nicht aufgefallen, da muss ich doch mal in meiner Schatztruhe nach einem alten CP suchen und das nächste Woche ausprobieren.

Gruß
Question_mark
 
@Question_mark + @Rainer Hönle

Danke für die Infos, jetzt wird es richtig interessant für mich. Ich fasse das nochmal kurz zusammen, bitte korrigiert mich falls was nicht stimmt:

- Die größe der Datenpakete ist von der CPU abhängig, der CP teilt ein solches Pakete dann je nachdem wie schnell er ist in mehrere TPDU's auf.

- 03 00 xx xx 02 F0 00 32 03 xx xx ..........
erstes TPDU (anfang des Datenpaketes)

- 03 00 xx xx 02 F0 00 es folgen noch weitere TPDU's

- 03 00 xx xx 02 F0 80 letzte TPDU des Datenpaketes. Muss beim Bausteindownload mit der Funktion "1E" Quittiert werden



Noch ein paar Fragen:
- Ist das bei 300er und bei 400er Steuerungen dasselbe (s.h. oben)?

- wie sieht es beim upload (also beim zurückspielen) aus?, woher weiß ich, wie groß ich die TPDU machen darf, bin bis jetzt immer von 462 Byte Bausteindaten ausgegangen (512). Gibt es auch CP's die das nicht können also langsamer sind?
oder was passiert bei schnelleren CP's (1024) Byte?


Vielen Dank im voraus für eure Hilfe
Gruß Tupo13
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Tupo13,
soweit richtig erkannt. Aber zur weiteren Erklärung :
Tupo13 schrieb:
woher weiß ich, wie groß ich die TPDU machen darf,
Der beim Verbindungsaufbau aktive Partner schlägt dem passiven Partner beim Connection request eine TPDU-Größe zwischen 128 und 8192 Bytes vor. Dies ist im allgemeinen immer die maximale TPDU-Größe, die der aktive Verbindungspartner aufgrund seiner Puffergröße etc. verarbeiten kann. Der passive Partner gibt im Antworttelegramm (Connection confirm) seine max. TPDU-Größe zurück. Beide Partner einigen sich immer darauf, die jeweils kleinere TPDU-Größe zu verwenden. Insofern ist es ziemlich egal, ob es sich um eine S7-300, S7-400 S5 oder sonstwas als Koppelpartner handelt. Beide müssen sich also mit der ausgehandelten TPDU-Größe korrekt verhalten.
Tupo13 schrieb:
Gibt es auch CP's die das nicht können also langsamer sind? oder was passiert bei schnelleren CP's (1024) Byte?
Aus o.a. Gründen ist das vollkommen egal, Dein Programm muss in jedem Fall richtig auf die ausgehandelte TPDU-Größe reagieren.

Gruß
Question_mark
 
Question_mark schrieb:
Der beim Verbindungsaufbau aktive Partner schlägt dem passiven Partner beim Connection request eine TPDU-Größe zwischen 128 und 8192 Bytes vor. Dies ist im allgemeinen immer die maximale TPDU-Größe, die der aktive Verbindungspartner aufgrund seiner Puffergröße etc. verarbeiten kann. Der passive Partner gibt im Antworttelegramm (Connection confirm) seine max. TPDU-Größe zurück.
Zu beachten ist, dass die TPDU-Größen 8192 und 4096 für Klasse 0 (und die kommt hier zum Einsatz) nicht zur Verfügung stehen (so steht es in der mir vorliegenden Doku). Der passive Partner gibt nicht seine maximale Größe sondern das Minimum von seiner maximalen Größe und der angeforderten Größe zurück. Dies ist dann auch die maximale Größe, mit der weiter kommuniziert wird.
 
Tupo13 schrieb:
- wie sieht es beim upload (also beim zurückspielen) aus?, woher weiß ich, wie groß ich die TPDU machen darf, bin bis jetzt immer von 462 Byte Bausteindaten ausgegangen (512). Gibt es auch CP's die das nicht können also langsamer sind?
oder was passiert bei schnelleren CP's (1024) Byte?
Hier kommt jetzt etwas durcheinander. Die Paketgröße auf RFC-Ebene hat überhaupt nichts mit der PDU-Größe der CPU zu tun. Die maximalen Größen sind vollkommen unabhängig voneinander und werden auch vollkommen separat auf unterschiedlichen Ebenen ausgehandelt. Es kann nun der Fall vorkommen, dass die L5-Paketgröße kleiner oder gleich ist als die L4-Paketgröße inklusive L4-Header. Dies ist vollkommen unkritisch, eine Aufteilung wird nicht stattfinden. Wenn die L5 Paketgröße größer ist als die L4-Paketgröße, dann muss zwangsläufig auf L4 paketiert werden. Dann (und wenn es sich um alte CPs handelt :wink: ) hat man mit der Paketierung zu kämpfen. Sehen Sie dazu auch meine Bermerkungen zu L4 und L5.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
Rainer Hönle schrieb:
Zu beachten ist, dass die TPDU-Größen 8192 und 4096 für Klasse 0 (und die kommt hier zum Einsatz) nicht zur Verfügung stehen
Grundsätzlich ist auch die Klasse verhandelbar. Ob diese im jeweiligen Partner überhaupt implementiert ist, ist eine andere Sache.
Question_mark schrieb:
Der passive Partner gibt im Antworttelegramm (Connection confirm) seine max. TPDU-Größe zurück
Uuuppss, da muss ich wohl irgendwas am Satzende vergessen haben. :oops:
Rainer Hönle schrieb:
Der passive Partner gibt nicht seine maximale Größe sondern das Minimum von seiner maximalen Größe und der angeforderten Größe zurück
Ja, so ist es richtig.

Gruß
Question_mark
 
Question_mark schrieb:
Grundsätzlich ist auch die Klasse verhandelbar. Ob diese im jeweiligen Partner überhaupt implementiert ist, ist eine andere Sache.
Stimmt, aber Siemens fängt schon mit 0 an. Und ein Aufstieg ist meines Wissens nach nicht möglich sondern nur die Einigung auf die gewünschte oder eine geringere Klasse (oder Ablehnung wenn es gar nicht passt). Und da bleiben dann nicht viel Möglichkeiten. :wink:

Grüße
Rainer Hönle
 
Also das wird mir jetzt schon fast wieder etwas zu hoch,
aber die Infos reichen mir wieder um ein paar Tage zu programmieren

vielen Dank euch beiden - echt super
@ Rainer Hönle
@ Question_mark


Eine Frage hätte ich da noch, also das erste PDU-Paket, das ich verschicke sieht so aus

1. Paket an PCU
03 00 00 16 11 E0 00 00 00 01 00 C1 02 01
00 c2 02 01 Slot c0 01 09

1.Paket von PCU (Antwort)
03 00 00 16 11 D0 00 01 44 31 00 C0 01 09
C1 02 01 00 c2 02 01 Slot




2. Paket an PCU
03 00 00 19 02 f0 80
32 01 00 00 02 00 00 08 00 00
f0 00 00 01 00 01 01 e0 -> Daten

2.Paket von PCU (Antwort)
03 00 00 1B 02 f0 80
32 03 00 00 02 00 00 08 00 00 00 00
F0 00 00 01 00 01 01 E0 -> Daten


Das sind die ersten 2 Pakete die Step7 und auch ich in meinem Programm sofort nach dem Verbindungsaufbau schicke
- leider habe ich keine Ahnung was diese bedeuten, wird vielleicht in diesen Paketen die PDU-Größe festgelegt?

Als nächstes wird von S7 die SZL abgefragt
als ersters die Funktion SZL 0132 mit dem Index 04
dann SZL 0132 Index 02
Leider steht in der Siemens Doku nichts über Index 02 und 04
wird vielleicht hier die PDU-Größe festgelegt?


Bitte entschuldigt kenne mich leider noch nicht ganz so gut aus, leider habe ich auch keinen zugriff auf Dokumentationen (außer Internet).

Würde mich freuen, wenn Ihr mir nochmal helfen könnt
Hoffe ich werde nicht lästig:

Gruß Tupo13
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tupo13 schrieb:
Eine Frage hätte ich da noch, also das erste PDU-Paket, das ich verschicke sieht so aus

1. Paket an PCU
03 00 00 16 11 E0 00 00 00 01 00 C1 02 01
00 c2 02 01 Slot c0 01 09

1.Paket von PCU (Antwort)
03 00 00 16 11 D0 00 01 44 31 00 C0 01 09
C1 02 01 00 c2 02 01 Slot


2. Paket an PCU
03 00 00 19 02 f0 80
32 01 00 00 02 00 00 08 00 00
f0 00 00 01 00 01 01 e0 -> Daten

01e0h=480. Das ist die angebotene Größe.
2.Paket von PCU (Antwort)
03 00 00 1B 02 f0 80
32 03 00 00 02 00 00 08 00 00 00 00
F0 00 00 01 00 01 01 E0 -> Daten
01e0h=480. Das ist die ausgehandelte Größe.

Libnodave schreibt an dieser Stelle in die Debug-Ausgabe: "partner offered PDU length: xxx"
 
Tupo13 schrieb:
Eine Frage hätte ich da noch, also das erste PDU-Paket, das ich verschicke sieht so aus

1. Paket an PCU
03 00 00 16 11 E0 00 00 00 01 00 C1 02 01
00 c2 02 01 Slot c0 01 09

1.Paket von PCU (Antwort)
03 00 00 16 11 D0 00 01 44 31 00 C0 01 09
C1 02 01 00 c2 02 01 Slot


2. Paket an PCU
03 00 00 19 02 f0 80
32 01 00 00 02 00 00 08 00 00
f0 00 00 01 00 01 01 e0 -> Daten

2.Paket von PCU (Antwort)
03 00 00 1B 02 f0 80
32 03 00 00 02 00 00 08 00 00 00 00
F0 00 00 01 00 01 01 E0 -> Daten


Das sind die ersten 2 Pakete die Step7 und auch ich in meinem Programm sofort nach dem Verbindungsaufbau schicke
- leider habe ich keine Ahnung was diese bedeuten, wird vielleicht in diesen Paketen die PDU-Größe festgelegt?
Volltreffer. Im ersten Paket wird die L4-Paketgröße verhandelt und im zweiten die L5-Paketgröße. Denn der L4 muss erst stehen bevor der L5 in verwenden kann :wink:. Die maximale Paketgröße auf L5 ist hier 0x01E0 = 480 Bytes.
 
Question_mark schrieb:
Bei der S7 schon, nur es gibt bei der S5 auch noch expedited data u.s.w. Aber ich glaube, das geht jetzt wirklich zu weit :wink:
Und schon wieder was gelernt. Mit ED hatte ich bis jetzt nichts zu tun (und habe auch nicht weiter die Infos gelesen :cry: ).
Und da gibt es Leute, die behaupten in diesem Forum würde das Niveau sinken und nur immer wieder die selben Themen aufgewärmt :?:
 
Zurück
Oben