TIA Bearbeitung PUT/GET S7-1500

[JanB1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen

Ich hab mal eine sehr spezifische Frage über die ich leider nichts in der Siemens Dokumentation gefunden habe.

Heute ist per Zufall die Frage aufgetaucht, wie denn genau ein GET abgearbeitet wird in der entfernten CPU.
Die S7-Kommunikation ist ja nichts anderes als ein mehr oder weniger proprietäres TCP(?)-Kommunikationsprotokoll.
Das heisst die Anfrage wird über den Kommunikationsprozessor in der entfernten CPU bearbeitet.
Meine Frage nun: wird bei einem GET eine Art interrupt ausgeführt, das heisst es wird aus der aktuellen bearbeitung rausgesprungen, das GET wird bearbeitet und danach wird die Bearbeitung fortgesetzt, oder wird das GET erst beim nächsten Zyklus bearbeitet? Und wann wird das GET bearbeitet, am Anfang, irgendwo dazwischen oder am Ende eines Zyklus?

Das sind sehr detaillierte Fragen und ich hab dazu leider auf die schnelle keine genaueren Informationen gefunden.

 

[DeltaMikeAir]

das heisst es wird aus der aktuellen bearbeitung rausgesprungen, das GET wird bearbeitet und danach wird die Bearbeitung fortgesetzt

PUT/GET arbeitet azyklisch. D.h. du triggerst per REQ an und dann ( nach mehreren Zyklen ) meldet PUT/GET "DONE".
Die Bearbeitung des SPS Program läuft regulär weiter.

[TABLE="class: title, width: 100%"]
[TR]
[TD]PUT: Daten in eine remote CPU schreiben[/TD]
[TD="align: right"]

[/TD]
[/TR]
[/TABLE]


Beschreibung
Mit der Anweisung "PUT" können Sie Daten in eine remote CPU schreiben.
Bei einer positiven Flanke am Steuereingang REQ wird die Anweisung gestartet:

• Dabei werden die Zeiger auf die zu schreibenden Bereiche (ADDR_i) und die Daten (SD_i) an die Partner-CPU gesendet. Die Partner-CPU kann sich im Betriebszustand RUN oder STOP befinden.
• Die zu sendenden Daten werden aus den projektierten Sendebereichen (SD_i) kopiert. Die Partner-CPU legt die gesendeten Daten unter den mitgeführten Adressen ab und sendet eine Ausführungsquittung zurück.
• Falls keine Fehler auftraten, wird dies beim nächsten Anweisungs-Aufruf am Zustandsparameter DONE mit "1" angezeigt. Eine erneute Aktivierung eines Schreibvorgangs ist erst nach dem Abschluss des letzten möglich.

Wenn beim Schreiben der Daten Zugriffsprobleme auftraten, oder die Prüfung der Ausführungsquittung einen Fehler ergab, werden Fehler und Warnungen über ERROR und STATUS ausgegeben.
Voraussetzungen zur Verwendung der Anweisung

• In den Eigenschaften der Partner-CPU wurde unter "Schutz" die Funktion "Zugriff über PUT/GET-Kommunikation durch entfernten Partner erlauben" aktiviert.
• Die Bausteine, auf die Sie mit der Anweisung "PUT" zugreifen, wurden mit der Zugriffsart "standard" erstellt.
• Sie müssen darauf achten, dass die über die Parameter ADDR_i und SD_i definierten Bereiche in der Anzahl, in der Länge und im Datentyp zueinanderpassen.
• Der zu schreibende Bereich (Parameter ADDR_i) muss so groß sein, wie der Sendebereich (Parameter SD_i).

Parameter
Die folgende Tabelle zeigt die Parameter der Anweisung "PUT":


[TABLE="class: table_default"]
[TR]
[TH] Parameter[/TH]
[TH] Deklaration[/TH]
[TH] Datentyp[/TH]
[TH] Speicherbereich[/TH]
[TH] Beschreibung[/TH]
[/TR]
[TR]
[TD] REQ[/TD]
[TD] Input[/TD]
[TD] BOOL[/TD]
[TD] E, A, M, D, L oder Konstante[/TD]
[TD] Steuerparameter request, aktiviert den Datenaustausch bei steigender Flanke.[/TD]
[/TR]
[TR]
[TD] ID[/TD]
[TD] Input[/TD]
[TD] WORD[/TD]
[TD] E, A, M, D, L oder Konstante[/TD]
[TD] Adressierungsparameter zur Angabe der Verbindung zu der Partner-CPU.[/TD]
[/TR]
[TR]
[TD] DONE[/TD]
[TD] Output[/TD]
[TD] BOOL[/TD]
[TD] E, A, M, D, L[/TD]
[TD] Zustandsparameter DONE:

• 0: Auftrag wurde noch nicht gestartet oder wird noch ausgeführt
• 1: Auftrag wurde fehlerfrei ausgeführt.

[/TD]
[/TR]
[TR]
[TD] ERROR[/TD]
[TD] Output[/TD]
[TD] BOOL[/TD]
[TD] E, A, M, D, L[/TD]
[TD] Zustandsparameter ERROR und STATUS, Fehleranzeige:

• ERROR=0
  STATUS hat den Wert:
  • 0000H: weder Warnung noch Fehler
  • <> 0000H: Warnung, STATUS liefert detaillierte Auskunft.
• ERROR=1
  Es liegt ein Fehler vor. STATUS liefert detaillierte Auskunft über die Art des Fehlers.

[/TD]
[/TR]
[TR]
[TD] STATUS[/TD]
[TD] Output[/TD]
[TD] WORD[/TD]
[TD] E, A, M, D, L[/TD]
[/TR]
[TR]
[TD] ADDR_1[/TD]
[TD] InOut[/TD]
[TD] REMOTE[/TD]
[TD] E, A, M, D[/TD]
[TD] Zeiger auf diejenigen Bereiche in der Partner-CPU, in die geschrieben werden soll.
Wenn der REMOTE-Zeiger auf einen DB zugreift, ist der DB immer zu spezifizieren.
Beispiel: P#DB10.DBX5.0 Byte 10.
Bei der Übertragung von Datenstrukturen (z. B. Struct) muss an den Parametern ADDR_i der Datentyp CHAR verwendet werden.[/TD]
[/TR]
[TR]
[TD] ADDR_2[/TD]
[TD] InOut[/TD]
[TD] REMOTE[/TD]
[/TR]
[TR]
[TD] ADDR_3[/TD]
[TD] InOut[/TD]
[TD] REMOTE[/TD]
[/TR]
[TR]
[TD] ADDR_4[/TD]
[TD] InOut[/TD]
[TD] REMOTE[/TD]
[/TR]
[TR]
[TD] SD_1[/TD]
[TD] InOut[/TD]
[TD] VARIANT[/TD]
[TD] E, A, M, D, L[/TD]
[TD] Zeiger auf diejenigen Bereiche in der eigenen CPU, die die zu versendenden Daten enthalten.
Zulässig sind nur die Datentypen BOOL, BYTE, CHAR, WORD, INT, DWORD, DINT, REAL.
Bei der Übertragung von Datenstrukturen (z. B. Struct) muss an den Parametern SD_i der Datentyp CHAR verwendet werden.[/TD]
[/TR]
[TR]
[TD] SD_2[/TD]
[TD] InOut[/TD]
[TD] VARIANT[/TD]
[/TR]
[TR]
[TD] SD_3[/TD]
[TD] InOut[/TD]
[TD] VARIANT[/TD]
[/TR]
[TR]
[TD] SD_4[/TD]
[TD] InOut[/TD]
[TD] VARIANT[/TD]
[/TR]
[/TABLE]

Weitere Informationen zu den gültigen Datentypen finden Sie unter "Übersicht über die gültigen Datentypen".
Parameter ERROR und STATUS
Die folgende Tabelle enthält alle für die Anweisung "PUT" spezifischen Fehlerinformationen, die über die Parameter ERROR und STATUS ausgegeben werden können.

 

[funkey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soweit ich weiß wurde bei der 300er die Programmbearbeitung für die Kommunikation unterbrochen. Bei der 400er läuft die Kommunikation parallel zum Programm und davon gehe ich auch bei der 1500er aus.

 

[Heinileini]

Heute ist per Zufall die Frage aufgetaucht, wie denn genau ein GET abgearbeitet wird in der entfernten CPU.

Habe ich jetzt die Frage und/oder die Antworten falsch verstanden?

 

[ducati]

Soweit ich weiß wurde bei der 300er die Programmbearbeitung für die Kommunikation unterbrochen. Bei der 400er läuft die Kommunikation parallel zum Programm und davon gehe ich auch bei der 1500er aus.

Nee, bei der 300er wird die Kommunikation im Zykluskontrollpunkt (also vor/nach OB1) durchgeführt, es sei denn, in der HW-Konfig ist der Menüpunkt "optimierte Kommunikation" angehakt, dann passiert die Kommunikation "parallel" zum OB1, wie auch bei 400er und 1500er.

Ob dabei die Kommunikation wirklich parallel zum OB1 abläuft, oder der OB1 dafür (kurz) unterbrochen wird, da scheiden sich die Geister. Und Heinilein, das bezieht sich m.M. auf die eigene sowie auch die entfernte CPU.

Gruß.

PS: irgendwo müssen natürlich die ankommenden Datenpakete zwischengepuffert werden...

PPS:

für die Praxis ja relevant, welche Variableninhalte bekommt man von der entfernten SPS: bei 300er ohne "optimierte Kommunikation" den Inhalt im Zykluskontrollpunkt, ansonsten den Variableninhalt von einem zufälligen Zeitpunkt im OB1. (wenn am Anfang vom OB1 ein DB-Wert 0 gesetzt wird und in der Mitte vom OB1 auf 10, dann liest PUT bei 400/1500 vermutlich 50/50 mal 0 mal 10, bei 300er immer 10)
Interessant in dem Zusammenhang auch noch die Datenkonsistenz. D.H. nicht alle Variableninhalte müssen aus dem selben OB1 Zyklus stammen, wenn ich z.B. mehr als 64Byte mit PUT lese. Wenn hier nen REAL-Wert z.B. vom Byte62 bis 65 reicht, kann da auch abundzu mal Quatsch (ein nicht gültiger Real-Wert) ankommen...

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

PS: irgendwo müssen natürlich die ankommenden Datenpakete zwischengepuffert werden...

In die Programmierhandbuch zu S7-300 habe ich gelesen dass bei PUT ist die Datenkonsistenz max 32 Bytes. Also, es gibt ein Zwischenpuffer und es ist nur 32 Bytes gross. Das ist eine wesentliche Nachteil gegenüber z.B BSEND/BRECV. Das kan bei den entfernte Gerät zu lustige Ereignisse führen.

Wie es verhält sich bei S7-1500 weis ich nicht. Es wäre interessant.

 

[ducati]

In die Programmierhandbuch zu S7-300 habe ich gelesen dass bei PUT ist die Datenkonsistenz max 32 Bytes. Also, es gibt ein Zwischenpuffer und es ist nur 32 Bytes gross. Das ist eine wesentliche Nachteil gegenüber z.B BSEND/BRECV. Das kan bei den entfernte Gerät zu lustige Ereignisse führen.

Wie es verhält sich bei S7-1500 weis ich nicht. Es wäre interessant.

https://support.industry.siemens.com/cs/at/de/view/78028908

ja, bei 300er mit CP 32 Byte, bei integrierter Schnittstelle 64 Byte bis zu 240 Byte, ja nach CPU.

Bei 400, 1200, 1500 nur für jeweils eine Variable konsistent.

Seite 41.

 

[Blockmove]

Bei 400, 1200, 1500 nur für jeweils eine Variable konsistent.

Und das bezieht sich auf die elementaren Typen.
String gehört da schon nicht mehr dazu.

 

[JanB1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe ich jetzt die Frage und/oder die Antworten falsch verstanden?

Du hast die Frage richtig verstanden, die Antwort von DeltaMike ist der Auszug aus der TIA-Hilfe, aber das beschreibt ja eben nur die lokale und nicht die entfernte CPU.

PUT/GET arbeitet azyklisch. D.h. du triggerst per REQ an und dann ( nach mehreren Zyklen ) meldet PUT/GET "DONE". Die Bearbeitung des SPS Program läuft regulär weiter.

Dahingehend: Danke @DeltaMike, aber das ist leider nicht das, was ich gesucht habe. Das gilt ja nur für die lokale CPU. In der entfernten CPU weiss ich ja nicht, wenn mit GET zugegriffen wird.

PPS:
für die Praxis ja relevant, welche Variableninhalte bekommt man von der entfernten SPS: bei 300er ohne "optimierte Kommunikation" den Inhalt im Zykluskontrollpunkt, ansonsten den Variableninhalt von einem zufälligen Zeitpunkt im OB1. (wenn am Anfang vom OB1 ein DB-Wert 0 gesetzt wird und in der Mitte vom OB1 auf 10, dann liest PUT bei 400/1500 vermutlich 50/50 mal 0 mal 10, bei 300er immer 10)
Interessant in dem Zusammenhang auch noch die Datenkonsistenz. D.H. nicht alle Variableninhalte müssen aus dem selben OB1 Zyklus stammen, wenn ich z.B. mehr als 64Byte mit PUT lese. Wenn hier nen REAL-Wert z.B. vom Byte62 bis 65 reicht, kann da auch abundzu mal Quatsch (ein nicht gültiger Real-Wert) ankommen...

Daher die Frage.

 

[DeltaMikeAir]

Ok, ich habe die Frage missverstanden. Eine interessante Frage, ich kann sie nicht beantworten aber es würde mich auch interessieren,
wie das genau funktioniert und evtl. die Unterschiede ( 300/400/1200/1500 ).

 

[JesperMP]

Bei 400, 1200, 1500 nur für jeweils eine Variable konsistent.

Sehr gefährlich !
Selbst wenn man denkt, die Daten sind konsistent wenn das DONE bit gesetzt ist, in die Realität kommt es ein Gemisch von alte und neue Daten.
Noch ein Grund auf PUT/GET zu verzichten, besonders bei S7-1500.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sehr gefährlich !
Noch ein Grund auf PUT/GET zu verzichten, besonders bei S7-1500.

Naja, bei BSEND/BRCV ist es ja auch erstmal nicht besser, es sei denn, mann baut noch DBs dazwischen, wo es nochmal konsistent zwischengespeichert wird.

Bei BSEND/BRCV kann man das aber mit dem Donebit machen, bei PUT/GET nicht, da es im entfernten Partner keinen aufgerufenen Kommunikationsbaustein gibt.

@TE, grundsätzlich läuft es beim entfernten Partner genauso wie beim aktiven PArtner, nur das man eben keinen sichbaren Bausteinaufruf hat sondern das im "Hintergrund" passiert.

gruß.

 

[JesperMP]

Naja, bei BSEND/BRCV ist es ja auch erstmal nicht besser, es sei denn, mann baut noch DBs dazwischen, wo es nochmal konsistent zwischengespeichert wird.

Bei BSEND/BRECV hat man ja aber diese Möglichkeit die Daten selber su puffern. Bei PUT/GET hat man kein Möglichkeit, weil man kann ja nicht wissen wenn der Partner die Daten schreibt bzw. lest. Dafür wäre es wichtig dass die Konsistenz integriert ist.

 

[ducati]

Bei PUT/GET hat man kein Möglichkeit, weil man kann ja nicht wissen wenn der Partner die Daten schreibt bzw. lest. Dafür wäre es wichtig dass die Konsistenz integriert ist.

an irgend ner Anlage hab ich mal am Anfang und Ende des zu übertragenden DBs einen Zählwert mitgeschickt. D.h. die Empfangenen Daten sind "konsistent" wenn der Zählwert am Anfang/Ende identisch sind.

gruß.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

(gelöscht)

 

[JesperMP]

an irgend ner Anlage hab ich mal am Anfang und Ende des zu übertragenden DBs einen Zählwert mitgeschickt. D.h. die Empfangenen Daten sind "konsistent" wenn der Zählwert am Anfang/Ende identisch sind.

Aha !
Genau dass habe ich auch bei andere proprietäre Protokoll ohne garantierte Konsistenz.

edit: Selbst beim 'moderne' Verfahren wie OPC ist das Problem noch relevant.
Dann muss man mit die obengenannte Zähler spielen, oder eine Verzögerung reinmachen wenn die Zähler nur am Anfang gibts. Ich finde dass es ist schwierig die andere Programmierer zu überzeugen dass sie müssen die Zähler doppelt machen.

 

[ducati]

Ich finde dass es ist schwierig die andere Programmierer zu überzeugen dass sie müssen die Zähler doppelt machen.

Naja, die viele verstehn vermutlich garnicht, was wir hier meinen

In den meisten Fällen brauche ich auch keine Konsistenz. Nur wie oben schon geschrieben, wenn eine REAL-Zahl zur Hälfte aus dem alten OB1-Zyklus und die andere Hälfte aus dem neuen OB1-Zyklus stammt, dann kommt halt abundzu eine nicht gültige Realzahl dabei raus, und die macht richtig Ärger. Hatte ich mal und das hat ewig gedauert, den Fehler zu finden.

Gruß.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

https://support.industry.siemens.com/cs/at/de/view/78028908

ja, bei 300er mit CP 32 Byte, bei integrierter Schnittstelle 64 Byte bis zu 240 Byte, ja nach CPU.

Bei 400, 1200, 1500 nur für jeweils eine Variable konsistent.

Seite 41.

Also ich habe das vor einiger Zeit mal bei einer 1200er getestet, und konnte dort über Put keine Transportgröße DWord konsistent schreiben:

https://www.sps-forum.de/hmi/75491-s7-datenkonsistenz-bei-hmi-kommunikation-3.html#post526024

 

[JanB1]

@TE, grundsätzlich läuft es beim entfernten Partner genauso wie beim aktiven PArtner, nur das man eben keinen sichbaren Bausteinaufruf hat sondern das im "Hintergrund" passiert.

Ja, die Frage war ja halt wann genau das GET abgearbeitet wird. Ob ein anstehendes GET eine Art interrupt zur Folge hat, ob es am Anfang, am Ende oder irgendwo dazwischen bearbeitet wird.

Also ich habe das vor einiger Zeit mal bei einer 1200er getestet, und konnte dort über Put keine Transportgröße DWord konsistent schreiben:

Ach du Sch...
Aber das von ducati verlinkte Dokument sagt ausdrücklich "Die CPU garantiert die Datenkonsistenz für eine Variable" für S7-1500, und ein ähnlicher Satz für die S7-1200. Das sollte also eigentlich nicht passieren...

https://support.industry.siemens.com/cs/at/de/view/78028908
ja, bei 300er mit CP 32 Byte, bei integrierter Schnittstelle 64 Byte bis zu 240 Byte, ja nach CPU.
Bei 400, 1200, 1500 nur für jeweils eine Variable konsistent.
Seite 41.

Okay, das Handbuch hatte ich auch schon offen, aber den Teil hatte ich wohl überlesen.

---

Ich fasse zusammen: wann genau ein GET in der entfernten CPU (also nicht in der CPU, in der sich der GET-Baustein befindet) abgearbeitet wird, ist nicht ganz klar.
Klar ist jedoch, dass die Datenkonsistenz nicht gewährleistet werden kann, wenn ein grösserer Datenbereich kopiert wird.
Hier müssen also entsprechende programmiertechnische Massnahmen getroffen werden, um die Datenkonsistenz sicherzustellen, sollte dies von nöten sein.
Siemens empfiehlt hier nur auf den Sende- und Empfangsbereich zuzugreifen, wenn die entsprechenden Bausteine das "Done"-Signal ausgeben. Dies funktioniert aber natürlich nur, wenn auch ein Baustein vorhanden ist, der dieses DONE liefert. Für die entfernte CPU also nicht anwendbar.
Ducati hat den Vorschlag gemacht, am Anfang und Ende des Datenbereichs einen Zähler einzufügen. Die lokale CPU prüft dann, ob dieser Zähler, der aus der entfernten CPU ausgelsen wurde, übereinstimmt. Ist dies nicht der Fall, so sind die Daten nicht konsistent.
Ich habe mich aktuell mit dem anderen Programmierer, mit dessen CPU ich Daten über PUT/GET austauschen muss, geeinigt, dass wir einfach kein GET verwenden. Somit kann sichergestellt werden, dass die Daten nicht in einem ungünstigen Zeitpunkt in der entfernten CPU ausgelesen werden. Die entfernte CPU löst dann ein PUT aus, wenn die Daten vorbereitet sind, und verändert die Daten nicht mehr, bis das PUT abgeschlossen ist.

Die Frage, zu welchem Zeitpunkt denn eigentlich ein GET in der entfernten CPU ausgeführt wird bleibt jedoch und die Antwort fände ich sehr interessant.

 

[ducati]

Ich habe mich aktuell mit dem anderen Programmierer, mit dessen CPU ich Daten über PUT/GET austauschen muss, geeinigt, dass wir einfach kein GET verwenden. Somit kann sichergestellt werden, dass die Daten nicht in einem ungünstigen Zeitpunkt in der entfernten CPU ausgelesen werden. Die entfernte CPU löst dann ein PUT aus, wenn die Daten vorbereitet sind, und verändert die Daten nicht mehr, bis das PUT abgeschlossen ist.

Puhh,
PUT finde ich jetzt noch x mal gefährlicher... wenn der entfernte Programmierer sich vertippt, schiebet er die Daten bei Dir in irgendeinen DB! Und PUT ist jetzt m.M. nicht "konsistenter" als GET.
Bei mir ist PUT eigentlich generell "Verboten"

Die Frage, zu welchem Zeitpunkt denn eigentlich ein GET in der entfernten CPU ausgeführt wird bleibt jedoch und die Antwort fände ich sehr interessant.

naja, wie das in der entfernten CPU nun genau bearbeitet wird ist ja schlußendlich egal. Die Frage ist halt, wann es im eigenen DB landet bzw. im entfernten DB rausgeholt wird. Für mich eigentlich klar: bei 300 mindestens 32byte konsistent im Zykluskontrollpunkt. Bei 400/1200/1500 konsistent pro Variable irgendwann während OB1 Zyklus.

Das Problem vom Thomas wäre jetzt aber nochmal auszudiskutieren.

Gruß.