TIA Daten mit PUT von S7-300 auf S7-1200 senden geht nicht

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber nicht bei einer S7-Verbindung, den Verbindungsaufbau übernimmt bei einer PN-CPU weiterhin das Betriebssystem. Ich habe etliche Anlagen mit 315 PN/DP und 317 PN/DP die sich untereinander nur über S7-Verbindungen rein mit den Put/Get-Funktionen unterhalten.

Eine PN-CPU kann Server und Client für S7-Kommunikation sein, darum ist auch ein aktiver Verbindungsaufbau möglich.
Bestimmte 300er Lean-CPs können hingegen nur S7-Kommunikation als Server, d.h. von dieser Baugruppe ist kein aktiver Verbindungsaufbau möglich. Step7 erkennt das, und meldet einen Fehler wenn man versucht zwischen solchen Stationen eine Verbindung anzulegen. Hat man zwei 300er mit jeweils einem Lean-CP, dann lässt sich keine S7-Verbindung einrichten. Dann muss auf eine andere Verbindungsart gewechselt werden.
Ob das TIA-Portal das auch überprüft weiß ich nicht.

Bei Step7 konnte man sich in NetPro den Verbindungszustand anzeigen lassen. Musst mal gucken obs bei TIA auch sowas in der Art gibt. Dann weiß man zumindest ob der Fehler an den programmierten Put/Get Funktionen liegt, oder schon die Verbindung überhaupt nicht aufgebaut werden kann. Eine Verbindung zu einer 1200er sollte nämlich auch aufgebaut werden können, wenn in dieser beispielsweise alle Datenbausteine optimiert, also Nicht-S7-300/400-kompatibel, angelegt wurden.

Ja, ich sprach über reine TCP-Kommunikation, du hast recht.

 

[HelleBarde]

Hi captainchaos666

Was ist ein "Optimiertem Bausteinzugriff"?

auf der 1200 und der 1500 gibt es zwei Arten von Bausteinen: standard und optimiert. Das bezieht sich sowohl auf die OB, FC und FB als auch auf die DB.

Bei den optimierten FB und den daraus entstehenden DB kann man für jeden Parameter einzeln bestimmen ob dieser retain ist oder nicht. Und dann gibt es noch ein dubioses "Set-in-DB". Das bedeutet, dass du wie bei V5 für die Retain Eigenschaften durch den DB festlegst.

