Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 7 von 8 ErsteErste ... 5678 LetzteLetzte
Ergebnis 61 bis 70 von 80

Thema: mit libnodave komplette Bausteine sichern

  1. #61
    Tupo13 ist offline Benutzer
    Themenstarter
    Registriert seit
    05.09.2005
    Beiträge
    43
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard


    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

  2. #62
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.235
    Danke
    642
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Zitat Zitat von Tupo13
    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.
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  3. #63
    Tupo13 ist offline Benutzer
    Themenstarter
    Registriert seit
    05.09.2005
    Beiträge
    43
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard

    @ Rainer Hönle

    Sogar auf deutsch! Vielen Vielen Dank

  4. #64
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Standard

    Hallo,
    Zitat Zitat von Tupo13
    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
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)

  5. #65
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.235
    Danke
    642
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Zitat Zitat von Question_mark
    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 ), 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.
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  6. #66
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Standard

    Hallo,
    Zitat Zitat von Rainer Hönle
    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 ???
    Zitat Zitat von Rainer Hönle
    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
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)

  7. #67
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.235
    Danke
    642
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Hallo,
    Zitat Zitat von Question_mark
    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

  8. #68
    Tupo13 ist offline Benutzer
    Themenstarter
    Registriert seit
    05.09.2005
    Beiträge
    43
    Danke
    2
    Erhielt 0 Danke für 0 Beiträge

    Standard

    @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

  9. #69
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Standard

    Hallo Tupo13,
    soweit richtig erkannt. Aber zur weiteren Erklärung :
    Zitat Zitat von Tupo13
    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.
    Zitat Zitat von Tupo13
    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
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)

  10. #70
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.235
    Danke
    642
    Erhielt 955 Danke für 769 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Question_mark
    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
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

Ähnliche Themen

  1. Komplette Bausteine gelöscht
    Von Waelder im Forum Simatic
    Antworten: 11
    Letzter Beitrag: 26.04.2017, 10:05
  2. Libnodave und schreibgeschützte Bausteine?
    Von Cliff im Forum Hochsprachen - OPC
    Antworten: 14
    Letzter Beitrag: 20.01.2011, 18:46
  3. DB's in SQL DB sichern? Libnodave?
    Von H00K im Forum Hochsprachen - OPC
    Antworten: 4
    Letzter Beitrag: 21.12.2009, 11:54
  4. Bausteine mit Libnodave übertragen
    Von ronnie.b im Forum Hochsprachen - OPC
    Antworten: 0
    Letzter Beitrag: 08.03.2008, 10:58
  5. Antworten: 0
    Letzter Beitrag: 23.05.2006, 10:56

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •