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

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

Thema: String als Eingangsparameter in DB kopieren

  1. #1
    Registriert seit
    30.07.2007
    Beiträge
    14
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Frage


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Ich möchte einen String[32] in einen DB umkopieren.
    Sowohl den String als auch den Zeiger auf den Zielbereich habe ich als Eingangspameter angelegt. Der Zeiger ist ebenfalls auf einen String[32].

    Wenn ich mir nun den Zeiger in den TEMP-Bereich kopiere und anschließend die SFC20 zum Kopieren aufrufe, erhalte ich den Rückgabewert 16#8124 (Bereichsfehler beim Lesen eines Parameters).


    Kann mir jemand sagen, was ich falsch mache?

    Code:
    FUNCTION_BLOCK FB 999
    TITLE =
    VERSION : 0.1
    
    
    VAR_INPUT
      STR : STRING  [32 ];    
      P_ZIELBEREICH : ANY ;    
    END_VAR
    VAR_TEMP
      P_ANY : BOOL ;    
      TEMP_RETVAL : INT ;    
    END_VAR
    BEGIN
    NETWORK
    TITLE =
    
          LAR1  P##P_ZIELBEREICH; 
          LAR2  P##P_ANY; 
    //;
          L     D [AR1,P#0.0]; 
          T     D [AR2,P#0.0]; 
          L     D [AR1,P#4.0]; 
          T     D [AR2,P#4.0]; 
          L     W [AR1,P#8.0]; 
          T     W [AR2,P#8.0]; 
    //;
          CALL SFC   20 (
               SRCBLK                   := #STR,
               RET_VAL                  := #TEMP_RETVAL,
               DSTBLK                   := #P_ANY);
    END_FUNCTION_BLOCK

    Vielen Dank im Voraus!
    Zitieren Zitieren String als Eingangsparameter in DB kopieren  

  2. #2
    Registriert seit
    15.12.2007
    Beiträge
    712
    Danke
    84
    Erhielt 105 Danke für 94 Beiträge

    Standard

    P_ANY ist als BOOL deklariert

  3. #3
    Bretti ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    30.07.2007
    Beiträge
    14
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Kleiner Fehler beim Herauslösen aus dem Projekt, habe ich korrigiert, das Fehlerbild ist das selbe.

    Code:
    FUNCTION_BLOCK FB 999
    TITLE =
    VERSION : 0.1
    
    
    VAR_INPUT
      STR : STRING  [32 ];    
      P_ZIELBEREICH : ANY ;    
    END_VAR
    VAR_TEMP
      P_ANY : ANY ;    
      TEMP_RETVAL : INT ;    
    END_VAR
    BEGIN
    NETWORK
    TITLE =
    
          LAR1  P##P_ZIELBEREICH; 
          LAR2  P##P_ANY; 
    //;
          L     D [AR1,P#0.0]; 
          T     D [AR2,P#0.0]; 
          L     D [AR1,P#4.0]; 
          T     D [AR2,P#4.0]; 
          L     W [AR1,P#8.0]; 
          T     W [AR2,P#8.0]; 
    //;
          CALL SFC   20 (
               SRCBLK                   := #STR,
               RET_VAL                  := #TEMP_RETVAL,
               DSTBLK                   := #P_ANY);
    END_FUNCTION_BLOCK

  4. #4
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.338
    Danke
    449
    Erhielt 688 Danke für 513 Beiträge

    Standard

    Problem 1: Du zerstörst bei deinem multiinstanzfähingen FB das AR2 im Moment in dem du LAR2 schreibst. Alle STAT-Zugriffe die du nachdem machst gehen nicht mehr
    Problem 2: Beim Kopieren des Pointers aus dem IN bekommst du die falsche Bereichskennung (DB) statt (IDB) - obwohl das nicht direkt einen Fehler verursacht

    [EDIT]
    Problem 3: Der Multiinstanzoffset wurde nirgens auffaddiert.

    Sieh dir mal dazu die Vorlage von PN/DP an.
    http://www.sps-forum.de/simatic/6360...tml#post481732
    Geändert von RONIN (05.08.2015 um 12:00 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  5. #5
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.618
    Danke
    775
    Erhielt 646 Danke für 492 Beiträge

    Standard

    Machst du den Pointer von Hand an die Schnittstelle (P#DB10.dbx0.0 byte 34) oder Symbolisch auf das Stringsymbol?
    Wenn von Hand dann stimmt die länge? also nicht die 2 zusätzlichen Bytes vergessen?

    mfG René

  6. #6
    Bretti ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    30.07.2007
    Beiträge
    14
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Zu Problem 1: Ich habe den FB in ein Test-Projekt (PLCSIM) kopiert, wo nur dieser eine FB aufgerufen wird, im originalen Programm sichere ich mir vorher AR1 und AR2.
    Code:
          TAR1  #AR1_SICHERUNG
          TAR2  #AR2_SICHERUNG
    Am Ende des FB's werden diese zurückgeladen
    Code:
          LAR1  #AR1_SICHERUNG
          LAR2  #AR2_SICHERUNG
    Zu Problem 2: Ich möchte ja in einen DB kopieren, damit sollte doch die Bereichskennung korrekt sein, oder?


    @vollmi: Am Aufruf ist symbolisch. "DB_TEST".Daten.name (34 Byte)
    Geändert von Bretti (05.08.2015 um 11:24 Uhr)

  7. #7
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.338
    Danke
    449
    Erhielt 688 Danke für 513 Beiträge

    Standard

    Zitat Zitat von Bretti Beitrag anzeigen
    Zu Problem 2: Ich möchte ja in einen DB kopieren, damit sollte doch die Bereichskennung korrekt sein, oder?
    Nicht ganz. Zuerst willst du ja den ANY-Pointer aus dem IN-Bereich des FBs nach Temp kopieren (also aus dem Instanzdatenbaustein).
    Es geht um die Bereichskennung wo du den ANY-Pointer her-kopierst. In den Datenwerten (10Byte) des Pointers steht dann schon wieder "DB" drin.

    Da du im Moment aber nur einen Zeiger auf P_ZIELBEREICH in das AR1 lädst, stimmt die Bereichskennung dort noch mit IDB.
    Im Moment kopierst du mittels bereichsübergreifender indirekter Adressierung aus dem IDB

    Wenn du dann (gezwungenermaßen) den Multiinstanzoffset aus AR2 aufaddierst (fehlt bei dir im Moment noch) bekommst du vom AR2 die falsche Kennung die dann beim Aufaddieren +AR1 ins AR1 übernommen wird
    Dass würde dann dazu führen, dass du mittels bereichsübergreifender indirekter Adressierung quasi einen Global-DB-Zugriff auf den DB mit der Nummer des Instanzdatenbausteins machen würdest..

    Hoffe verständlich. Die Details findest du auch noch mal im Beitrag von PN/DP.
    Funktioniert im Endeffekt auch ist aber nicht ganz sauber.

    Fazit: Halte dich beim Kopieren von ANY-Pointern von IN nach TEMP in FBs einfach an die Vorlage von PN/DP, die berücksichtigt das schon.
    Geändert von RONIN (05.08.2015 um 13:05 Uhr) Grund: Korrekturen, Verbesserung der Erläuterung..
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  8. #8
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.338
    Danke
    449
    Erhielt 688 Danke für 513 Beiträge

    Standard

    KLAR dass das nicht geht!
    Zitat Zitat von Bretti Beitrag anzeigen
    Am Ende des FB's werden diese zurückgeladen
    Code:
          LAR1  #AR1_SICHERUNG
          LAR2  #AR2_SICHERUNG
    Das machst du nicht am Ende des FB sondern direkt nach dem kopieren!
    Das Problem ist ja, dass wenn du dein AR2 (Multiinstanzoffset) veränderst, du innerhalb des FB nicht mehr auf IN/OUT/STAT-Parameter zugreifen kannst, sondern irgendwo landest .

    Wenn du das wiederherstellen des AR2 am Ende des FBs machst bringt dir das gar nix mehr!

    Die Ursache für W#16#8124 (1 steht für Paramater 1 - SRCBLK) ist dann logischerweise auch dass der SFC20 keinen korrekten Zugriff auf den im IN-Bereich liegenden String bekommt.
    Da das AR2 zu dem Zeitpunkt falsch ist!

    Das nächste Problem ist: Der Multiinstanzoffset wurde nirgens auffaddiert.

    So geht das was du vor hast problemlos...
    Code:
    FUNCTION_BLOCK FB 999
    TITLE =
    VERSION : 0.1
    
    VAR_INPUT
      STR : STRING  [40 ];    
      P_ZIELBEREICH : ANY ;    
    END_VAR
    VAR_TEMP
      P_ANY : ANY ;    
      SaveAR2 : DWORD ;    
      iTMp : INT ;    
    END_VAR
    
    BEGIN
    NETWORK
    TITLE =
    
          TAR2  #SaveAR2; 
    
          L     P##P_ZIELBEREICH;    // relative Adresse #P_ZIELBEREICH in dieser Instanz (DI) 
          L     #SaveAR2;        // Offset dieser Multiinstanz (DB)
          UD    DW#16#FFFFFF;    // Bereichskennung (DB) die von AR2 mitkommt ausblenden
         +D    ; 
          LAR1  ;            // AR1: absolute Adresse #P_ZIELBEREICH im IDB (DI)
          LAR2  P##P_ANY; 
    
          L     DID [AR1,P#0.0]; 
          T     LD [AR2,P#0.0]; 
          L     DIW [AR1,P#4.0]; 
          T     LW [AR2,P#4.0]; 
          L     DID [AR1,P#6.0]; 
          T     LD [AR2,P#6.0]; 
    
          LAR2  #SaveAR2; 
    
          CALL "BLKMOV" (
               SRCBLK   := #STR,
               RET_VAL  := #iTMp,
               DSTBLK   := #P_ANY);
          NOP   0; 
    
    END_FUNCTION_BLOCK
    Geändert von RONIN (05.08.2015 um 13:06 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  9. Folgende 2 Benutzer sagen Danke zu RONIN für den nützlichen Beitrag:

    Bretti (05.08.2015),vollmi (05.08.2015)

  10. #9
    Bretti ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    30.07.2007
    Beiträge
    14
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Danke, RONIN!!!

    Kann ich das so verstehen, dass ich, wenn ich einen Pointer nach TEMP umkopieren will, immer dieser Methodik anwenden muss?

  11. #10
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.338
    Danke
    449
    Erhielt 688 Danke für 513 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Bretti Beitrag anzeigen
    Danke, RONIN!!!

    Kann ich das so verstehen, dass ich, wenn ich einen Pointer nach TEMP umkopieren will, immer dieser Methodik anwenden muss?
    In einem FB ja, nur dort hat man das Problem mit dem Multiinstanz-Offset und einem Instanzdatenbaustein wo man herkopiert.

    Für einen FC hätte den Eingangsversuch schon gepasst da es diesen Offset dort nicht gibt und da du dir dort das AR2 eigentlich auch nicht zerstören kannst.
    Man kann sich dort also auch das Retten des AR2 sparen.
    Beispiel ANY-Pointer aus FC-IN nach Temp kopieren

    Noch was zum Unterschied bei der Übergabe von Any-Pointern zwischen FB und FC:
    FB: Dort bekommt man den ANY quasi perValue über den IDB in den IN-Bereich übergeben. Der ANY-Pointer wird also tatsächlich im IDB abgelegt.
    FC: Dort bekommt man einen 6-Byte Pointer (quasi perReference) auf den Lokaldaten-Bereich des Bausteins der Den FC aufruft.
    Dieser legt nämlich dort den ANY-Pointer, den man als Parameter angegeben hat, ab. Der FC hat je keinen Speicherbereich um etwas entgegen zu nehmen....

    Hoffe bei dem ganzen Gewirr war jetzt kein Blödsinn dabei...
    Geändert von RONIN (05.08.2015 um 13:38 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

Ähnliche Themen

  1. String kopieren?!
    Von blueColt im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 14.09.2010, 12:53
  2. String Variable kopieren
    Von cindy im Forum Programmierstrategien
    Antworten: 10
    Letzter Beitrag: 25.06.2009, 15:47
  3. Ein String kopieren in einen anderen String
    Von CanYouHelpMe im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 25.09.2008, 17:21
  4. String 20 kopieren in DB
    Von ice6461 im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 24.04.2008, 17:03
  5. String kopieren
    Von dietere im Forum Sonstige Steuerungen
    Antworten: 2
    Letzter Beitrag: 12.02.2008, 12:12

Lesezeichen

Berechtigungen

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