TIA Konvertierung auf S7-1500 CPU

vollmi · 6 Februar 2014

Hallo Ich versuche gerade mein erstes Programm nach 1500 zu migrieren. Und stehe da vor diversen Problemen.
TCON etc. konnte ich soweit schon neu bestücken dass sie funktionieren.

Allerdings habe ich jetzt ein PUT der meine Parameter nicht will.

Code:

#PUT_Instance(REQ:=#sende AND NOT (#PUT_Instance_1.STATUS = 16#0019),              ID:=#SendVerbindungsID,
              DONE=>#put_done,
              ERROR=>#put_error,
              STATUS=>#put_status,
              ADDR_1:=#Befehlsdb,
              SD_1:=#Befehlsdb);

#Befehlsdb ist ein Any am IN des Aufrufenden Bausteins. auf den ich noch ein AT Konstrukt gelegt habe.
Also ANY an IN geht für den neuen PUT schonmal nicht da ADDR_1 und SD_1 INOUTs sind.

Also verschoben nach INOUT in der Schnittstelle des Bausteins. Jetzt wäre SD_1 zufrieden.
Allerdings verlangt ADDR_1 jetzt einen Typ "Remote".
Wenn ich #Befehlsdb jetzt zum Typ Remote mache. Dann wäre ADDR_1 zufrieden, aber SD_1 wieder nicht, der verlangt eigentlich n Variant.

Wie kriege ich jetzt den Pointer von Ausserhalb des Bausteins durch die Schnittstelle an den PUT/GET etc.?

Soll ich für jetzt für jedes Convertierungsproblem einen neuen Tread aufmachen, dass das nachher jeder gut findet, oder machen wir alles in einem?

mfG René

vollmi · 8 Februar 2014

Hat das echt noch keiner herausgefunden?
Ich hab mir mal das Berger Buch zur 1500er bestellt. Hoffe dann steige ich dahinter wie man solche Schnittstellen sauber versorgt

mfG René

shutdown_TIA12 · 8 Februar 2014

wo hast du denn da Buch bestellt? Ist es denn endlich erschienen?

vollmi · 8 Februar 2014

Leider noch nicht erschienen. Hab bei Amazon bestellt. Datum sei 12.2.14. mal schaun.

shutdown_TIA12 · 8 Februar 2014

Habe gesehen, dass man direkt beim Verlag das "Buch" als PDF schon kaufen kann. Ob das stimmt?

PUT und GET habe ich vor nem Jahr mal gemacht. Da gab es paar Sachen zu beachten. Könnte erst Montag wieder was dazu sagen. Aber du kannst ja mal kurz erläutern, was du machen willst.

vollmi · 8 Februar 2014

Ich wollte meinen Baustein den ich zur Datenübertragung an andere CPUs benutze so umschreiben dass er auf der 1500er auch läuft.

Der Baustein benutzt einen PUT zum schreiben eines DB Teils und einen BRECV zum empfang einer von aussen definierten Menge an Daten.

Für Put habe ich also an meinem Baustein am IN einen ANY definiert an dem ich den pointer z.B. P#DB100.dbx0.0 byte 10 angehängt habe.
Am IN habe ich ausserdem noch ein AT aufgelegt um die Datenlänge aus dem Pointer auszulesen und auf einen INT zu kopieren.

diesen ANY habe ich zuvor am PUT an Lokal un Ziel angehängt so dass der DB lokal aus dem gleichen Bereich genommen wird wie er Remote geschrieben wird. So muss man nur einen Pointer an meinem Baustein anhängen welcher dann sowohl Source wie auch Ziel anzeigt. Leider habe ich das bisher noch nicht hingekriegt im 1500er Programm.

Auch ein AT geht nicht wenn ich den ANY wegen der 1500er in den INOUT Bereich verschieben muss. Bei der 300er war das ja nur ein Pointer also nicht nötig den an INOUT zu heften, auch wenn man darauf nachher schreiben wollte. Weil er ja nur angezeigt hab wohin man schreiben wollte.

mfG René

HelleBarde · 9 Februar 2014

