SFC14/SFC15 zugriff auf Stukturen im Stat. Bereich von FBs

Markus

Administrator
Teammitglied
Beiträge
6.324
Reaktionspunkte
2.342
Folgeder Code ist aus einem Baustein von Siemens zum ansteuern eines Micromaster über Profibus (FB63)

Code: 
       CALL  "DPRD_DAT"                  // PKW einlesen
       LADDR  :=#P_Adresse
       RET_VAL:=#Intern.Fehler_DP_SFC14_15
       RECORD :=#PKW.EMPFANGEN


PKW ist eine Stuktur im Stat Bereich und enthält die Struktur EMPFANGEN welche zwei INT und einen DINT enthält.

Das läuft problemlos.



In meinem Projekt habe ich auch eine dezentralen Antrieb am Profibus mit dem ich 8 Byte austausche. Folgender Code ist im FB64, der den DB64 als IDB hat.

Code: 
       CALL  "DPWR_DAT"
       LADDR  :=#SteuerStatus_start_Addr
       RECORD :=#Steuerwort
       RET_VAL:=#retval

"Steuerwort" ist eine Struktur im Stat. Bereich des FB64 mit 8 Bytes.
Wenn ich es so mache, dann geht es nicht - Fehlermeldung "Bereichslängenfehler beim lesen(schreiben)"


Mache ich es aber so:

Code: 
       CALL  "DPWR_DAT"
       LADDR  :=#SteuerStatus_start_Addr
       RECORD :="IDB_Servoregler".Steuerwort
       RET_VAL:=#retval

dann geht es! Ich mache nur den DB davor.
Wieso geht das bei mir ohne den DB nicht (den will ich nicht - wegen Instanz FB), aber beim obigen BEispiel vom FB63 von Siemens gehts?
 
Ruft den Siemens da den IDB nicht auch auf?
-> RET_VAL:=#Intern.Fehler_DP_SFC14_15
Wenn ja, dann hätte ich folgende Erklärung
Ich denke dass da der IDB nicht mehr bekannt ist, also AR2 irgend wie verbogen wird.
Abhilfe wäre ein umweg über Lokaldaten.
 
Wie ist denn dein Steuerwort aufgebaut?
Ich habe gerade mal auf die schnelle das Beispielprojekt genommen und eine Testvariable angelegt (Struktur mit 8 Member vom Typ byte) und ich hatte beim simulieren mit PLCSim keine Probleme mit Bereichslängenfehler
 
1. an dem beispiel von siemens wird auch nur auf lokaldaten verwiesen.

2. meine struktur "steuerwort" ist wie geschrieben 8 byte lang (8x 1byte)
(der nama SteuerWORT ist etwas ungünstig gewählt - wird geändert)

3. Retval ist nicht das Problem

5. der editor meckert auch nicht und es lässt sich alles übertragen, aber irgendwie hat das mit der symbolik von "steuerwort" ohne den db mitanzugeben nicht hin. aber "steuerwort" ist doch schon eine lokalvariable (stat)...
 
Ich hab mir das jetzt mal alles durchgelesen. Und muss gestehen, das ich völlig falsch liege.
Aber den Umweg über Temp's sollte dann gehen. Obs sein muss weiss ich nicht. Aber würde ich probieren.
 
möglicherweise geht es über temps, sicher geht es mit dem db vorne dran oder wenn ich einen any rechne und den übergebe.

ABER: WARUM GEHT ES NICHT - BZW NUR BEI MIR NICHT???

in dem ersten Beispiel geht es eben doch!

wie ich das problem umgehen kann ist mir mehrfach bekannt.
aber warum es dieses problem gibt und wie ich es lösen kann, das übersteigt derzeit mein verständniss.

ich halte nichts von "hauptsache es läuft" lösungen!
das ist was für pfuscher!

es muss doch eine logische erklärung dafür geben?
 
Wenn es bis jetzt nur ein testprojekt ist, dann setz es doch mal online damit wir mal gucken können.
 
Fb

Hallo Markus,

wie wärs wenn du vor dem Bausteinaufruf mal den IDB öffnest? Dann weisst du obs davon kommt.

L DINO
T #NR_DI
AUF DB [#NR_DI]

Ich denke dass im ANY-Pointer zum SFC nicht die DI-Nr übergeben wird wenn er direkt auf statische Variablen zeigt. Evtl wird im Siemens-Beispiel irgendwo vorher der DI "aktiviert"

André
 
Ich hab gerade mal ein Projekt rausgekramt. Und da funktioniert das mit STAT's einwandfrei.
Mir bleibt nur der Hinweis mit der Adresse, also angabe Hexadezimal. Aber ich denke das hast du schon so.
 
Hallo Markus,

eigentlich sollte die Variante wie im Siemens-Bsp. funktionieren. Was machst du vor dem Aufruf der SFC15? Verwendest du event. eine Adressierung über Adressregister im FB64? Werden vorher andere Bausteine aufgerufen die irgendwas verbiegen können?


Gruß, Onkel
 
hier der ganze code:

Code: 
      L     #I_LADDR                    // PZD-Daten beginnen 10 Byte später
      +     10
      T     #SteuerStatus_start_Addr
      LAR1  P##Steuerwort
      UN    #I_Freigabe
      =     DIX [AR1,P#1.0]             // Freigabe
      U     #I_Start
      UN    DIX [AR1,P#1.6]             // Stop
      =     DIX [AR1,P#1.2]             // Start
      U     #I_Home_Pos
      =     DIX [AR1,P#1.4]             // MaschinenNull suchen
      UN    DIX [AR1,P#1.6]             // Stop
      UN    #I_Start
      UN    #I_Home_Pos
      =     DIX [AR1,P#1.6]             // Stop
      
      CALL  "DPWR_DAT"
       LADDR  :=#SteuerStatus_start_Addr
       RECORD :=#Steuerwort         // so gehts nicht!!!!!!
       RET_VAL:=#retval
      
      CALL  "DPRD_DAT"
       LADDR  :=#SteuerStatus_start_Addr
       RET_VAL:=#retval
       RECORD :="IDB_Servoregler".Statuswort    // so gehts ???!!!
 
Und wenn du das AR1 einfach mal rettest,
vor der ersten Zeile und dann vor dem SFC Aufruf.

Ich musste mir letztens von HDD sowas erklären lassen,
und das wäre doch imho bei dir auch eine mögliche Erklärung.



Mfg
Manuel
 
böse - und ich dachte mit ar1 kann ich machen was ich will weil das symbol "steuerwort" dem sfc alle notwenigen parameter gibt.

er sollte doch erkennen das es eine lokale stat-var ist und wie groß diese ist...

trotzdem danke!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Similar threads

Lesen und Scheiben von und in den Peripheriebereich
Antworten
12
Aufrufe
8K
MSB
I
Korrekter Aufruf von DPWR_DAT (SFC14) in SCL?
Antworten
7
Aufrufe
9K
iga-graz
I
Simovert Paramter von S7 aus ändern
Antworten
1
Aufrufe
2K
Dotzi
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…