TIA Bearbeitung PUT/GET S7-1500

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

Den Test habe ich damals mit einer S7-1200 mit Firmware 2.2 durchgeführt, die ist ja schon etwas älter. Das müsste man noch mal mit einer aktuellen Firmware oder auch S7-1500er wiederholen. Die Dokumentation von Siemens ist auch insofern nicht eindeutig, als dass es bei Put/Get überhaupt keine Variablen gibt, sondern nur Transportgrößen. Und da der Zielbereich "nicht optimiert" sein muss ist das letztenendes nur ein Byte-Array.

 

[Onkel Dagobert]

Man könnte es ja mal relativ einfach testen, in dem man abwechselnd zwei Bitmuster "getet" und/oder "putet". Kommt irgendwann etwas Vermischtes an, ist die Übertragung inkonsistent. PUT und GET kann man ja auch simulieren, wenn man die Muse dazu hat. Dann stellt sich jedoch wieder die Frage, ob das Ergebnis der Simulation realistisch ist. Ganz schlecht fände ich es, wenn es vom Firmwarestand abhängig wäre, was man aber leider nicht ausschließen kann.

 

[JanB1]

Zuviel Werbung?
-> Hier kostenlos registrieren

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"



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

Die Idee dahinter war, dass das PUT nur dann ausgeführt wird, wenn die sendende CPU "bereit" ist. Das heisst wenn ich neue Daten kriege weiss ich, dass diese Daten neu sind. Alternativ kann man das natürlich mit einem Control-Flag machen, welches aussagt "Neue Daten". Wenn Bit TRUE, dann kann ich damit arbeiten.

Und es ist eben nicht egal, wie die entfernte CPU arbeitet, wenn ich wissen will, wann denn ein GET ausgeführt wird. Ich will ja sicherstellen, dass das GET nicht irgendwo dazwischen ausgeführt wurde, wo die Daten vielleicht gar nicht passen. Das heisst, ich hätte dann das Control-Flag "neue Daten", aber es wurden nur die Hälfte der Daten Konsistent übertragen, da die entfernte CPU noch am schreiben der Daten (in den Kommunikations-DB) war.

Man könnte es ja mal relativ einfach testen, in dem man abwechselnd zwei Bitmuster "getet" und/oder "putet". Kommt irgendwann etwas Vermischtes an, ist die Übertragung inkonsistent. PUT und GET kann man ja auch simulieren, wenn man die Muse dazu hat. Dann stellt sich jedoch wieder die Frage, ob das Ergebnis der Simulation realistisch ist. Ganz schlecht fände ich es, wenn es vom Firmwarestand abhängig wäre, was man aber leider nicht ausschließen kann.

Ich werde das definitiv mal testen. Einfach weil es mich wunder nimmt. Ich werde euch dann meine Ergebnisse mitteilen!

 

[ducati]

Die Idee dahinter war, dass das PUT nur dann ausgeführt wird, wenn die sendende CPU "bereit" ist. Das heisst wenn ich neue Daten kriege weiss ich, dass diese Daten neu sind. Alternativ kann man das natürlich mit einem Control-Flag machen, welches aussagt "Neue Daten". Wenn Bit TRUE, dann kann ich damit arbeiten.

Und es ist eben nicht egal, wie die entfernte CPU arbeitet, wenn ich wissen will, wann denn ein GET ausgeführt wird. Ich will ja sicherstellen, dass das GET nicht irgendwo dazwischen ausgeführt wurde, wo die Daten vielleicht gar nicht passen. Das heisst, ich hätte dann das Control-Flag "neue Daten", aber es wurden nur die Hälfte der Daten Konsistent übertragen, da die entfernte CPU noch am schreiben der Daten (in den Kommunikations-DB) war.



Ich werde das definitiv mal testen. Einfach weil es mich wunder nimmt. Ich werde euch dann meine Ergebnisse mitteilen!

naja, nö...