Hi vollmi

Warum ist bei dir ADDR_1 und SD_1 gleich?

Der PUT schiebt doch Daten von einer CPU in den Speicher einer anderen. ADDR_1 bezeichnet eine Adresse auf einer anderen CPU. Deswegen hat Siemens hier vermutlich auch einen "neuen Datentyp" erfunden REMOTE. SD_1 adressiert die Daten, die du verschicken willst. Das ist Speicher in der CPU in der dieses Programm läuft. Das ist deswegen vom Typ VARIANT, weil man da auch Daten aus optimierten DB verschicken kann. Wie PUT und die anderen Kommunikations-Bausteine das Kunststück hinbekommen die Strukturen um zu ordnen erstaunt mich, denn in einer AS300 landen auch optimierte Daten nach Standard Layout.

In Step7 V5 hatte der PUT zwei ANY. Und wenn ich nun da als Empfangsadresse DB3.DBX4711.0 WORD 100 angegeben habe, dann hat Step7 V5 einfach ohne mit der Wimper zu zucken ein "Dings".bums draus gemacht. Auch wenn auf der Empfangs-CPU der DB3 den Namen "Puffer" hatte. Das ist für mich ein Fehler in Step7 V5.

TIA-Portal macht das meiner Meinung nach besser. Die Empfangsadresse der Empfangs CPU bekommt einen REMOTE, der im Grunde ja doch nur ein ANY ist, aber weil es sich um eine Adresse auf einer anderen CPU handelt wird nicht nach einem Symbol gesucht. Wenn man einen Input vom Typ ANY macht, und dort ein DB3.DBX4711.0 WORD 100 anlegt, dann versucht auch das TIA-Portal daraus ein Symbol zu machen. Das ist auch ok, denn das ist ja jetzt die CPU auf der das Programm läuft. Aber die Adresse einer anderen CPU auflösen geht nicht.

Vielleicht, könnten sie das wenn die Empfangs CPU ebenfalls in einem TIA-Portal Projekt ist. Dann müssten sie aber irgendwie aus der Verbindungs ID das Projekt ermitteln und dann dieses Projekt aufmachen. Zum Schluss könnte dann wie im Internet eine Adresse der Form //tia-project/PLC_1/Gruppe/"derDB".dings.bums stehen ...

Zurück zu deinem Problem. Das kann nicht gehen! REMOTE ist niemals eine lokale Adresse. Auch wenn du in Step7 V5 zufälligerweise zwei mal den DB3.DBX4711.0 WORD 100 angeben konntest, weil du eben auf beiden CPU den gleichen DB in der gleichen Struktur angelegt hast (also rüber kopiert), so waren das schon immer Adressen auf unterschiedlichen CPUen. Du musst mir zwei Adressen arbeiten.

Eigentlich ist nur ADDR_1 eine Adresse auf der anderen CPU und SD_1 ist eine Variable auf dieser CPU.

'n schön' Tach auch
HB

vollmi · 9 Februar 2014

HelleBarde schrieb:
Hi vollmi

Warum ist bei dir ADDR_1 und SD_1 gleich?

Weil ich normalerweise den QuellDB und den ZielDB in Excel als Datenpunktliste mache und ihn darob nur einmal erstelle.

Der PUT schiebt doch Daten von einer CPU in den Speicher einer anderen. ADDR_1 bezeichnet eine Adresse auf einer anderen CPU. Deswegen hat Siemens hier vermutlich auch einen "neuen Datentyp" erfunden REMOTE. SD_1 adressiert die Daten, die du verschicken willst.

Das ist schon richtig. Aber ich will nunmal daten aus dem Lokalen DB3 in den DB3 auf der anderen CPU verschieben. Kann mir doch keiner verbieten auf beiden CPUs den gleichen DB zu benutzen

In Step7 V5 hatte der PUT zwei ANY. Und wenn ich nun da als Empfangsadresse DB3.DBX4711.0 WORD 100 angegeben habe, dann hat Step7 V5 einfach ohne mit der Wimper zu zucken ein "Dings".bums draus gemacht. Auch wenn auf der Empfangs-CPU der DB3 den Namen "Puffer" hatte. Das ist für mich ein Fehler in Step7 V5.

