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

Seite 5 von 5 ErsteErste ... 345
Ergebnis 41 bis 47 von 47

Thema: Statische Variablen funktionieren nicht mehr nach LOOP

  1. #41
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.293
    Danke
    932
    Erhielt 3.320 Danke für 2.682 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Da mir aber als aufrufender Baustein bewusst sein muss, dass auch dem aufgerufenen Baustein das AR1 zur Verfügung steht und ich als Aufrufender weiss, dass der Aufgerufene mit Akku, Flags und AR1 tun und lassen darf, was er will, muss ich mich selbst vor Aufruf drum kümmern, dass ich meine Werte rette.
    Stimmt, da hast Du recht. Es ist besser so.
    Meine Erwartung, daß das AR1 unangetastet zurückkommen soll, ist wohl meinen Erfahrungen bei der Assembler-Programmierung von Prozessoren geschuldet.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  2. #42
    Registriert seit
    01.10.2007
    Ort
    Waiblingen
    Beiträge
    3.317
    Danke
    767
    Erhielt 536 Danke für 419 Beiträge

    Standard

    Ich bin jetzt nur noch am Grübeln, wie das innerhalb von Interruptroutinen aussieht. Um Akku und Flags und sicher auch um das AR2 kümmert sich ja das System, wenn z.B. OB35 gestartet oder beendet werden soll. Ich frage mich, wo man das jetzt nachlesen kann, was mit dem AR1 geschieht.

    Es gibt übrigens einen Fall, wo das AR1 bereits durch den Call verbogen wird - da hat dann der aufgerufene Baustein keine Chance mehr, das AR1 unangetastet zu lassen:

    In den folgenden Situationen werden die Inhalte des Adressregisters AR1 und des DB-Registers des
    aufrufenden Bausteins überschrieben:




    Bei Aktualparametern aus

    einem DB




    Nachdem Sie einem Baustein einen Aktualparameter zugeordnet haben,

    der in einem DB gespeichert ist (z. B. DB20.DBX0.2), öffnet STEP 7

    diesen DB (DB 20) und passt dabei den Inhalt des DB-Registers an. Das
    Programm arbeitet im Anschluss an den Bausteinaufruf dann mit dem
    angepassten DB.






    Bei Aufruf von Bausteinen in

    Zusammenhang mit höheren
    Datentypen






    Nach einem Bausteinaufruf aus einem FC, der eine Komponente eines

    Formalparameters eines höheren Datentyps (String, Array, Struct oder

    UDT) an den aufgerufenen Baustein übergibt, wird der Inhalt von AR1
    und des DB-Registers des aufrufenden Bausteins modifiziert.





    Dasselbe gilt bei Aufruf aus einem FB, wenn der Parameter im

    VAR_IN_OUT Bereich des Aufrufers liegt.



    Bei Zugriff auf Komponenten

    höheren Datentyps






    Beim Zugriff eines FB auf eine Komponente eines Formalparameters

    höheren Datentyps im VAR_IN_OUT-Bereich (String, Array, Struct oder

    UDT) verwendet STEP 7 das Adressregister AR1 und das DB-Register.
    Dadurch werden die Inhalte der beiden Register modifiziert.





    Beim Zugriff eines FC auf eine Komponente eines Formalparameters

    höheren Datentyps (String, Array, Struct oder UDT) verwendet STEP 7

    das Adressregister AR1 und das DB-Register. Dadurch werden die
    Inhalte der beiden Register modifiziert.





    Quelle: Handbuch "STEP 7 - Programmieren mit STEP 7" im Lieferumfang der Software, Seite 330 (05/2010, A5E02789665-01), Kapitel 15.8 "Vermeiden von Fehlern beim Aufrufen von Bausteinen"


    Sorry, dass das jetzt ziemlich zerrissen ist - ich hab das aus einer Tabelle des PDF rauskopiert (und bin jetzt ein wenig faul, das auch noch in Form zu bringen).



    EDIT:
    und sicher auch um das AR2 kümmert sich ja das System, wenn z.B. OB35 gestartet oder beendet werden soll.
    ähhhmmmm, nein, nicht sicher. Das AR2 braucht ja erst beim Auftreten eines Call innerhalb des OB35 weggeräumt und danach wiederhergestellt zu werden. Oder?
    Geändert von Perfektionist (08.10.2010 um 12:49 Uhr)

  3. #43
    Registriert seit
    11.05.2005
    Ort
    Baden-Württemberg
    Beiträge
    673
    Danke
    113
    Erhielt 153 Danke für 124 Beiträge

    Standard

    Hi Harald,
    Ich war bisher der Meinung, daß meine Beiträge überwiegend nützlich waren und oft neues nicht allgemein vorhandenes Wissen und Knowhow rüberbringen.
    Dagegen habe ich kein Argument, und suche auch keines.
    Deine Beiträge sind fachlich zu 99,99% richtig, und nie unüberlegt geschrieben.
    Über deine Fachkentnisse brauchen wir nicht zu diskutieren.

    Aber da ist halt die Haarspalterei.
    Was nützt mir ne Aussage wie:
    Das ist nicht ganz richtig.
    Das AR2 ist beim FB-Aufruf DW#16#84000000 = P#DBX0.0 . Später P#0.0 in AR2 schreiben ist genau genommen keine korrekte Restauration.
    Doch zum Glück wird beim Zugriff auf Multi-Instanzdaten die Bereichskennung im AR2 ignoriert und immer durch DIB (16#85..) ersetzt.
    Wen interessiert das?
    Das ist mir viel zu theoretisch.
    Du hast ja mittlerweile selbst geschrieben, dass es doch so funktioniert.
    Ich bin Praktiker.
    Sag mal ehrlich: Hast du das mit dem "DW#16#84000000" auswendig gelernt, oder ausprobiert???
    Ich habe einfach so gepostet.
    Aber ich wusste, dass ne "null" das AR2 restauriert (ohne Multiinstanz).
    Wenn man einen FB schreibt, der nicht als Multiinstanz verwendet werden soll, dann sollte man den auch als "nicht Multiinstanz-fähig" anlegen.
    Netter Nebeneffekt: der MC7-Code des Bausteins wird dann kürzer.
    Das ist auch richtig, aber wer hakt denn den Multiinstanzhaken schon ab???
    Das will ich nicht so allgemein stehen lassen.
    Das AR2 wird beim Aufruf eines anderen FB automatisch gesichert und wieder hergestellt, das AR1 aber nicht.
    Wird nun in einem Baustein A, der AR1 benutzt, ein weiterer Baustein B aufgerufen, der ebenfalls das AR1 benutzt, dann erwarte ich, daß der
    Baustein B das AR1 unverändert an Baustein A zurückgibt - das AR1 also ggf. sichert und restauriert.
    Es kann nicht schaden, Bausteine immer so zu programmieren, daß man bei Nutzung dieser Bausteine nicht erst deren Code durchlesen muß,
    um zu sehen, ob diese mit dem aufrufenden Baustein verträglich sind.
    Dazu erst mal danke am den Perfektionisten.
    Er ist mir zuvor gekommen.
    Aber da hast ja auch schon eingelenkt.

    Eines möchte ich noch mal betonen:
    Ich verwende den im Beispiel genannten Code nicht.
    Aber ich fand die Idee!? nicht schlecht.
    Meine Bausteine sind sauber restauriert.

    Da halt ichs wie Kollege 4L:
    mir ist das ja sowieso alles wurscht, ich schreib FBs grundsätzlich MI-fähig...
    @Perfektionist:
    ähhhmmmm, nein, nicht sicher. Das AR2 braucht ja erst beim Auftreten eines Call innerhalb des OB35 weggeräumt und danach wiederhergestellt zu werden. Oder?
    Ich verstehe nicht genau was du damit meinst.
    Aber ich würde nie Variablen in einem Baustein über AR1 oder AR2 lesen oder beschreiben, bevor ich die AR nicht definiert habe.
    Damit bist du immer aus der theoretischen Kacke raus.
    Das Ganze ist recht ähnlich zu Lokalvariablen, die vor einem lesenden Zugriff beschrieben werden müssen.

    Ansonsten liebe ich es mal ein oder ... Bier zu trinken, gerne auch mit dir Harald.

    Bis dann.

    Micha
    "arbeite klug, nicht hart" - deutsches Sprichwort

  4. #44
    Registriert seit
    01.10.2007
    Ort
    Waiblingen
    Beiträge
    3.317
    Danke
    767
    Erhielt 536 Danke für 419 Beiträge

    Standard

    Zitat Zitat von SPSKILLER Beitrag anzeigen
    Dazu erst mal danke am den Perfektionisten.
    Er ist mir zuvor gekommen.
    Sorry. Da hatte ich nicht die Geduld, auf Deine Reaktion zu warten.

    Zitat Zitat von SPSKILLER Beitrag anzeigen
    @Perfektionist:
    Ich verstehe nicht genau was du damit meinst.
    Zunächst dachte ich, AR2 würde sicherlich beim Auftreten eines Interrupts (z.B. OB35) durch das System, also S7, gesichert und restauriert werden. Dann fiel mir auf, dass dies nicht beim Auftreten bzw. Abschliessen eines Interrupts notwendig ist, sondern es ausreichen würde, wie bei einem normalen Call innerhalb des OB1 das Register AR2 zu sichern und beim Rücksprung zu restaurieren.

  5. #45
    Registriert seit
    29.03.2004
    Beiträge
    5.792
    Danke
    144
    Erhielt 1.706 Danke für 1.238 Beiträge

    Standard

    Zitat Zitat von Perfektionist Beitrag anzeigen
    Zunächst dachte ich, AR2 würde sicherlich beim Auftreten eines Interrupts (z.B. OB35) durch das System, also S7, gesichert und restauriert werden. Dann fiel mir auf, dass dies nicht beim Auftreten bzw. Abschliessen eines Interrupts notwendig ist, sondern es ausreichen würde, wie bei einem normalen Call innerhalb des OB1 das Register AR2 zu sichern und beim Rücksprung zu restaurieren.
    Das habt ihr doch vor zwei Jahren schon ausdiskutiert:
    http://www.sps-forum.de/showthread.php?t=21473
    Siemens FAQ gibts sogar auch, das ist doch was für PN zum Verlinken.

    Dass man bei Alarm-OBs was selber sichern muss wird ja schon was sowas wie eine Urban Legend...

  6. #46
    Registriert seit
    11.05.2005
    Ort
    Baden-Württemberg
    Beiträge
    673
    Danke
    113
    Erhielt 153 Danke für 124 Beiträge

    Standard

    meine späte Reaktion ist auf die schlechte Infrastrucktur in Polen (Ostroleka) zurückzuführen.
    Aber besser hätte ich es ohnehin nicht schreiben können.
    Ich bin Schwabe
    Mit dem Hochdeutsch haben wirs nicht so...

    Ansonsten liegst du 100% richtig.
    "arbeite klug, nicht hart" - deutsches Sprichwort

  7. #47
    Registriert seit
    01.10.2007
    Ort
    Waiblingen
    Beiträge
    3.317
    Danke
    767
    Erhielt 536 Danke für 419 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Perfektionist Beitrag anzeigen
    Werden die Flags automatisch gesichert?
    Für diejenigen Leser, die nicht einen F1-Tastenschlag von dieser Information entfernt sitzen: die Flags (Statusregister), die die Binärverknüpfungen betreffen, werden bei Aufruf und Beendigung eines Bausteins auf Standardwerte gesetzt, sodass grundsätzlich eine neue Verknüpfungskette beginnen kann. Die Flags, die z.B. das Ergebnis von Vergleichsoperationen anzeigen, bleiben jedoch unverändert.

Ähnliche Themen

  1. statische Variablen...
    Von snowleopard1702 im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 08.05.2011, 11:47
  2. Ausgänge der Wago funktionieren nicht mehr
    Von Reto Hasler im Forum CODESYS und IEC61131
    Antworten: 11
    Letzter Beitrag: 22.07.2008, 20:55
  3. Statische Variablen in FB´s
    Von Gerri im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 26.06.2008, 14:34
  4. Antworten: 3
    Letzter Beitrag: 15.08.2006, 11:02
  5. Statische Variablen
    Von Sh4gr4th im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 09.12.2005, 14:45

Stichworte

Lesezeichen

Berechtigungen

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