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

Seite 4 von 5 ErsteErste ... 2345 LetzteLetzte
Ergebnis 31 bis 40 von 47

Thema: Statische Variablen funktionieren nicht mehr nach LOOP

  1. #31
    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 vierlagig Beitrag anzeigen
    zur multiinstanzfähigkeit muß noch gesagt werden, dass das AR1 um das AR2 zum bausteinstart erhöht werden muß.
    Dafür Danke. Den Aspekt habe ich zwar irgendwo schonmal gelesen, wäre aber sicher erstmal drüber gestolpert, hätte ichs dann selbst machen sollen. Bislang hab ich halt nur in Nicht-Multiinstanzen rumgepointert. (Vielleicht sollte ich mal wieder die FAQ des Forums durchgehen.)

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

    Standard

    Hallo,

    Und was Deine weiteren Ausflüsse angeht:
    Willst Du nicht am Freitag zum Forum-Stammtisch nach Bielefeld kommen? Da könnten wir schön ein Bier zusammen trinken und Du sagst
    mir mal ins Gesicht, was Dir an mir nicht passt (gut programmieren können ist doch kein Übel).
    Vielleicht kann ich ja mein Auftreten hier noch verbessern.
    ich bin grad in Polen zur IBN.
    Deshalb scheidet der Vorschlag leider aus.
    Ausserdem habe ich nix gegen dich, ich kenn dich doch überhaupt nicht.

    Es kommt bei deinen Beiträgen halt oft der Klugscheisser rüber.
    Das ist meine Meinung.
    Wem das nicht passt, sorry.

    Ich meine hier NIX persönlich.

    Jetzt noch mal fachlich:

    Mit Programmiererfahrung kann man doch nicht wirklich glauben, daß LAR1 + LAR2 hinter LOOP irgendwas sinnvolles bewirkt, außer
    die ARs auf 0 zu schreiben. Mit retten und und wieder herstellen hat das überhaupt nichts zu tun ... es ist noch nicht mal besonders
    kurz, weil komplett überflüssig. Also ich leugne ausdrücklich, daß an solchem Code irgend etwas richtig ist und funktioniert.
    Das hat sehr wohl was mit "wieder herstellen" zu tun.
    In einem FB, der nicht als Multiinstanz aufgerufen wird ist AR2 beim Aufruf 0.
    Wenn das AR2 während der Bearbeitung des FBs verändert wird (im Beispiel hier in der Schleife), dann muss es mit P#0.0 restauriert werden - wenn danach noch auf Instanzdaten zugegriffen werden soll.
    P#0.0 ist auch nur ne 0 im Akku 1, deshalb kann man direkt nach der Schleife einfach LAR2 schreiben um AR2 wieder auf 0 zu setzen.
    AR1 zu retten ist Quatsch. Brauchts nicht.

    Was soll jetzt daran nicht funktionieren

    Es ist nur so wie der Perfektionist geschrieben hat:
    Gut - der Beispielcode, der da die Null in AR2 läd, ist nicht mit voller Absicht entstanden.
    Ich wollte eigentlich nur sagen, dass ich nicht auf die Idee gekommen wäre mein AR2 so zu "nullen". Dazu muss man anders denken.

    Bevor jetzt wieder jemand draufhaut: Klar kann eine Schleife durch einen Sprung verlassen werden, wodurch der Zähler nicht auf 0 runterläuft, aber das interessiert in dem Beispiel nicht.

    @Perfektionist

    Du hast das schon verstanden!
    Aber das Verbiegen des AR2 ermöglicht trotzdem Lokaldatenzugriffe, man kann die Variablen der Instanz aber nur noch indirekt ansprechen...

    Micha
    "arbeite klug, nicht hart" - deutsches Sprichwort

  3. Folgende 2 Benutzer sagen Danke zu SPSKILLER für den nützlichen Beitrag:

    Perfektionist (08.10.2010),PN/DP (08.10.2010)

  4. #33
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    *räusper* ... man muß natürlich sicherstellen, dass der AKKU auch wirlich 0 ist ...
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

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

    Standard

    was soll da in dem Beispiel denn sonst drin stehen?
    "arbeite klug, nicht hart" - deutsches Sprichwort

  6. #35
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    Zitat Zitat von SPSKILLER Beitrag anzeigen
    was soll da in dem Beispiel denn sonst drin stehen?
    in dem beispiel nicht viel, aber soll auch fälle geben, in denen man eine schleife vorzeitig bedingt verlässt ...

    mir ist das ja sowieso alles wurscht, ich schreib FBs grundsätzlich MI-fähig...
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

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

    Standard

    mann, ich hab gewusst, dass das kommt
    Lies mal #32 richtig!
    "arbeite klug, nicht hart" - deutsches Sprichwort

  8. #37
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    Zitat Zitat von SPSKILLER Beitrag anzeigen
    mann, ich hab gewusst, dass das kommt
    Lies mal #32 richtig!
    ja, da ist der verweis auf die 0 nach der schleife drin, aber es ist eben nicht nach jeder schleife 0
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

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

    Standard

    noch mal für dich:
    Bevor jetzt wieder jemand draufhaut: Klar kann eine Schleife durch einen Sprung verlassen werden, wodurch der Zähler nicht auf 0 runterläuft, aber das interessiert in dem Beispiel nicht.
    "arbeite klug, nicht hart" - deutsches Sprichwort

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

    vierlagig (07.10.2010)

  11. #39
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.327
    Danke
    932
    Erhielt 3.332 Danke für 2.690 Beiträge

    Standard

    Zitat Zitat von SPSKILLER Beitrag anzeigen
    ich bin grad in Polen zur IBN.
    Deshalb scheidet der Vorschlag leider aus.
    Das ist schade. Vielleicht laufen wir uns irgendwann mal über den Weg, dann steht mein Angebot mit dem Bier und dem Unterhalten.

    Es kommt bei deinen Beiträgen halt oft der Klugscheisser rüber.
    Tja, das ist schon seit meiner Schulzeit mein Problem, daß andere Leute mein Besser-Wissen und meinen Hang zur Perfektion als Klugscheisserei empfinden.
    Deshalb korrigiere ich andere Leute normalerweise nur noch, wenn ich direkt gefragt werde. Hier im Forum fühle ich mich direkt gefragt.
    Ich war bisher der Meinung, daß meine Beiträge überwiegend nützlich waren und oft neues nicht allgemein vorhandenes Wissen und Knowhow rüberbringen.

    Das ist meine Meinung.
    Wem das nicht passt, sorry.
    Ich habe nicht gesagt, daß mir Deine Meinung nicht passt. Ich habe eher gefragt, was Dir an mir nicht passt. Was Du ja nun beantwortet hast.
    Hier im Forum kann zum Glück jeder seine Meinung schreiben - wenn er das Echo verträgt.

    Ich meine hier NIX persönlich.
    Dies hier klingt aber doch ein bißchen persönlich:
    Zitat Zitat von SPSKILLER Beitrag anzeigen
    Ich hoffe mal, dass dein Image des besten Programmierers unter der Sonne dadurch nicht allzu sehr leidet...

    Jetzt noch mal fachlich:

    Das hat sehr wohl was mit "wieder herstellen" zu tun.
    In einem FB, der nicht als Multiinstanz aufgerufen wird ist AR2 beim Aufruf 0.
    Wenn das AR2 während der Bearbeitung des FBs verändert wird (im Beispiel hier in der Schleife), dann muss es mit P#0.0 restauriert werden - wenn danach noch auf Instanzdaten zugegriffen werden soll.
    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.

    In einem Nicht-Multiinstanz-fähigen FB wird das AR2 gar nicht für den Zugriff auf die Instanzdaten verwendet.
    AR2 kann beliebig manipuliert werden und ein wieder-Herstellen wegen Zugriff auf Instanzdaten ist folglich überflüssig.

    Der Code in einem Multiinstanz-fähigen FB muß imho immer Multiinstanz-verträglich programmiert sein (auch wenn er momentan nicht als
    Multiinstanz verwendet wird), was bei Benutzung des AR2 ein korrektes wieder-Herstellen erfordert.
    Einfach P#0.0 (oder P#DBX0.0) in AR2 schreiben ("ich weiß ja, daß ich diesen Multiinstanz-fähigen Baustein NIE als Multiinstanz benutze") ist
    imho nicht korrekt, auch wenn es in dem speziellen Fall funktioniert.

    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.

    AR1 zu retten ist Quatsch. Brauchts nicht.
    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.

    Ich wollte eigentlich nur sagen, dass ich nicht auf die Idee gekommen wäre mein AR2 so zu "nullen". Dazu muss man anders denken.

    Bevor jetzt wieder jemand draufhaut: Klar kann eine Schleife durch einen Sprung verlassen werden, wodurch der Zähler nicht auf 0 runterläuft, aber das interessiert in dem Beispiel nicht.
    Wenn ich tatsächlich mal das AR2 nach einer Schleife "nullen" wollte oder ganz allgemein an irgendeiner Programmstelle einen bestimmten Wert
    im AKKU1 brauche, aber nicht extra laden will, weil dieser Wert glücklicherweise schon drin steht, dann schreibe ich das Laden dieses Wertes
    als auskommentierte Zeile dazu. Dann beachte ich diese Bedingung, wenn ich später mal den Code ändern muß:
    Code:
          ...
          LOOP  lop1
    //      L     P#0.0       //P#0.0 steht schon im AKKU1
          LAR2
    So, nun aber auf nach Bielefeld.
    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  12. Folgende 2 Benutzer sagen Danke zu PN/DP für den nützlichen Beitrag:

    rostiger Nagel (08.10.2010),Verpolt (08.10.2010)

  13. #40
    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
    Vorweg: es regt sich bei mir der Widerspruchsgeist, obwohl ich 99% von dem Geschriebenen für richtig befinde.
    Zitat Zitat von PN/DP Beitrag anzeigen
    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.
    Werden die Flags automatisch gesichert? Die Akkus werden jedenfalls nicht automatisch gesichert. Das ist sicherlich ein schöner Dienst, den ein FB einem erweisen kann, indem er das AR1 unangetastet lässt. 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.

    Dass das AR2 automatisch gesichert wird ist dem Umstand geschuldet, dass das AR2 dem Anwenderprogramm nicht wirklich zur Verfügung steht. Wenn jemand das AR2 sichert, dann damit hantiert und es danach restauriert, dann hat er sich das AR2 nur vorübergehend vom System ausgeliehen.

  14. Folgende 2 Benutzer sagen Danke zu Perfektionist für den nützlichen Beitrag:

    PN/DP (08.10.2010),SPSKILLER (08.10.2010)

Ä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
  •