Das stimmt, eigentlich ist das ein Fehler wenn das automatisch so symbolisiert wird. Allerdings ist das ja schon ziemlich ein Zufall wenn der Pointer GENAU zur lokalen Struktur eines DBs passt der aber überhaupt nix mit dem Remoteziel zu tun hat.[/QUOTE]

TIA-Portal macht das meiner Meinung nach besser. Die Empfangsadresse der Empfangs CPU bekommt einen REMOTE, der im Grunde ja doch nur ein ANY ist, aber weil es sich um eine Adresse auf einer anderen CPU handelt wird nicht nach einem Symbol gesucht. Wenn man einen Input vom Typ ANY macht, und dort ein DB3.DBX4711.0 WORD 100 anlegt, dann versucht auch das TIA-Portal daraus ein Symbol zu machen. Das ist auch ok, denn das ist ja jetzt die CPU auf der das Programm läuft. Aber die Adresse einer anderen CPU auflösen geht nicht.

Das ist ja schön und gut. Trotzdem will ich an meinem Baustein irgendwie einen Pointer übergeben, von mir aus ganz Symbollos und ihn an einen PUT oder whatever übergeben.
Oder anders gefragt, wie kriege ich den Pointer aus dem Typ Variant in den Pointer des Typs Remote.
Früher konnte man einen Any ja auch direkt zuweisen z.B. so

#Pointer1 := #Pointer2;

Dass war dann ja wie ein AT Konstrukt.

mfG René

HelleBarde · 9 Februar 2014

Hi René

wie kriege ich den Pointer aus dem Typ Variant in den Pointer des Typs Remote

Das hat S. gestrichen -- also gar nicht!

Vermuteter Hintergrund: VARIANT ist mehr als ANY. Du kannst aus ANY einen Variant machen. Definiere einen INPUT vom Typ Variant, und schreibe einen ANY dran. Aber du kannst eben nicht aus einem VARIANT wieder einen ANY machen. Zumindest jetzt nicht. Vielleicht in der V13. Aber ich glaub es nicht.

Keiner hindert dich daran QuellDB und ZielDB mit der gleichen Nummer und der gleichen Struktur anzulegen. Dann schreibst du an deinen PUT.ADDR_1 eben den ANY des fernen ZielDB und an den PUT.SD_1 eben den QuellDB.element. Und schon klappt das mit der Kommunikation. Sind halt zwei Parameter zu versorgen und nicht einer.

'n schön' Tach auch
HB

NOBS · 29 Januar 2015

Hallo zusammen

Hatte gerade die gleiche Problematik, ich musste eine dynamsierte TCP Kommunikation von einer S7 300 auf eine S7 1500 konvertieren, in welchem dynamsich unterschiedliche Datenbereiche nacheinander abgeholt bzw versendet werden.
Im Prinzip muss man die neuen PUT und GET Funktionsbausteine über einen zusätzlichen FB kapseln, welcher nicht zugriffsoptimiert ist.
Als Eingangsparamter für das RD_1 bzw SD_1 ist ein ANY INOUT und für ADDR_1 ein Remote INOUT Parameter zu verwenden, diese kann man dann vor dem FB Aufruf dynamisch vorbelegen. Dazu hatte ich schon auf einer S7 300 eine Funktion die aus Integer Werten für DB Länge und Offset den Pointer vorbereitet und in einen ANY Pointer schreiben kann, diese Funktion lies sich einfach auf die 1500 portieren.

Gruss

NOBS

TIA Konvertierung auf S7-1500 CPU

vollmi

Level-3

vollmi

Level-3

shutdown_TIA12

Level-1

vollmi

Level-3

shutdown_TIA12

Level-1

vollmi

Level-3

HelleBarde

Level-1

vollmi

Level-3

HelleBarde

Level-1

NOBS

Level-2

Similar threads

Wir schützen deine Privatsphäre