# mit libnodave komplette Bausteine sichern



## Tupo13 (6 Dezember 2005)

Hallo, 

weiß jemand ob es möglich ist - Bausteine die ausgelesen wurden wieder in die SPS zu schießen?

Also mein vorhaben ist:
Ich möchte eine komplette Sicherungen aller Bausteine auf einer SPS machen. Das funktioniert mit Libnodave einwandfrei.

Das Problem ist jetzt, wie bekomme ich die Bausteine wieder in die SPS?

Das Test-Programm funktioniert ja leider meistens nicht. SPS stoppt...

@Zottel
Ich habe mit dir ja vor eineigen Monaten schon einmal darüber geredet.
Damals meintest du, dass das alles noch etwas experimentiell ist - aber du daran Arbeitest.
Gibt es/oder wird Libnodave in nächster Zeit Funktionen zur Verfügung stellen, welche es ermöglichen Bausteine wieder in die SPS zu schießen?


Vilen Dank im voraus
Gruß Tupo13


----------



## Zottel (6 Dezember 2005)

Tupo13 schrieb:
			
		

> Ich habe mit dir ja vor eineigen Monaten schon einmal darüber geredet.
> Damals meintest du, dass das alles noch etwas experimentiell ist - aber du daran Arbeitest.
> Gibt es/oder wird Libnodave in nächster Zeit Funktionen zur Verfügung stellen, welche es ermöglichen Bausteine wieder in die SPS zu schießen?
> Gruß Tupo13