Viel wichtiger als die Festlegung, ob der Wert den Stromausfall überlegt, ist für mich (ja für mich persönlich -- allen anderen ist das total egal) wie schnell man auf die Daten zugreifen kann. Das ist nun wiederum sehr davon abhängig ob du eine 1200 oder eine 1500 hast. Da die 1500 deutlich besser optimiert wird, siehe die Diskussion vom Wochenende (http://www.sps-forum.de/simatic/67616-awl-kop-oder-fup-2.html#post467913), macht es sich dort auch viel stärker bemerkbar. Grobe Richtung bei der 1516, optimierte Daten können 3 mal so schnell gelesen und 6 mal so schnell geschrieben werden wie die Daten in einen standard DB, siehe http://www.sps-forum.de/simatic/67413-db-bereichsabfrage.html#post466269

Bei der 1200 kann man sich die Inhalte der DB beim Laden in die CPU mit dem Wireshark anschauen. Es hat für mich den anschein, als ob die optimierten DB die Daten umsortiert haben. Breitere Datentypen (DWORD,DINT,UDINT,REAL) zuerst, die kürzeren hinterher (BYTE,USINT,SINT). Aber alles innerhalb einer Struktur bleibt zusammen.
Bei standard DB ist das so wie es im Buch von Hans Berger beschrieben ist, also im wesentlichen an Wortgrenzen ausgerichtet.

Was die neuen CPU aber gar nicht mögen, ist wenn man wechselt. Das dauert ewig. Vermutung: die Strukturen werden kopiert/umsortiert. Mir ist allerdings nicht klar wohin. Den Lokaldatenbedarf sieht man nicht :-(

PUT und GET sollte es egal sein, ob die Daten nun aus einem optimierten oder einem standard DB kommen/gehen. Kommen/gehen sie aus einem standard DB, dann werden sie auch genau so verschickt. Kommen sie jedoch aus einem optimierten DB, dann werden sie kopiert/umsortiert bevor sie verschickt werden. Für eine 300 als Kommunikationspartner macht das keinen Unterschied, das Zeug kommt richtig an. Laufzeitmessungen am PUT oder GET konnte ich jedoch nicht machen, denn die Kommunikation ist asynchron und das überdeckt sowieso alle Effekte. Deswegen macht es auch gar nix wenn die optimierten für den PUT/GET umsortiert und kopiert werden. Auch wenn sich zwei 1500 über optimierte Daten unterhalten wird umsortiert. Hat mir Wireshark verraten.

PUT und GET sind asymmetrisch. Die greifen der anderen CPU in den Speicher. Die NSA freut sich. Die CPU auf der du die beiden ausführst ist der Master. Die Daten dort können optimiert oder standard sein. Die andere ist das Opfer. Dort muss ein Server laufen, aber keine Kontakt-Code dafür programmiert werden. Die Adresse dort kann nur standard sein.


Ich bevorzuge TSEND und TRCV. Die sind symmetrisch. Auf beiden Seiten können standard und optimierte Daten verwendet werden. Es muss kein Server auf Empfängerseite laufen. Der Empfänger weiß wann die Daten da sind.

HB

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

PUT und GET sollte es egal sein, ob die Daten nun aus einem optimierten oder einem standard DB kommen/gehen. Kommen/gehen sie aus einem standard DB, dann werden sie auch genau so verschickt. Kommen sie jedoch aus einem optimierten DB, dann werden sie kopiert/umsortiert bevor sie verschickt werden.

Das kann ich nicht nachvollziehen.

Beispiel:
S7-300 ist master und mit einem GET soll ein Bereich eines optimierten DBs aus einer 1200er geholt werden.

wie sagt ich dem GET jetzt wo die zweite Struktur des DB2 auf der 1200er ist?

Normalerweise bildet man das ja entweder in der 300er genau ab. Also die Struktur ist genauso vorhanden wie in der partnercpu. Oder man greift mit einem Pointer zu der sagt die Struktur startet bei Wort 20 und ist 12 Byte lang. Aber die absolute Adresse ist ja in einem optimierten Baustein eigendlich unbekannt. Und das die zweite Struktur im optimierten DB in der 1200er an der absolut gleichen Stelle liegt wie im DB einer 300er wäre ja IMHO auch zufall.

mfG René

 

[Pipboy]

Kommen sie jedoch aus einem optimierten DB, dann werden sie kopiert/umsortiert bevor sie verschickt werden.

Ich bevorzuge TSEND und TRCV. Die sind symmetrisch. Auf beiden Seiten können standard und optimierte Daten verwendet werden.

Das geht aber immer nur genau solang gut, wie du symbolisch adressierst richtig.

Auch wenn sich zwei 1500 über optimierte Daten unterhalten wird umsortiert.

Wenn beide Seiten optimierte DBs haben und man am Adressbereich der Gegenstelle nur Pointer anlegen kann, dann kann das unmöglich gut gehen - oder habe ich da etwas verpasst.

 

[PN/DP]

Ja, heute schreibt unser HB etwas unverständlich ... in mir hatte sich auch zunächst der Widerspruchsgeist gemeldet ...

Doch er meint wohl nicht den Speicherbereich in der remote CPU (der an ADDR drangeschrieben wird und immer in nicht-optimierten Speicherbereichen mit Adresse liegen muß) sondern den in der eigenen CPU (also der, der an SD/RD drangeschrieben wird) - dieser eigene Speicherbereich kann durchaus in optimierten DB liegen. Da aber die Struktur des eigenen optimierten Speicherbereichs wegen der Optimierung real nicht genau der Struktur des remoten Speicherbereichs entspricht müssen die Daten natürlich umsortiert werden - dabei nimmt TIA wohl an, daß die remote Struktur der Struktur des eigenen Speicherbereiches entspricht, wie sie ohne Optimierung wäre (also in Deklarationsreihenfolge mit ggf. Füllbytes wie bei Standard-DB). Ist der eigene Speicherbereich ein unstrukturiertes ARRAY OF BYTE, dann sollte eigentlich keine Umsortierung stattfinden.

Auch wenn sich zwei 1500 über optimierte Daten unterhalten wird umsortiert. Hat mir Wireshark verraten.

Das könnte HelleBarde aber gerne näher erläutern wie er es meint, weil PUT/GET bzw. das Protokoll der S7-Verbindungen den Zugriff auf remote Variablen nur mit symbolischen Namen ohne Adresse gar nicht ermöglichen.

Harald

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist zwar etwas Offtopic, aber vielleicht kann das mal einer erklären, zum besseren Verständnis.

Warum erlauben optimierte DB einen schnelleren Zugriff werden dazu umsortiert.
Letztlich hole ich mit ein Paar Byte aus einem Speicherbereich.
Kann es sein, dass Siemens da so eine Art Datenbank in der SPS hat?

 

[HelleBarde]

Hi all

ja ich geb zu, dass das vielleicht etwas knapp geschrieben war.

GET und PUT hantieren mit drei "Adressen". Die erste ist die Verbindungsadresse. Die zweite ist die lokale Adresse. Die dritte ist die auf der anderen CPU - REMOTE.

Die remote Adresse muss wie schon in Step7 V5 und früher etwas in der Form P#DBa.DBXb.0 type c sein. Warum? Weil man eben einer 300 oder 400 in den Speicher greift und die können nix anderes :-(

Die lokale Adresse kann mit irgendwas versorgt sein. Also auch mit was optimierten. Ja, optimierte DB können nur symbolisch angegeben werden. Ist doch gut so -- warum sollte ich mich unnötigerweise mit P#DBa.DBXb.0 quälen wenn ich "derDB".mitderstrukturiertenVariablen schreiben kann. Und jetzt schaffen es 1200 und 1500 sogar die Daten so auf das Netz zu legen, dass eine 300/400 damit zu recht kommt. Hey, was wollt ihr mehr

Da PUT/GET immer standard Speicher auf der REMOTE Seite annehmen muss auch immer nach standard sortiert werden.

Nutzt man statt PUT/GET die symmetrischen TSEND/TRECV dann kann man zwischen 1200/1500 und 1200/1500 Daten hin und her schicken. Wenn sich zwei 1200 miteinander unterhalten, könnte es ja sein, dass die ohne umsortieren arbeiten, weil auf beiden Seiten optimierte Daten angesprochen werden, geschickter weise der gleiche -- was sage ich -- der selbe Datentyp. Aber die Hoffnung trügt. Wireshark zeigt, dass die Daten im Netz genauso unterwegs sind wie zu einer 300/400. D.h. sie werden zwei mal umsortiert; einmal beim TSEND und nochmal beim TRCV. Kleine Enttäuschung meinerseits.

@Ralle:

Ja auf der 1200/1500 ist eine Art Datenbank. Nimm mal die SD aus der 1500 und stecke sie in einen Kartenleser. Da sind hunderte Dateien drauf. Kopier sie dir auf deinen PC. Steck die Karte wieder in die CPU. Ändere einen Baustein. Z.B. füge in einen FC einen Kontakt ein. Verwende aber ein Tag das es schon gibt. Übersetzen und auf die CPU laden, konsistent natürlich . Nun nimm das Kärtchen wieder aus der CPU und steck sie zurück in den Kartenleser. Vergleiche welche Datei sich geändert hat. Siehe da, es sind nur sehr wenige. Wenn man da mit einem Hex Editor rein schaut, dann findet man sogar welche zum FC gehört.

Nun ändere einen Startwert eines DB. Es ändert sich ein paar mehr, aber nicht alles. Im File zum DB man findet sogar die Stelle des Werte wenn man ein auffälliges Bitmuster verwendet hat. Und es ändert sich wieder reichlich Verwaltungsinformation. Das macht die Suche gerne zu einer nach der Nadel im Heuhaufen.

Nun ändere einen UDT. Jetzt ändern sich viele Files. Wenn ich das richtig zähle, dann gibt es zu jedem Typ, sei es ein richtiger UDT oder nur eine Struktur innerhalb einer anderen ein zusätzliches File. Was da genau drin ist, verstehe ich zwar nicht, aber ich vermute das ist sowas wie eine Datenbank für die Namen, die Typen und die Offsets.

Siemens und Microsoft kochen doch auch nur mit Wasser. Was soll S denn auch anderes tun. Unsere Programme müssen irgendwie auf die CPU und die kann bestimmt nicht mit den Symbolen arbeiten. Also müssen die Symbole schließlich zu profanen Adressen des Controllers werden. Weder Intel noch AMD, noch ARM, noch MIPS, noch IBM, noch Qualcomm bauen symbolische Controller.

'n schönen Tach auch
HB

 

[Thomas_v2.1]

Nutzt man statt PUT/GET die symmetrischen TSEND/TRECV dann kann man zwischen 1200/1500 und 1200/1500 Daten hin und her schicken. Wenn sich zwei 1200 miteinander unterhalten, könnte es ja sein, dass die ohne umsortieren arbeiten, weil auf beiden Seiten optimierte Daten angesprochen werden, geschickter weise der gleiche -- was sage ich -- der selbe Datentyp. Aber die Hoffnung trügt. Wireshark zeigt, dass die Daten im Netz genauso unterwegs sind wie zu einer 300/400. D.h. sie werden zwei mal umsortiert; einmal beim TSEND und nochmal beim TRCV. Kleine Enttäuschung meinerseits.

Siemens hat sich ja (zumindest laut Beschreibung) überlegt die Daten immer irgendwo ("optimiert") im Speicher abzulegen, und dabei die verschiedenen Datentypen (Bool, Byte, Int usw.) zu gruppieren.
Wenn ich jetzt zu einem Partner Daten übertragen will, muss ich natürlich wissen wie mein Telegramm aufgebaut ist, z.B. wenn ich eine Struktur mit Variablen verschiedenen Datentyps verschicken will.
Und jetzt kann ich dank des neuen Konzepts nämlich nur raten und ausprobieren was da übertragen wird, weil a) ich überhaupt nicht mehr weiß wie groß die Struktur im Speicher ist, d.h. was ich am Parameter LEN angeben muss und b) ich nicht mehr sehen kann wo überall Füllbytes eingefügt werden, und c) Siemens bei der jährlichen TIA Runderneuerung da vielleicht was ändert.