erstens: mit PUT weisst Du aber in der CPU wo die Daten hingeschrieben/hingeschickt werden, nicht wann/ob es konsistent ist, oder PUT grad im DB was verändert. D.H. Du müsstest am Anfang und Ende nen "Zähler" mitschicken, nur wenn dieser identisch ist, sind die Daten dazwischen auch konsistent.

zweitens: musst Du in der CPU wo Du PUT benutzt die DBs vorher umkopieren, da PUT "parallel" zum OB1 abläuft und da Daten noch während PUT bearbeitet wird, wieder verändert werden könnten.

Das gleiche kannst Du aber mit GET auch machen. In dem zu lesenden DB befindet sich am Anfang/Ende nen Zähler. In der CPU die liest, also wo GET aufgerufen wird, werden die Daten verworfen, wenn der Zähler nicht identisch ist.

Gruß.

PS:

also egal ob PUT oder GET, Du brauchst im Sender und Empfänger jeweils 2 DBs, einen wo PUT bzw. GET drauf zugreift und einen zweiten, wo hin bzw. her kopiert wird (unterbrechungsfrei mit UBLKMOVE) wenn man meint es wäre konsistent, und mit dem dann das SPS-Programm im OB1 weiterarbietet.

 

[JanB1]

Fair enough. I denke so oder so, dass man das immer machen sollte. Also nicht direkt aus dem Kommunikations-DB arbeiten, sondern die Daten immer noch woanders hin kopieren.

---

Man könnte es ja mal relativ einfach testen, in dem man abwechselnd zwei Bitmuster "getet" und/oder "putet". Kommt irgendwann etwas Vermischtes an, ist die Übertragung inkonsistent. PUT und GET kann man ja auch simulieren, wenn man die Muse dazu hat. Dann stellt sich jedoch wieder die Frage, ob das Ergebnis der Simulation realistisch ist. Ganz schlecht fände ich es, wenn es vom Firmwarestand abhängig wäre, was man aber leider nicht ausschließen kann.

Btw, ich hab das mal getestet:
CPU 1515 v2.8
CPU 1511 v2.8
Datenlänge 844 bytes, davon 840 bytes als Bitmuster, jeweils immer abwechselnd 1 Bit TRUE, 1 Bit FALSE.

Ich habe jeweils PUT aufgerufen, und alles in die entfernte CPU kopiert. In der entfernten CPU habe ich über einen mitgeschickten Zähler detektiert, dass neue Daten angekommen sind und habe jedes Bit invertiert.
Mittels GET habe ich in der Lokalen CPU immer nach 100ms (Taktmerker) wieder die Daten aus der entfernten CPU geholt und das Bitmuster verglichen, also ob alle Bits abwechselnd sind.
Das ganze habe ich ein paar zehntausend Mal ausgeführt.
Es ist nie ein Datenfehler aufgetreten.
Wie aussagekräftig das jetzt ist muss jeder für sich entscheiden.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fair enough. I denke so oder so, dass man das immer machen sollte. Also nicht direkt aus dem Kommunikations-DB arbeiten, sondern die Daten immer noch woanders hin kopieren.

---

bei mir kommt es in der Regel nicht auf die Konsistenz über den ganzen DB an, von daher spar ich mir das Umkopieren eigentlich. Aber wenn nen Real mitendrin zerstückelt wird, dann kommt halt abundzu Quatsch raus, deshalb schau ich halt, dass nen REAL nicht auf ner "Grenze" (32 byte 64 byte usw.) liegt.

wo befindet sich denn Dein mitgeschickter Zähler, am Anfang oder Ende des DB? Bei am Ende würde es erklären, warum zumindest mal in der entfernten CPU alles konsistent für den Beginn des Invertierens ist. Für das Lesen mit GET ist der Zähler ja unerheblich.
Das Senden mit PUT ist bezogen auf die lokale CPU ja auch konsistent, da die Daten in der lokalen CPU nicht verändert werden (bis auf den Zähler).

naja, schwierig. PDU Size spielt ja auch noch ne Rolle, interessant vielleicht mal ne sich ändernde REAL-Zahl auf byte 958 zu legen