Wie ich damals sagte, sind ja Testprogramme dabei, die zurückschreiben. Das "experimentell" bezieht sich auf folgendei Dinge:
1. Sieht der Code zum Zurückschreiben momentan bei verschiedenen Protokollen verschieden aus und dazu sehe ich eigentlich keinen Grund :-(
2. Müssen SDBs in einer bestimmten Reihenfolge geschrieben werden. Das wird nie völlig zu klären sein, da neue Modelle vielleicht neue SDBs (z.B. für Profinet) einführen können.
3. Fehlt noch eine Funktion zur Speicherkomprimierung.
Punkt 3 werde ich mal angehen. Dann gehe davon aus: Wenn es für dich mit einer bestimmten HW-Konfiguration funktioniert, wird es mit dieser Konfiguration immer funktionieren.


----------



## Tupo13 (6 Dezember 2005)

@ Zottel

Danke für deine schnelle Antwort.

Leider funktioniert es mit deinem Testprogramm nicht. Ich zerschieße mir da jedesmal das ganze Projekt. Die SPS bekomme ich dann erst nach dem Urlöschen wieder zum laufen. (416 2DP).

Ich greife über Ethernet auf die SPS zu. Es muss aber absolut zuverlässig sein. Das Testprogramm ist also für diesen zweck nicht zu gebrauchen.

Wist du in nächster Zeit (in 2 Monat Diplomarbeitabgabe) daran noch etwas ändern?


Falls nicht, dann muss ich mir das irgendwie selber zusammenschustern.  Damit habe ich auch bereits angefangen:
Ich verwende die pcap.h - der 3-way-Handshake ... funktioniert schon.

Nur habe ich leider keine Ahnung, wie der Rest aussehen muss.
Hast du da vielleicht irgendwelche Infos...
Wäre dir sehr sehr dankbar

Gruß Tupo13


----------



## Question_mark (7 Dezember 2005)

Hallo Tupo13,


			
				Tupo13 schrieb:
			
		

> Ich verwende die pcap.h


Kann man mit pcap wirklich Pakete (egal ob TCP/IP, ISO, ISO on TCP) versenden. Ich hab immer gedacht, dass damit nur ein sniffen möglich ist ??
Übrigens, der OPC-Server von Siemens (Simatic.Net) und auch die S7-SAPI.DLL können problemlos Bausteine von der S7 lesen b.z.w. schreiben.

Gruß
Question_mark


----------



## Tupo13 (8 Dezember 2005)

Ja mit pcap.h kann man pakete verschicken.
Allerdings musst du dir die Pakete selber zusammenbauen - Checksummen, Längen.... Byte für Byte - du kannst so also jedes protokoll verwenden.

Wenn du unter Windows programmierst kann es allerdings sein, dass der Kernel dir manchmal dazwischen Funkt

Gruß Tupo13


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Leider funktioniert es mit deinem Testprogramm nicht. Ich zerschieße mir da jedesmal das ganze Projekt.


Bei welcher Aktion? Welchen Baustein schreibst du?



> Wist du in nächster Zeit (in 2 Monat Diplomarbeitabgabe) daran noch etwas ändern?


Eher nein. Ich habe auch keine 4xx zum Testen.



> Ich verwende die pcap.h - der 3-way-Handshake ... funktioniert schon.
> der 3-way-Handshake


Keine Ahnung, was der 3-way-Handshake ist...


> Nur habe ich leider keine Ahnung, wie der Rest aussehen muss.
> Hast du da vielleicht irgendwelche Infos...


Nein. Du kannst nur in den Quellcode schauen oder die debug-Ausgabe von Libnodave mit dem vergleichen, was PG und S7 miteinander "reden".


----------



## Tupo13 (8 Dezember 2005)

@ Zottel

Danke für deine Antwort

Angenommen ich nehme den OB1 in dem nichts drin steht oder den DB1 in dem zwei Integer sind. - Es hat noch nie funktioniert.

Einmal musste ich dann auch eine neue Firmware einspielen, weil es nach dem Ürlöschen die Bausteine auf der Steuerung (die ich natürlich wieder runtergeschossen habe) nicht mehr angezeigt hat obwohl sie da waren




> Eher nein. Ich habe auch keine 4xx zum Testen.


Funktioniert es denn bei einer 300?




> Keine Ahnung, was der 3-way-Handshake ist...


Der Drei-Wege-Handshake baut die Verbindung auf 
Syn an die SPS
Syn und Ack von Sps
Ack an SPS
Das macht bei dir glaube ich initialize




> Nein. Du kannst nur in den Quellcode schauen oder die debug-Ausgabe von Libnodave mit dem vergleichen, was PG und S7 miteinander "reden".


Na ja das mache ich ja auch, aber es sind ja um die 120 Pakete die pro Baustein hinundhergeschickt werden. Es fällt mir sehr schwer das nachzubilden wenn ich nichteinmal weiß was an welche Stelle... muss.

Dachte du hast da vielleicht schon was- egal werde mich mal hinsetzen und versuchen ob ich dahinter komme - Melde mich dann falls ich was rausbekomme


Gruß Tupo13


----------



## Rainer Hönle (8 Dezember 2005)

Das Schreiben von Bausteinen ist in der Tat etwas aufwändiger. Was ist denn genau Thema bzw. Aufgabe der Diplomarbeit? 
Hintergrund der Frage: Ein kostenloses Backup-Tool gibt es für die 300er von mhj. Wir bieten im diesem Bereich unser Backup/Restore an. Dieses Tool sichert die SPS in ein originales S7-Projekt. Und kann S7-Projekte, inklusive aller SDBs, in der richtigen Reihenfolge der Bausteine, auch wieder zurückspielen. Das Ganze ist über Kommandozeile parametrierbar und kann somit in (fast) jede Windows-Applikation eingebunden werden.


----------



## Tupo13 (8 Dezember 2005)

Das Thema ist ein Backup Programm für S7 300/400 zu erstellen
(Allerdings ohne S7 Treiber)

Mit dem Simatic OPC Server funktioniert das ganze ja eigentlich recht gut.

Was steht denn eigentlich in den SDB's ? Wozu dienen die ?
Steht da die Hardware drinn?

Ich habe bis jetzt nur  DB,FB,FC und OB abgezogen

Gruß Tupo13


----------



## Rainer Hönle (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Was steht denn eigentlich in den SDB's ? Wozu dienen die ? Steht da die Hardware drinn?


Richtig. Dort steht die Hardwarekonfiguration, Netzkonfiguration, Verbindungen etc. drin. Ohne diese ist eine nackte SPS nicht zum Leben zu erwecken.


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Funktioniert es denn bei einer 300?


Ja. Außer wenn man SDBs in falscher Reihenfolge einspielt oder wenn der Speicher nicht reicht. Über TCP/IP habe ich allerdings nur mit einer VIPA Speed7 getestet und das ist schon eine Weile (ca. 1 Jahr?) her.
Du probierst es immer noch mit reinem ISO??


> Der Drei-Wege-Handshake baut die Verbindung auf
> Syn an die SPS
> Syn und Ack von Sps
> Ack an SPS
> Das macht bei dir glaube ich initialize


SYN und ACK klingt aber nach TCP. Bei ISO over TCP macht das wohl das Betriebssystem, wenn ein socket geöffnet bzw. connect() aufgerufen wird.



> Nein. Du kannst nur in den Quellcode schauen oder die debug-Ausgabe von Libnodave mit dem vergleichen, was PG und S7 miteinander "reden".


Na ja das mache ich ja auch, aber es sind ja um die 120 Pakete die pro Baustein hinundhergeschickt werden.
Also PDUs (Pakete der S7-Kommunikation sind es für einen kurzen Baustein nur einige wenige:
PG an SPS: Ich will dir den Baustein OB1 mit der Länge 123 schicken (Funktionscode 0x1A)
SPS an PG: ok
SPS an PG: gib mir den Anfang (Funktionscode 0x1B)
PG an SPS: Anfang vom Baustein + Kennung, ob noch mehr folgt
Falls noch was folgt SPS an PG: gib mir mehr (Funktionscode 0x1B)
PG an SPS: Fortsetzung Baustein + Kennung, ob noch mehr folgt
Falls nix mehr folgt SPS an PG: ok, laden beendet  (Funktionscode 0x1C)
PG an SPS: Übernimm den Baustein ins Programm (Funktionscode 0x28 +Schlüsselwort _INSE)
Das müßtest du irgendwie auch in der Kommunikation PG<->SPS wiederfinden. Sonst lade mal einen kurzen OB1 und schick mir die mitgeschnittenen Pakete.


----------



## Tupo13 (8 Dezember 2005)

@ Zottel Danke

Also ich verwende TCP/IP - kein ISO over TCP

Wie verschickst du denn in libnodave deine Packete?

Ich habe dir dann noch die aufgezeichneten Pakete OB1
geschickt

Gruß Tupo13


----------



## Zottel (8 Dezember 2005)

> Also ich verwende TCP/IP - kein ISO over TCP


Wie das? Welche Port-Nummer?


> Wie verschickst du denn in libnodave deine Packete?


Ganz normal, per write auf ein verbundenes socket...


----------



## Tupo13 (8 Dezember 2005)

> Wie das? Welche Port-Nummer?



Wie libnodave auch benutze ich den Port 102 der SPS.
Mein Sourceport ist ein zufälliger der über 10000 liegt.

Momentan verschicke ich jedes Paket einzeln, ich berechne die Checksummen selber, zähle die Sequenznummern hoch...

aber so wie es aussieht werde ich dann wohl auch auf sockets umsteigen müssen

Hast du meine email bekommen?

Gruß Tupo13


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Wie libnodave auch benutze ich den Port 102 der SPS.


Also ist es ISO over TCP.


> Mein Sourceport ist ein zufälliger der über 10000 liegt.


Das ist normal.


> Momentan verschicke ich jedes Paket einzeln, ich berechne die Checksummen selber, zähle die Sequenznummern hoch...


Eine Quälerei und möglicherweise kollidiert es mit anderen TCP/IP-Verbindungen, die andere Programme über das OS abwickeln.


> aber so wie es aussieht werde ich dann wohl auch auf sockets umsteigen müssen


Solltest du auf jeden Fall tun. Könnte zur Abwertung deiner Diplomarbeit führen, wenn dur er IP und TCP nachbildest, weil du nicht erkannt hast, daß das im OS schon drin ist...


> Hast du meine email bekommen?


Noch nicht. web.de scheint ein Problem mit dem login zu haben.


----------



## Tupo13 (8 Dezember 2005)

@ Zottel
Ok vielen Danke für die Hinweise - werde mich dann an das Socket-Lernen machen

Ich dachte immer ISO over TCP sei das Protocoll mit dem S5 (oder auch S7 SPSen ohne IP-Adresse) komunizieren.
Sobald ein IP Header im Protocol enthalten ist - dachte ich ist es TCP/IP
ist das etwa falsch?


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> @ Zottel
> Ok vielen Danke für die Hinweise - werde mich dann an das Socket-Lernen machen


Da kannst du eigentlich allen nötigen Code in libnodave finden.
[/quote]
Ich dachte immer ISO over TCP sei das Protocoll mit dem S5 (oder auch S7 SPSen ohne IP-Adresse) komunizieren.


> Nee das war ISO.
> 
> 
> > Sobald ein IP Header im Protocol enthalten ist - dachte ich ist es TCP/IP
> ...


----------



## Tupo13 (8 Dezember 2005)

Ok kapiert danke


```
Da kannst du eigentlich allen nötigen Code in libnodave finden.
```
Ich habe MS VC++ kann ich damit den Sourcecode von libnodave.dll anschauen oder vielleicht sogar kompilieren? Das wäre ja super


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Ok kapiert danke
> 
> 
> ```
> ...


Ja sicher kannst du das. Aber bevor du die graphische Oberfläche "anwirfst:" Der Sourcecode braucht zwei conditional defines und ein weiteres, wenn er als .dll kompiliert wird. Es sind diverse Makefiles dabei, die alles von der Kommandozeile aus kompilieren, weil ich erstens kein Visual Studio habe und zweitens alles (Linux, Windows-Bibliothek, Testprogramme, .NET.dll) in einem Rutsch per Skript auf einer Linux-Kiste kompiliere.
MAKEFILE.VC sollte mit dem Make-Tool von VC++ laufen.
Es könnte aber seien, daß irgendwas nicht up to date ist. Dann mußt du schauen, was in MAKEFILE.VC.WINE steht; das ist das, womit ich die Windows-Teile übersetze.


----------



## Tupo13 (8 Dezember 2005)

Also ich habe das mit dem Makefile nicht hinbekommen
keine ahnung an was es liegt. Er bringt mir jedesmal Fatal Error

In der openSocket.c verbindest du dich zu einem Socket oder?


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Also ich habe das mit dem Makefile nicht hinbekommen
> keine ahnung an was es liegt. Er bringt mir jedesmal Fatal Error


w e l c h e n ? a n w e l c h e  r S t e l l e ?


			
				Tupo13 schrieb:
			
		

> In der openSocket.c verbindest du dich zu einem Socket oder?


Ja. Wenn es windows ist, allerdings opensocketw.c


----------



## Tupo13 (8 Dezember 2005)

Er bringt mir diese Fehlermeldung

"e:\programme\microsoft visual C++ Toolkit 2003\bin\cl" -I"e:\programme\
microsoft visual C++ Toolkit 2003\include" -I"e:\programme\microsoft platform sd
k\include" -c -DBCCWIN -DLITTLE_ENDIAN -TC -DDOEXPORT setportw.c
Das System kann den angegebenen Pfad nicht finden.
NMAKE : fatal error U1077: '"e:\programme\microsoft visual C++ Toolkit 2003\bin\
cl"' : Rueckgabe-Code '0x1'
Stop.

Sagt das dir was?


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Er bringt mir diese Fehlermeldung
> 
> "e:\programme\microsoft visual C++ Toolkit 2003\bin\cl" -I"e:\programme\
> microsoft visual C++ Toolkit 2003\include" -I"e:\programme\microsoft platform sd
> ...


*
Jaas System kann den angegebenen Pfad nicht finden. 
Du mußt die Pfade an deine Installation anpassen, z.B. Wenn dein Compiler eben nicht auf Laufwerk E: sonder C: oder sonstwo ist. Und die Namen der Unterverzeichnisse müssen auch stimmen...*


----------



## Tupo13 (8 Dezember 2005)

Er bringt immer noch diesen Fehler, obwihl der Pfad jetzt passt


NMAKE : fatal error U1077: '"c:\programme\microsoft Visual Studio\VC98\bin\cl


----------



## Zottel (8 Dezember 2005)

Tupo13 schrieb:
			
		

> Er bringt immer noch diesen Fehler, obwihl der Pfad jetzt passt
> NMAKE : fatal error U1077: '"c:\programme\microsoft Visual Studio\VC98\bin\cl


Das ist ein bischen wenig. Du mußt mal schauen, ob du den Compiler cl im angegebenen Pfad "ohne alles" aufrufen kannst. 
Das dumme ist, daß in der Zeile, die du im letzten Posting aufgeführt hast, schon 4 Pfade vorkommen: Der zum Compiler, 2 zu include-Dateien und der zum Quellcode. Sie müssen alle simmen und die include-Dateien kommen ja aus dem Platform-SDK. Wenn du den Compiler aufrufen kannst, schreibe dir 3 Zeilen C-Code, der nur jeweils eine header-Datei von denen benutzt, die auch in libnodave gebraucht werden und schau, wo du sie findest und daß der Compiler sie findet. Irgendwie erinnere ich mich, daß irgendwelche altvertrauten Windows-Header beim PSDK nicht mehr dabei waren. Kann sein, daß ich sie aus einer älteren Installation rüberkopiert habe, um es selbst zum Laufen zu kriegen.


----------



## Tupo13 (8 Dezember 2005)

ok danke werde ich versuchen

melde mich dann morgen wenn es geklappt hat

Gruß Tupo13


----------



## Tupo13 (9 Dezember 2005)

Hi Zottel

das mit dem Makefile habe ich jetzt mal auf nächste Woche verschoben - ist für mich auch nicht unbedingt nötig die DLL kompilieren zu können.
Danke aber für deine Uterstützung

Eine Frage habe ich da noch
In deiner Doku steht ja der Aufbau des PDU Protocols. Dieses Dokument ist in Blöcke unterteilt - oder?

Es fängt ja immer wieder bei Position 0 an.
Was ist der unterschied zwischen length of parameters und length of Data?
Egal wie ich zähle ich komme auf keinen zusammenhang

Kannst du dazu vielleicht ein paar Sätze sagen?
Sieht das ganze mögliche Werte... auch so aus wenn ich einen ganzen Baustein schießen will?


Gruß Tupo13


----------



## Zottel (9 Dezember 2005)

Tupo13 schrieb:
			
		

> Hi Zottel
> 
> das mit dem Makefile habe ich jetzt mal auf nächste Woche verschoben - ist für mich auch nicht unbedingt nötig die DLL kompilieren zu können.
> Danke aber für deine Uterstützung
> ...


Ein Auszug aus den Sachen die du mir geschickt hast, etwas leserlicher aufbereitet und kommentiert. Bis zum des Datenbausteins bin ich nicht gekommen (keine Zeit):

16:32:05.236579 192.168.17.166.1237 > 192.168.17.111.102: P 95:128(33) ack 131 win 65405 (DF)
    4500 0049 f95f 4000 8006 5ce9 c0a8 11a6
    c0a8 116f 04d5 0066 e37f 249c 8ab0 2f5e
    5018 ff7d 1bf6 0000 0300 0021 02f0 80
Begiin der PDU:
    32 07 00 00 04 00 00 08 00 08 
Die erste 8 ist die Länge der Parameter, die zweite die Länge der Daten.
Die Parameter selbst (8 Byte):
    00 01 12 04 11 44 01 00
Bekannt ist mir die Funktion 44, Unterfunktion 1 der PG-Funktionen, PG fordert den Inhalt einer SZL an.
Die Daten, wieder 8 Byte:
    ff 09 00 04
     01 32 00 02
Innerhalb der Daten sagt das  "ff 09 00 04": es folgen Datenbytes, und zwar 4
 01 32 ist die Nummer (132h) der SZL
00 02 der Index

Antwort der CPU:
16:32:05.255221 192.168.17.111.102 > 192.168.17.166.1237: P 131:212(81) ack 128 win 560
    4500 0079 48bf 0000 3c06 915a c0a8 116f
    c0a8 11a6 0066 04d5 8ab0 2f5e e37f 24bd
    5018 0230 48c1 0000 0300 0051 02f0 80
Begiin der PDU:
    32 07 00 00 04 00 00 0c 00 34 
Die 0c (12) ist die Länge der Parameter, die 34 (52) die Länge der Daten.
Die Parameter selbst (12 Byte):
    00 01 12 08 12 84 01 05 00 00 00 00 
84, 1 ist die Antzwort zu PG-Funktion 44,1
Die Daten, diesmal  52 Byte:
    ff 09 00 30 
Innerhalb der Daten sagt das  "ff 09 00 30": es folgen Datenbytes, und zwar 48.
SZL-Nummer und Index werden wiederholt
     01 32 00 02
Ab hier folgen die Bytes der SZL:
     00 2800
    0100 0200 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 00


----------



## Tupo13 (9 Dezember 2005)

Ok vielen Dank

Super

Gruß Tupo13


----------



## Tupo13 (19 Dezember 2005)

@Zottel

hallo, komme hier irgendwie nicht weiter. Würde mich sehr freuen, wenn du mir nochmal weiterhelfen könntest.

Ich habe das Problem, dass wenn ich die Anforderung an die SPS schicke
Funktionstyp 0x0A
Bausteinnr 0x03
Bausteintyp 0x0A also DB

Dann beendet die SPS die Verbindung und Antwortet nicht richtig

Gibt es außer den oben genannten noch andere Parameter, die ich bei dieser Funktion noch beachten muss?

vielen Dank im voraus


----------



## Zottel (19 Dezember 2005)

Tupo13 schrieb:
			
		

> Ich habe das Problem, dass wenn ich die Anforderung an die SPS schicke
> Funktionstyp 0x0A


Was soll das sein? Vielleicht Funktion 0x1A ?


----------



## Tupo13 (19 Dezember 2005)

Sorry

Natürlich Funktion 0x1A

Brauche ich für diese noch zusätzliche Parameter?


----------



## Zottel (19 Dezember 2005)

Tupo13 schrieb:
			
		

> Sorry
> 
> Natürlich Funktion 0x1A
> 
> Brauche ich für diese noch zusätzliche Parameter?


Nicht das ich wüßte. Aber ich müßte selbst erst in den Code gucken. Was klappt denn nicht? Wie sieht die Antwort von der CPU denn aus?


----------



## Tupo13 (19 Dezember 2005)

In der Antwort schickt die SPS keine Daten, sie schickt nur das FIN Flag

Vielleicht könntest du mir diese Fragen noch kurz beantworten:

- Der Header (vor der PDU) lautet ja immer so
  03  00  00  XX  02  f0  80  
  was ist denn in dem XX drin?

- Wenn ich einen Baustein hochgeladen habe, dann kann ich aus ihm ja 
  Bausteinnr, Bausteintyp, Bausteinlänge, Datenlänge, Autor, Version....
  auslesen.
  zwischen Byte17 und Byte32 müssen zwei Daten stehen
  Änderungsdatum und noch ein Datum
  ich bin nicht dahintergekommen in welchem Format, und wie ich es  
  wandeln kann - weißt du darüber vielleicht mehr?


----------



## Zottel (19 Dezember 2005)

Tupo13 schrieb:
			
		

> In der Antwort schickt die SPS keine Daten, sie schickt nur das FIN Flag


Das mit dem FIN Flag hat mich nie interessiert; das macht ja das OS...
Das hieße jetzt, daß eine Anwendung, die auf socket level ließt, einfach keine Antwort bekommt?


> Vielleicht könntest du mir diese Fragen noch kurz beantworten:
> 
> - Der Header (vor der PDU) lautet ja immer so
> 03  00  00  XX  02  f0  80
> was ist denn in dem XX drin?


Möglicherweise die Länge, aber das kannst du auch in RFC1006 oder im Quellcode von libnodave nachlesen.
[/quote]
- Wenn ich einen Baustein hochgeladen habe, dann kann ich aus ihm ja 
  Bausteinnr, Bausteintyp, Bausteinlänge, Datenlänge, Autor, Version....
  auslesen.
  zwischen Byte17 und Byte32 müssen zwei Daten stehen
  Änderungsdatum und noch ein Datum
  ich bin nicht dahintergekommen in welchem Format, und wie ich es  
  wandeln kann - weißt du darüber vielleicht mehr?[/quote]
Nein, weiß ich nicht. Bausteine aus der SPS lesen geht ja wohl, oder? Also kannst du die betreffenden Parameter ändern, den Baustein wiederum auslesen und im Hex-Editor oder so vergleichen.
Noch etwas: Wenn du einen DB3 mit testISO_TCPload -d DB3.mc7 übertragen willst, was kriegst du da von der CPU zurück? Ich sehe keinen Sinn darin, hier lauter Detailfragen zu Dingen zu beantworten, die ich ad acta gelegt habe, in der Meinung daß sie funktionieren oder Hilfe dabei zu leisten, Code der dir zur Verfügung steht noch einmal zu schreiben.


----------



## Tupo13 (19 Dezember 2005)

Hi Zottel

Danke für deine Antwort.

Ich benütze Libnodave zum Auslesen der Bausteine. Ich benütze Libnodave wo es nur geht weil es ein sehr gutes Tool ist.

Ich wollte dein Beispielprogramm verwenden um die Bausteine wieder auf die SPS zu schießen. Leider gab es da Probleme.(416 CPU)

Beim ersten mal als ich das gemacht habe habe ich die SPS zerschossen.
nach Urlöschen ging wieder alles.

Beim zweitenmal ging garnichts mehr - ich habe ein Firmwareupdate draufgeladen.......
Sie läuft einfach nicht mehr - kaputt

Ein drittes mal will ich es nicht unbedingt versuchen.



Was ich jetzt machen will ist, das ganze soweit zu verstehen, dass ich die Bausteine wieder auf die SPS bringe.


Ich kann verstehen, dass du nicht die Zeit und den Willen hast jedem alles ins kleinste Detail zu erklären.

Trotzdem vielen Dank, du hast mir in letzter Zeit sehr viel geholfen und ich bin Dank deiner Hilfe sehr gut voran gekommen.


Gruß Tupo13


----------



## Zottel (19 Dezember 2005)

Tupo13 schrieb:
			
		

> Beim ersten mal als ich das gemacht habe habe ich die SPS zerschossen.
> nach Urlöschen ging wieder alles.


Wie sah der "zerschossene" Zustand vor dem Urlöschen aus? Soweit ich verstehe, befindet sich ja die Netzwerk-Schnittstelle auf einem CP. Damit das geht, muß sicherlich einen passende HW-Konfig da sein?
MPI könnte funktionieren,auch wenn mit dem CP nichts mehr geht.


> Beim zweitenmal ging garnichts mehr - ich habe ein Firmwareupdate draufgeladen.......
> Sie läuft einfach nicht mehr - kaputt


Das klingt natürlich erschreckend. Aber wenn es so ist, würde ich Folgendes erwägen:
1. Informier dich mal, was man nach einem gescheiterten Firmware-Update machen kann.
2. Falls man so eine CPU tatsächlich durch ein paar Datenpakete "killen" kann, sind alle deine jetzigen Versuche genauso gefährlich.


----------



## Tupo13 (19 Dezember 2005)

Na ja das erste mal war es noch relativ harmlos
 ich habe ein ganz normales S7 Projekt genommen
 mit deinem Testtool den OB1 gespeichert.
Dann habe ich ihn mit deinem Tool wieder hinuntergeschossen
Die SPS ging nicht in Stop soweit ich mich erinnern kann.
Als ich dann mit Step7 die Bausteine Online anschauen wollte war kein einziger zu sehen keine DBs,FCs,SFCs..... das Programm war aber noch auf der Steuerung und ist auch gelaufen - richtigen Werte an den Ausgängen.

Nach Urlöschen war alles wieder in Ordnung

Beim zweiten mal stoppte die SPS, ich habe Sie dann Urgelöscht und wollte über MPI die Hardwarekonfiguration schießen.
Das lässt er aber nicht mehr zu, er will irgendein Passwort
ich habe nie ein Passwort parametriert gehabt

Auch müssten laut Support alle Passwörter nach dem Urlöschen... entfernt sein....
Danach Firmwareupdate.....
Es geht nichts mehr


----------



## Zottel (19 Dezember 2005)

Tupo13 schrieb:
			
		

> Na ja das erste mal war es noch relativ harmlos
> ich habe ein ganz normales S7 Projekt genommen
> mit deinem Testtool den OB1 gespeichert.
> Dann habe ich ihn mit deinem Tool wieder hinuntergeschossen
> ...


Online anschauen über CP oder MPI?
Welche anderen Funktionen gingen oder gingen nicht mehr?
Kommuniziertee die CPU über MPI? Wenn ja, was stand im Diagnosepuffer?


> Nach Urlöschen war alles wieder in Ordnung


So sollte es sein...


> Beim zweiten mal stoppte die SPS, ich habe Sie dann Urgelöscht und wollte über MPI die Hardwarekonfiguration schießen.
> Das lässt er aber nicht mehr zu, er will irgendein Passwort
> ich habe nie ein Passwort parametriert gehabt


Mal versucht, das Urlöschen zu wiederholen?


> Auch müssten laut Support alle Passwörter nach dem Urlöschen... entfernt sein....


Ja müßten. Mit dem Urlöschen von S7 habe ich keine großen Erfahrungen, aber bei S5 habe ich mir irgendwann angewöhnt, immer zweimal zu löschen...


> Danach Firmwareupdate.....
> Es geht nichts mehr


 Ein Firmwareupdate kann natürlich schon an sich schiefgehen.
Wie sieht das Im Detail aus? Kommunikation? LEDs? Versuch, vorige Firmware wieder einzuspielen? Was hast du mit dem Ding vor?


----------



## Tupo13 (19 Dezember 2005)

Versucht habe ich so ziemlich alles schon 
bestimmt 50mal Urgelöscht,
sie vom Rack geschraubt (dann müsste normalerweise auch alles weg sein)
Firmwareupdate 1x das empfohlene Update (Das ist ziemlich umständlich auf Eprom schießen...)

LED's brennen keine Fehler nur die Stopp LED, beim Anlaufversuch geht die Stopp LED nicht aus und er schafft den Anlauf auch nicht.

Ich kann mir nicht Vorstellen, dass man auf Speicherbereiche des Betriebsystems... schreiben kann - das könnte ja teoretisch auch bei Bitfehlern passieren, das hat Siemens bestimmt irgendwie geschützt.
Auch hast du ja gemeint dass es bei den 300ern noch nie Probelme gegeben hat.

Es kann natürlich auc sein, dass es ein Hardewarefehler ist und nichts mit dem laden des Bausteins zu tun hat.
Das halte ich allerdings für ziemlich unwarscheinlich
1. gehen SPSen sehr sehr sehr selten kaputt
2. und dass es dann auch noch genau nach dem laden passiert 

Momentan steht das Ding bei mir auf dem Schreibtisch, ich hoffe, dass ich sie wieder zum laufen bringe

Gruß Tupo13


----------



## Question_mark (19 Dezember 2005)

*LibNoDave*

Hallo Tupo13,


			
				Tupo13 schrieb:
			
		

> - Der Header (vor der PDU) lautet ja immer so
> 03 00 00 XX 02 f0 80
> was ist denn in dem XX drin?



Nicht ganz genau getroffen. Der Header lautet :
03 00 XX XX 02 F0 80

wobei XX XX für die Länge der nachfolgenden Daten steht (beim byteweisen Auslesen aber nicht das SWAP vergessen).
Der Part 03 00 XX XX ist dann in Fachkreisen als TPKT bekannt. Wenn Du dann noch googeln kannst, bringt Dich das weiter.



			
				Zottel schrieb:
			
		

> Das mit dem FIN Flag hat mich nie interessiert; das macht ja das OS...


Ja, aber das OS der S7-CPU. Die mag es nämlich überhaupt nicht, wenn im ISO-Anteil des Telegramms vom PC falsche Längenangaben stehen und will sich mit jemanden, der ein so korruptes Telegramm schickt, ganz einfach nicht mehr unterhalten.
Gruß
Question_mark


----------



## Question_mark (19 Dezember 2005)

Hallo Tupo13,


			
				Question_mark schrieb:
			
		

> Übrigens, der OPC-Server von Siemens (Simatic.Net) und auch die S7-SAPI.DLL können problemlos Bausteine von der S7 lesen b.z.w. schreiben.


Das habe ich ziemlich am Anfang dieses Threads geschrieben. Für Deine Reparatur der CPU 416 gibt es einen Pauschalpreis von Siemens für 999,- € zuzüglich Mehrwertsteuer. Wieviel hast Du jetzt durch die kostenlosen Tools und nach vielen Wochen Arbeitsaufwand eigentlich gespart ???
Mal so in Euro ausgedrückt ???
Gruß
Question_mark


----------



## seeba (20 Dezember 2005)

Question_mark schrieb:
			
		

> Hallo Tupo13,
> 
> 
> 
> ...



Nichts  :lol: Aber die CPU kann doch nicht einfach so nicht mehr gehen!


----------



## Tupo13 (20 Dezember 2005)

@ Question_Marc
Danke für deine Erklärung des TPKT

Was das mit dem OPC server ... angeht weiß ich dass es geht ich habe ja bereits eine Anwendung die den OPC-Server von SimaticNet und deren Funktionen benützt.

Die Aufgabe lautet jedoch keine kostenpflichtige Programme..... zu verwenden. Es handelt sich um eine Diplomarbeit.
Mit Libnodave klappt auch alles einwandfrei nur eben die Bausteine wieder zurückspielen, da hakt es noch.

Woher weißt du, dass Siemens die SPS um 1000€ wieder reparieren kann.
Hattest du schon einmal einen ähnlichen Fehler, weißt du an was es liegen kann?

Gruß Tupo13


----------



## Question_mark (20 Dezember 2005)

Hallo Tupo13,


			
				Tupo13 schrieb:
			
		

> Die Aufgabe lautet jedoch keine kostenpflichtige Programme


Ok, dann ist natürlich Libnodave die einzigste, mir bekannte Möglichkeit, das ganze ohne kostenpflichtige Tools zu lösen.


			
				Tupo13 schrieb:
			
		

> Woher weißt du, dass Siemens die SPS um 1000€ wieder reparieren kann


Es gibt da einen Pauschalpreis für Reparaturen, egal ob nur ein defektes Gehäuseteil oder die CPU-Platine ersetzt werden muss. Bei der 400-er CPU kostet das m.W. so ca. 999,- € und Mwst. Einfach mal den freundlichen Ansprechpartner bei Siemens fragen.

Gruß
Question_mark


----------



## Zottel (20 Dezember 2005)

Anbei noch ein Tip zur Wiederbelebung von Rainer Hönle:


> Ein Test wäre noch, ein entsprechendes Programm mit Hardwarekonfig, auch die der CP, auf ein Flash zu brennen, das zu Stecken und danach noch einmal Urlöschen ausführen. Wenn dann die CP geht, ist die MPI-Schnittstelle defekt, wenn nicht, dann muss die CPU zu Siemens zur Prüfung.


----------



## Tupo13 (20 Dezember 2005)

Danke Zottel

werde ich versuchen


----------



## Tupo13 (20 Dezember 2005)

Also das mit dem Eprom habe ich versucht.
Den CP konnte ich danach anpingen
Onlineansicht hat er nicht geschaft.
Wenn ich ein Baustein auf die SPS schießen will dann will er von mir ein Passwort und lässt das nicht zu.(Step7 Version5.3 SP2)
Bei der Step7 Version 3.1 macht er das komischerweise (über MPI)

Wenn ich Urlöschen oder in den Runmode wechseln will (beide Versionen), dann sagt er mir dass das bei der aktuellen Sicherheitsstufe nicht erlaubt ist...Auf den Schlüsselschalter reagiert er garnicht

Ich Frage mich wo um alles in der Welt kann den dieses Passwort stehen, dass es nach dem Urloschen, Firmwareupdate..... immer noch auf der SPS ist?
Auch habe ich ja nie ein solches Passwort eingegeben. Gibt es noch andere Passwörter als das unter den Objekteigenschaften Schutz?

Danke für eure Hilfe
Gruß Tupo13


----------



## Rainer Hönle (20 Dezember 2005)

Da würde ich jetzt mal den freundlichen Mann von Siemens fragen. Die CPU scheint ja noch zu funktionieren. Vielleicht gibt es ein Masterpasswort.


----------



## Anonymous (20 Dezember 2005)

Hallo ich hätte da mal eine Frage:

Weiß jemand ob es ein Dokument gibt, in dem die PG-Funktionen aufgelistet und beschrieben werden?

Gruß Tupo13


----------



## Question_mark (21 Dezember 2005)

*S7-Programmierschnittstelle*

Hallo, Tupo13,


			
				Tupo13 schrieb:
			
		

> Weiß jemand ob es ein Dokument gibt, in dem die PG-Funktionen aufgelistet und beschrieben werden?


Gibt es natürlich, aber wer es besitzt, wird das nicht gerade im Internet publizieren. Wissen ist manchmal Macht oder auch Geld. Ich weiss wie ich heisse und wie alt ich bin. In diesem Falle interessiert das kein Schwein  und es 'macht' nix. Wenn ich aus meinem Wissen über das Protokoll einen entsprechenden S7-Treiber erstellen und verkaufen kann, dann verdiene ich damit Taler, also 'macht' es irgendwas für mich. 
Wenn die Kenntnis der Protokolle für deine Diplomarbeit so eminent wichtig sind, sollte es über Deinen Prof möglich sein, diese Informationen zu erhalten. Ansonsten hast Du das falsche Thema für eine Diplomarbeit. Es kann nicht sein, dass Du im Rahmen einer Diplomarbeit einige Mannjahre Entwicklung der Firma Siemens nachbilden sollst. Auch die LibNodave von Zottel hat noch viele Aspekte der Programmierschnittstelle noch nicht berücksichtigt (Zottel, bitte nicht böse sein, Du hast eine tolle Arbeit vorgelegt in absoluter Zeigerakrobatik mit dem Potential der grössten Verwirrung (dank C) und minimaler Kommentierung). 
Also Tupo13, sorge bitte dafür, dass Dein Prof den Sourcecode von Zottel nicht einsehen kann, das gibt jede Menge Minuspunkte   
Ach so, zurück zum Thema :
Du hast versucht, über die Domain-Dienste einen Up/Download von Bausteinen zu realisieren. Zu den Domain-Diensten gehört aber auch das Setzen von Passwörtern. Da reicht dann schon ein falsch gesetztes Flag im Telegramm und eine andere zufällige Bytefolge im Telegramm wird als Passwort interpretiert und unwiderruflich in der CPU als Passwort gesetzt. 

Gruß
Question_mark
PS : Du hast es geschafft, die Schutzstufe 3 einzustellen, herzlichen Glühstrumpf dazu, ist gar nicht so einfach.


----------



## seeba (21 Dezember 2005)

*Re: S7-Programmierschnittstelle*



			
				Question_mark schrieb:
			
		

> Zottel, bitte nicht böse sein, Du hast eine tolle Arbeit vorgelegt in absoluter Zeigerakrobatik mit dem Potential der grössten Verwirrung (dank C) und minimaler Kommentierung



Wie war das? Nur ein Genie beherrscht das Chaos, oder?


----------



## Zottel (21 Dezember 2005)

*Re: S7-Programmierschnittstelle*

Zum Problem mit der CPU: Da die Misere jetzt einen Namen zu haben scheint (Schutzstufe 3), sollte es ja vielleicht möglich sein, etwas darüber in der Dokumentation zu finden. Für diejenigen, die es schneller sagen können, als ich es finde: Hat eine 315-2DP auch diese Schutzstufe? Wie kann ich sie mit Absicht aktivieren?
@Tupo13:


> Bei der Step7 Version 3.1 macht er das komischerweise (über MPI)


Möglicherweise kannst du mit dieser Version weiter kommen?


			
				Question_mark schrieb:
			
		

> Auch die LibNodave von Zottel hat noch viele Aspekte der Programmierschnittstelle noch nicht berücksichtigt (Zottel, bitte nicht böse sein,


Es ist mit völlig klar,daß es "work in progress" ist und nur diejenige Untermenge von Funktionen enthält, die ich beim Mithören der Kommunikation zuordnen konnte.


> ...Du hast eine tolle Arbeit vorgelegt in absoluter Zeigerakrobatik


Es gibt genau zwei Stellen, an denen wesentlich mit Zeigern gearbeitet wird:
1. Zeiger auf protokollspezifische Funktionen. Sie erlauben z.B. S7-200 und 300/400 (und demnächst S5) mit denselben Funktionsaufrufen zu behandeln, was ich als Vorteil gegenüber ähnlichen Produkten anderer Herkunft sehe.
2. Zum Merken der aktuellen Positionen der PDU und einzelner Bereiche darin (Parameter, Daten). Mögliche Alternativen müßten mehr Parameter von einer Funktion zur anderen übergeben oder, in objektorientierten Sprachen, implizite Zeiger auf Objekdaten und, für einen völlig objektorientierten Ansatz, zusammengesetzte Objekte konstruieren.


> ...mit dem Potential der grössten Verwirrung (dank C)


Ich sehe an vorderster Stelle, daß es sich dank C auf so ziemlich jedem System kompilieren läßt und von so ziemlich jeder anderen Sprache aus aufrufen läßt. Wäre es in eineri Sprache mit eigener Speicher/Objektverwaltung geschrieben, würde es zumindest darauf hinauslaufen, die notwendigen Teile in jedes Programm mitschleppen zu müssen.


> ... und minimaler Kommentierung).


Gegenüber der meisten freien Software, mit der ich im Laufe der Zeit zu tun hatte, halte ich den Quellcode für üppig kommentiert.


----------



## Rainer Hönle (21 Dezember 2005)

*Re: S7-Programmierschnittstelle*



			
				Zottel schrieb:
			
		

> Zum Problem mit der CPU: Da die Misere jetzt einen Namen zu haben scheint (Schutzstufe 3), sollte es ja vielleicht möglich sein, etwas darüber in der Dokumentation zu finden. Für diejenigen, die es schneller sagen können, als ich es finde: Hat eine 315-2DP auch diese Schutzstufe? Wie kann ich sie mit Absicht aktivieren?


Ja, die 315-2DP hat auch die Schutzstufe, zumindestens in der aktuellen Variante. Einfach in Hardwarekonfig auf CPU doppelklicken und den Tanz im Reiter Schutz beginnen  



> ... was ich als Vorteil gegenüber ähnlichen Produkten anderer Herkunft sehe.


Das sage ich bei ACCON-AGLink auch immer :wink: Aber es stimmt, für jede CPU-Familie bzw. jeden Kommunikationsweg eine eigene API ist meiner Meinung nach eine Zumutung für die Anwender.


----------



## Rainer Hönle (21 Dezember 2005)

Habe noch mal nachgesehen. Schutz ist seit 6ES7 315-2AF02-0AB0 drin.


----------



## Question_mark (21 Dezember 2005)

*Passwortschutz*

Hallo Tupo13,
Schutzstufe 3 bedeutet ganz einfach, dass alle Schreib/Lesevorgänge auf die CPU bis zur Eingabe des gültigen Passwortes gesperrt sind. Das Passwort ist immer 8 Byte lang. Durch das Passwort wird dabei der Schlüsselschalter der CPU zweitrangig. Ich vermute (wie gesagt, nur meine unmassgebliche Vermutung) mal, dass Du beim Experimentieren mit selbsterstellten Telegrammen versehentlich einen Passwortschutz mit einem Dir nun unbekannten Passwort erstellt hast.

Ruf doch einfach bei der Simatic-Hotline in Nürnberg an und schildere Dein Problem, vielleicht gibt es ja ein Master-Passwort.   :wink: 
Ansonsten habe ich wirklich keine Ahnung, wie Du aus der Nummer wieder rauskommst.

Gruß
Question_mark


----------



## Rainer Hönle (22 Dezember 2005)

Nachdem das Passwort in der Hardwarekonfig und somit in den SDBs abgelegt ist, bzw. sein sollte, einfach mal folgendes Experiment machen: In der bestehenden Konfig die Schutzstufe 3 auswählen um ein Passwort eingeben. Diese Konfiguration auf ein Flash brennen, in die CPU stecken und Urlöschen per Schalter ausführen. Welches Passwort nimmt die CPU nun? Das bekannte neue oder immer noch das alte?


----------



## Rainer Hönle (22 Dezember 2005)

@Tupo13
Habe jetzt einmal etwas mit den Passwörtern auf meiner 416er rumgespielt. Wenn ich in der Hardwarekonfig ein Passwort eingebe, runterlade, Passwort ändere, runterlade kommt keine Abfrage des Passwortes. Dieses wird somit auch in Stufe 3 einfach überschrieben. D.h. wenn es bei Ihrer CPU genauso ist, würde es genügen eine neue Konfig runterzuladen. Kommt bei Ihnen an dieser Stelle bereits eine Abfrage?


----------



## Tupo13 (2 Februar 2006)

Entschuldigung, dass ich mich solange nicht mehr gemeldet habe
(wurde irgendwie nichtmehr über neue Beiträge informiert).

Das Problem mit der SPS besteht aber immer noch,
werde jetzt mal eure Vorschläge testen,
falls es klappt melde ich mich sofort.

Vielen vielen Dank für eure tatkräftige unterstützung

Gruß Tupo13


----------



## Question_mark (2 Februar 2006)

*Wat iss nu mit dem Baustein ???*

Hallo Tupo13,


			
				Tupo13 schrieb:
			
		

> Das Problem mit der SPS besteht aber immer noch,


Ja, das Thema interessiert mich allerdings auch immer noch, allerdings in einem anderen Zusammenhang. Interessant ist folgendes : Über 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) ?
Wenn Du den S7-Baustein in Windows mit einem Hex-Editor öffnest, wie oft findest Du folgende Zeichenfolge (wobei xx für beliebige Zeichen steht):

03 00 
xx xx
02 F0
00

oder :

03 00 
xx xx
02 F0
80

Welche S7 wurde verwendet : Bitte MLFB der CPU angeben.
Um die eingestellte Schutzstufe der CPU herauszufinden, ruf mal LibNoDave auf und rufe SZL 0232 mit dem Index 04 auf. Die Erklärung zu den Informationen aus der SZL findest Du dann in der entsprechenden Siemens-Info. Wenn die nicht zu Deiner Verfügung steht, poste bitte die zurückgegebenen Bytes im Hex-Format hier im Thread.

Gruß
Question_mark


----------



## Tupo13 (3 Februar 2006)

@ 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


----------



## Rainer Hönle (3 Februar 2006)

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.
> ...


Im Handbuch "Standardsoftware für die S7-300/400 System- und Standardfunktionen" Kapitel 31 "Systemszustandsliste". Dort ist eine Beschreibung der aktuell dokumentierten SZLs enthalten.


----------



## Tupo13 (3 Februar 2006)

@ Rainer Hönle

Sogar auf deutsch! Vielen Vielen Dank


----------



## Question_mark (3 Februar 2006)

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


----------



## Rainer Hönle (3 Februar 2006)

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.


----------



## Question_mark (3 Februar 2006)

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


----------



## Rainer Hönle (3 Februar 2006)

Hallo,


			
				Question_mark schrieb:
			
		

> ja, schon. Aber Zottels LibNoDave bildet ja Layer 4 und 5 nach, oder ???


Stimmt, muss er ja zwangsläufig. Und der L5 ist ja überall (TCP/IP, PC-Adapter,..) derselbe.
Grüße
Rainer Hönle


----------



## Tupo13 (6 Februar 2006)

@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


----------



## Question_mark (6 Februar 2006)

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


----------



## Rainer Hönle (6 Februar 2006)

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.


----------



## Rainer Hönle (6 Februar 2006)

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.


----------



## Question_mark (6 Februar 2006)

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.   


			
				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


----------



## Rainer Hönle (6 Februar 2006)

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


----------



## Tupo13 (6 Februar 2006)

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


----------



## Zottel (6 Februar 2006)

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
> ...



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"


----------



## Rainer Hönle (6 Februar 2006)

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
> ...


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.


----------



## Tupo13 (6 Februar 2006)

Danke Rainer Hönle
Danke Zottel


----------



## Rainer Hönle (6 Februar 2006)

War Zottel doch wieder mal schneller


----------



## Question_mark (6 Februar 2006)

Hallo,


			
				Rainer Hönle schrieb:
			
		

> Stimmt, aber Siemens fängt schon mit 0


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: 

Gruß
Question_mark


----------



## Rainer Hönle (7 Februar 2006)

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  ).
Und da gibt es Leute, die behaupten in diesem Forum würde das Niveau sinken und nur immer wieder die selben Themen aufgewärmt :?:


----------