So sollte man eigentlich für den Datenaustausch ein Byte-Array anlegen und die Daten aus der Struktur einzeln hineinkopieren. Bedeutet natürlich etwas Mehrarbeit in der Programmierung, aber bei den 1200/1500 eigentlich der einzig gangbare Weg.

Ich kann mir vorstellen, dass diese "optimierte Datenablage" in der SPS ein ordentlicher Performancefresser ist. Bei den meisten anderen Programmiersprachen ist festgelegt, dass wenn ich auf ein Strukturelement zugreifen will, es immer über die Anfangsadresse der Struktur im Speicher plus einen festen Versatz zu erreichen ist. Wenn Siemens die Daten nun auch bei identischen Strukturen immer woanders im Speicher ablegt, muss bei jedem Zugriff auf ein Strukturelement erst geguckt werden wo dieses denn nun aktuell im Speicher abgelegt ist. Beispiel: ein FC dem ich eine UDT als IN-OUT übergebe.
Aber irgendwie muss Siemens das schon angestellt haben, dass eine um fast 20 Jahre neuere Steuerung nicht mindestens Faktor 100 schneller, sondern grade mal gleich schnell ist.

 

[Pipboy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn sich zwei 1200 miteinander unterhalten, könnte es ja sein, dass die ohne umsortieren arbeiten, weil auf beiden Seiten optimierte Daten angesprochen werden, geschickter weise der gleiche -- was sage ich -- der selbe Datentyp. Aber die Hoffnung trügt. Wireshark zeigt, dass die Daten im Netz genauso unterwegs sind wie zu einer 300/400. D.h. sie werden zwei mal umsortiert; einmal beim TSEND und nochmal beim TRCV. Kleine Enttäuschung meinerseits.

Welchen Vorteil würdest du dir davon erhoffen. Das "Umsortieren" ist doch nur die Reihenfolge in der man die Daten an den Stack übergibt. Ich behaupte außerdem, dass die Optimierung auf den ganzen DB gemacht wird und nicht auf einzelne Strukturen begrenzt ist. (Bei "alten" TIA Versionen konnte man mit Pointern oder AT halbwegs sehen was intern draus wird - folgte keinerlei Logik wenn ich mich recht entsinne. Auch die Elemente eines Strings waren völlig durcheinander)
Selbst wenn, die Annahme dass man alle Siemens Gerätschaften zwingen kann gleich zu optimieren ist gelinde gesagt mutig.

Und jetzt kann ich dank des neuen Konzepts nämlich nur raten und ausprobieren was da übertragen wird, weil a) ich überhaupt nicht mehr weiß wie groß die Struktur im Speicher ist, d.h. was ich am Parameter LEN angeben muss und b) ich nicht mehr sehen kann wo überall Füllbytes eingefügt werden, und c) Siemens bei der jährlichen TIA Runderneuerung da vielleicht was ändert.

