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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 20

Thema: S7-400 sfb14/15 put get

  1. #1
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi zusammen

    Ich wollte einen put/get auftrag der bei einer s7 verbindung auf einer 300er einwandfrei läuft auf eine 400er übertragen.
    jetzt das problem.

    Ich erstelle mir einen anypointer mit dem inhalt


    Wenn ich den so anhänge
    Code:
          CALL  #PUT_1
           REQ   :=
           ID    :=#ID_Red
           DONE  :=
           ERROR :=
           STATUS:=
           ADDR_1:=#zDB_1_Send
           ADDR_2:=
           ADDR_3:=
           ADDR_4:=
           SD_1  :=#zDB_1_Send
           SD_2  :=
           SD_3  :=
           SD_4  :=
    Fehler in den Sendebereichszeigern SD_i bezüglich der Datenlänge oder des Datentyps

    wenn ich den pointer absolut angebe.
    Code:
          CALL  #PUT
           REQ   :=
           ID    :=#ID
           DONE  :=
           ERROR :=
           STATUS:=
           ADDR_1:=P#DB2202.DBX0.0 BYTE 40
           ADDR_2:=
           ADDR_3:=
           ADDR_4:=
           SD_1  :=P#DB2202.DBX0.0 BYTE 40
           SD_2  :=
           SD_3  :=
           SD_4  :=
    funktioniert das einwandfrei. Wo liegt denn der Unterschied? Der inhalt ist doch IMHO genau gleich.

    mfG René
    Zitieren Zitieren S7-400 sfb14/15 put get  

  2. #2
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.192
    Danke
    925
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    - der ANY #zDB_1_Send ist in TEMP deklariert?
    - Du könntest mal den IDB löschen und neu generieren lassen und einspielen
    - Du könntest Dir mal bei beiden Versionen den Inhalt von ADDR_1 direkt im IDB anschauen und vergleichen
    - Was steht in den anderen nicht belegten ADDR_i und SD_i im IDB? Das erste Byte sollte die Syntax-ID B#16#10 sein, der Rest alles 0
    - Geht's, wenn Du dem SFB einen eigenen IDB gibst statt Multiinstanz?
    - mal Firmwareversion der CPU checken

    PS: Statt DW#16#84000000 würde ich P#DBX0.0 schreiben, doch das hat mit dem Problem nichts zu tun.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    vollmi (11.09.2014)

  4. #3
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    super. nach komplettem löschen des IDB hatts jetzt funktioniert. Ein Reinit hat es nicht gebracht.

    Gibts eigentlich für die 400er auch ein "C_CNTRL" Derivat? Um die Verbindung selbst abzufragen?

    mfG René

  5. #4
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    Weiteres Problem. Vermutlich aber nicht 400er spezifisch.

    Code:
          L     P##DB_1_Recv
          LAR1  
          L     W [AR1,P#0.0]
          T     #pointing.DB_Nr
    
    
          L     #pointing.DB_Nr
          T     #wDummy
    
    
          CALL  "TEST_DB"
           DB_NUMBER :=#wDummy
           RET_VAL   :=#RetVAL
           DB_LENGTH :=#wDummy
           WRITE_PROT:=#Write_Prot
    Wenn ich diesen Baustein als Multiinstanz zweimal aufrufe. Dann müsste doch im pointer #pointing.DB_Nr den ich im temp deklariert habe den angeschlossenen Any haben? Habe ich was übersehen? denn da steht immer der any vom Baustein der zuvor aufgerufen wird. Mit LAR1 lade ich doch das Adressregister aus dem Akku den ich mit L P##DB_1_Recv schon beschrieben habe. Muss ich trotzdem irgendwo einen Versatz berücksichtigen bei Multiinstanzen?

    mfG René
    Geändert von vollmi (11.09.2014 um 14:40 Uhr)

  6. #5
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.192
    Danke
    925
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Um das Laden der Adresse der TEMP-Variable DB_1_Recv in AR1 ganz deutlich sichtbar zu machen, kann man auch gleich in AR1 laden:
    Code:
          LAR1  P##DB_1_Recv        //lade Adresse der TEMP-Variable 'DB_1_Recv' in AR1
          L     W [AR1,P#4.0]       //wenn DB_1_Recv ein ANY ist, dann steht die DB-Nummer im 5. und 6. Byte
          T     #pointing.DB_Nr
    Der falsche zusätzliche Offset P#0.0 war nur ein Tippfehler hier im Forum?

    Wenn man die Adresse einer TEMP-Variable referenzieren will, dann braucht man keinen Multiinstanz-Versatz. Den braucht man nur, wenn man eine Variable in einer Multiinstanz referenzieren will (IN, OUT, IN_OUT, STAT).

    ALLE Variablen in TEMP müssen VOR dem Lesen beschrieben werden - auch ANY! Vorher kann man nicht sagen, daß irgendein bestimmter Wert in der TEMP-Variable drinsteht - eine Vermutung kann zufällig zutreffen, muß aber nicht. Auch der zweite Aufruf eines Bausteins aus der gleichen Aufrufebene kann sich nicht sicher sein, daß in einer TEMP-Variable ein Wert vom ersten Aufruf drinsteht. Ein Baustein weiß halt nicht, was außerhalb des Bausteins passiert ist, weiß nicht ob er direkt zweimal aufgerufen wurde oder ein anderer Baustein dazwischen war, er weiß noch nichtmal, von wem er aufgerufen wurde und in welcher Aufrufebene.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  7. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    vollmi (11.09.2014)

  8. #6
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    Ich kriegs nicht hin.
    https://dl.dropboxusercontent.com/u/.../MasterCom.AWL

    Hier mal die quelle des Bausteins. Wohlgemerkt alleine funktioniert er eigentlich. Aber sobald ich den Mutterinstanziere greift er bei beiden auf die Adressen des ersten Aufrufs zu.

    Ausserdem habe ich jetzt bei der zweiten slave sps wenn ich die instanz unabhängig mache, das problem dass ich wohl einen db schreiben kann. Aber beim GET bekomme ich ein "Negative Quittung vom Partnergerät. Die Funktion ist nicht ausführbar." keine ahnung wieso dass bei einer tut und bei der anderen nicht.

    Ich beschreib doch die temp pointer unbedingt immer am anfang des zyklus in jedem baustein?

    mfG René

  9. #7
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.726
    Danke
    398
    Erhielt 2.402 Danke für 2.001 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Wenn man die Adresse einer TEMP-Variable referenzieren will, dann braucht man keinen Multiinstanz-Versatz. Den braucht man nur, wenn man eine Variable in einer Multiinstanz referenzieren will (IN, OUT, IN_OUT, STAT).
    Hallo René,
    ich zitiere hier mal Harald ...
    Deine DB's, die du lädtst sind auch IN-Parameter und auf die greifst du mit dem AR1 zu. (Dafür brauchst du also auf alle Fälle das +AR2 für den Pointer)
    Weiter habe ich zunächst noch nicht geschaut ...

    Gruß
    Larry

    Code:
    LAR1  P##DB_1_Recv; 
    +AR2
    L     W [AR1,P#0.0];        
    T     #pointing.DB_Nr;
    Geändert von Larry Laffer (11.09.2014 um 16:43 Uhr)

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

    vollmi (11.09.2014)

  11. #8
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.192
    Danke
    925
    Erhielt 3.292 Danke für 2.661 Beiträge

    Standard

    Oooch, ich hatte Dich so interpretiert, daß DB_1_Recv ein ANY in TEMP ist...

    Achtung! Das Addieren des Multiinstanz-Offset aus AR2 ist nicht ganz trivial.
    siehe mal hier: Pointer auf eine FB-Multiinstanzvariable erstellen Da geht es auch um eine GET-Multiinstanz.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  12. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    vollmi (11.09.2014)

  13. #9
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    Meine Güte. Bald bin ich wieder soweit das ich den Bettel hin und wechsle wieder zu SCL.

    Padawan muss noch viel lernen.

    mfG René

  14. #10
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Also soweit läufts jetzt in der Multiinstanz
    Allerdings habe ich jetzt noch das Problem dass ich von einigen CPUs abgewiesen werde mit "Negative Quittung vom Partnergerät. Die Funktion ist nicht ausführbar."

    Partner sind 315-2pn/dp. Ideen was das sein könnte?

    Okay zurück: ich habs glaub ich. Zuviele Bytes vermutlich im recv

    mfG René
    Geändert von vollmi (12.09.2014 um 07:35 Uhr)

Ähnliche Themen

  1. TIA Get sfb14
    Von SanjaDO im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 24.01.2014, 14:41
  2. Antworten: 8
    Letzter Beitrag: 05.03.2013, 08:25
  3. Antworten: 9
    Letzter Beitrag: 15.12.2010, 12:27
  4. Sfb14
    Von rokb im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 18.02.2010, 13:17
  5. Sfb14 Get
    Von Adenauer im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 13.02.2008, 10:33

Lesezeichen

Berechtigungen

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