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

Ergebnis 1 bis 10 von 10

Thema: Konvertierung auf S7-1500 CPU

  1. #1
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.647
    Danke
    788
    Erhielt 654 Danke für 497 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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é
    Zitieren Zitieren Konvertierung auf S7-1500 CPU  

  2. #2
    Avatar von vollmi
    vollmi ist gerade online Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.647
    Danke
    788
    Erhielt 654 Danke für 497 Beiträge

    Standard

    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é

  3. #3
    Registriert seit
    02.04.2013
    Beiträge
    143
    Danke
    7
    Erhielt 22 Danke für 20 Beiträge

    Standard

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

  4. #4
    Avatar von vollmi
    vollmi ist gerade online Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.647
    Danke
    788
    Erhielt 654 Danke für 497 Beiträge

    Standard

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

  5. #5
    Registriert seit
    02.04.2013
    Beiträge
    143
    Danke
    7
    Erhielt 22 Danke für 20 Beiträge

    Standard

    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.

  6. #6
    Avatar von vollmi
    vollmi ist gerade online Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.647
    Danke
    788
    Erhielt 654 Danke für 497 Beiträge

    Standard

    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é
    Geändert von vollmi (08.02.2014 um 13:13 Uhr)

  7. #7
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    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

  8. #8
    Avatar von vollmi
    vollmi ist gerade online Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.647
    Danke
    788
    Erhielt 654 Danke für 497 Beiträge

    Standard

    Zitat Zitat von HelleBarde Beitrag anzeigen
    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é

  9. #9
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    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

  10. Folgender Benutzer sagt Danke zu HelleBarde für den nützlichen Beitrag:

    NOBS (29.01.2015)

  11. #10
    Registriert seit
    29.01.2015
    Beiträge
    1
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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

Ähnliche Themen

  1. TIA Dateien per HTTP auf S7-1500 übertragen
    Von DiStra im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 12.08.2013, 13:49
  2. Umstieg auf das TIA Portal und die S7-1500
    Von Grollmus im Forum Werbung und Produktneuheiten
    Antworten: 0
    Letzter Beitrag: 08.08.2013, 09:39
  3. konvertierung von S5 auf S7
    Von leon79 im Forum Simatic
    Antworten: 30
    Letzter Beitrag: 17.02.2007, 22:08
  4. Antworten: 1
    Letzter Beitrag: 14.12.2006, 11:00
  5. Com-Profibus Konvertierung V3.2 auf 5.x Wie?
    Von DerDet im Forum Feldbusse
    Antworten: 6
    Letzter Beitrag: 23.11.2005, 10:18

Lesezeichen

Berechtigungen

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