Solange du symbolisch adressierst ist es doch kein Problem, die Daten werden weiterhin so übergeben als wären sie nicht optimiert am Stück. Len muss dann 0 sein.
Pointer oder AT lässt die V12 auf optimierte DBs überhaupt nicht mehr zu.

 

[LowLevelMahn]

Ja auf der 1200/1500 ist eine Art Datenbank. Nimm mal die SD aus der 1500 und stecke sie in einen Kartenleser.

ich hab hier eine 1211C auf dem Tisch - da ist keine SD drinn

Siemens hat sich ja (zumindest laut Beschreibung) überlegt die Daten immer irgendwo ("optimiert") im Speicher abzulegen,

kann mir kaum vorstellen das damit so viel gewonnen wird - man könnte Blockzugriffe optimieren aber ich sehe das eher als leichtes Werbe-"Druckmittel" um auf Voll-Symbolisch DBs zu wechseln

Aber irgendwie muss Siemens das schon angestellt haben, dass eine um fast 20 Jahre neuere Steuerung nicht mindestens Faktor 100 schneller, sondern grade mal gleich schnell ist.

die Echtzeit,..., Debugging-Code(für online Diagnosen - möglicherweise früher mehr in Hardware) usw. wird auch kosten - es ist ja nicht wirklich vergleichbar mit einem "auskompilierten" C/C++ Code bei dem es dann wirklich völlig symbolbefreiter Code ist,
und es ist ein S7 auf ARM Mapping, passt das 100% oder muss das noch viel zwischen-verarbeitet werden - es wird aber bestimmt wieder lustig wenn die ersten S7 Code auf S71200 Entschlüsselungen beginnen