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

Page 1 of 7 123 ... LastLast
Results 1 to 10 of 63

Thread: Problem mit Lokaldaten

  1. #1
    Join Date
    13.01.2009
    Posts
    27
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Leute...

    Ich kämpfe gerade mit einem Problem und taste mich nun langsam zur Ursache vor. Ich hoffe einer von euch kann mir helfen oder mich eventuell auf eine neue Spur bringen.

    Ich habe einen FB geschrieben, welcher sehr viele Lokaldaten (>500Byte) besitzt. Nun rufe ich meinen FB im OB1 auf. Ebenfalls wird die selbe Instanz im OB35 aufgerufen obwohl er dort keinerlei Funktion ausführt.

    OB1 OB35
    CALL FB11,DB99 CALL FB11,DB99
    meine parameter identischer parametersatz

    (Der Hinweis den FB nicht im OB35 aufzurufen, wenn er dort keinerlei Funktion ausführt bringt nicht die Lösung => Der Grund warum mein Baustein im OB1 und OB35 liegt ist, dass wenn ich ihn in einem CFC einbaue er standardmaßig auf OB35 gelegt wird. Der zusätzlich Einbau in OB1 wird über das Attribut S7_tasklist erreicht. Der Aufruf in OB35 ist quasi "ohne nutzen". Ich möchte dem Kunden nur ersparen den Baustein dort löschen zu müssen. Das Problem ist aber nicht PCS7-spezifisch. Ich erreiche das gleiche Verhalten bei reiner AWL-Programmierung.)

    Wird der Baustein aus dem OB35 aufgerufen, erkennt er dieses und macht ein BE. (Diese Implementierung ist überprüft. Der Baustein steigt im OB35 wirklich aus.)


    Arbeitet mein Baustein nun in einem OB1-Zyklus und wird durch den OB35 unterbrochen treten beim fortführen des OB1 Zykluses Fehler auf und das immer an Stellen wo mit Lokaldaten gearbeitet wird.

    L XY
    L AB
    *I
    SLD 3
    LAR1
    TAR1 TEMP0_DWORD

    /*mach irgendwas anderes*/

    LAR1 TEMP0_DWORD
    L 5
    T W[AR1,P#0.0]

    Ich vermute das der Baustein im OB1-Zyklus an der Stelle "mach irgendwas anderes" unterbrochen wird. Danach will er die berechnete Adresse (TEMP0_DWORD) rekonstruieren und diese stimmt nicht mehr und ich hab den Salat. Kann das sein, dass ab einer gewissen Größe es Probleme bei der Rekonstruktion der Lokaldaten nach einem Weckalarm gibt?

    Oder kann es sein das mein Programm nach LAR1 TEMP0_DWORD unterbrochen wird und das Adressregister (welches im OB35 auch geändert wird) nicht mit gesichert und zurückgeschrieben wird? Gravierende Fehler bei der algorithmischen Implementierung schließe ich (vorerst) aus, da keinerlei Probleme auftreten, wenn der Baustein nur im OB1 aufgerufen wird..

    Gibt es eine Möglichkeit zu sehen an welcher Bausteinadresse für den OB35 unterbrochen wurde?

    Das beschriebene Verhalten tritt bei vielen Steuerungssystemen sowohl aus der 300er- als auch der 400er-Serie auf.


    Vielen Dank!
    Reply With Quote Reply With Quote Problem mit Lokaldaten  

  2. #2
    Join Date
    08.08.2007
    Location
    Dresden
    Posts
    9,882
    Danke
    1,064
    Erhielt 2,056 Danke für 1,632 Beiträge

    Default

    ich empfehle dir: sowohl AR1 und AR2 als auch den letzten offenen global-DB zu retten und nach bearbeitung wieder herzustellen ... das löst erstmal das adressregister verschiebe...
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  3. #3
    tobi221081 is offline Neuer Benutzer
    Themenstarter
    Join Date
    13.01.2009
    Posts
    27
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Default

    Hey hallo, vielen Dank für so eine schnelle Antwort.

    Das Problem ist nur, dass der OB1 halt durch einen Weckalarm unterbrochen wird. Innerhalb meines Bausteines im OB1-Zyklus kann ich also nichts retten, da ich ja nicht absehen kann wann genau der Weckalarm zuschlägt.

    Im Baustein innerhalb des OB35 kann ich auch nichts retten, denn ich weiß nicht was der Kunde innerhalb des OB35 "oberhalb" meines Bausteinaufrufes projektiert.

  4. #4
    tobi221081 is offline Neuer Benutzer
    Themenstarter
    Join Date
    13.01.2009
    Posts
    27
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Default

    Um auszuschliessen, dass ich einem fatalen Denkfehler aufsitze, möchte ich noch folgendes abklären.

    Wird mein Baustein im OB1 an der Codezeil X durch den Weckalarm unterbrochen so wird nach der Bearbeitung des Weckalarms an der Codezeile X+1 und nicht am Anfang fortgefahren.

    Stimmt doch oder?

  5. #5
    Join Date
    27.05.2004
    Location
    Thüringen/Berlin
    Posts
    13,804
    Danke
    746
    Erhielt 3,127 Danke für 2,231 Beiträge

    Default

    Es gibt noch den SFC39/40. Mit dem kann man die Weckalarme abschalten und auch wieder einschalten.

    Bei einer S7-300 ist sicherzustellen, daß ein bestimmter Programmteil nicht durch einen Weckalarm (OB-35-Aufruf) unterbrochen wird. Eventuell auftretende Weckalarme sollen nicht nachgeholt werden.
    Wenn du in deinem FB als erstes die Weckalarme sperrst und am Ende wieder zuschaltest oder dies im OB1 vor und nach dem FB tust,würde dieser nicht mehr unterbrochen werden. Ein Versuch ist es sicher Wert.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  6. Folgender Benutzer sagt Danke zu Ralle für den nützlichen Beitrag:

    PoeHel (21.02.2011)

  7. #6
    Join Date
    08.08.2007
    Location
    Dresden
    Posts
    9,882
    Danke
    1,064
    Erhielt 2,056 Danke für 1,632 Beiträge

    Default

    ja, so ist es.

    wenn noch mehr in den OB35 kommt, so rette im NW1 und schreibe im letzten zurück
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  8. #7
    Join Date
    22.03.2007
    Location
    Detmold (im Lipperland)
    Posts
    12,402
    Danke
    422
    Erhielt 2,536 Danke für 2,108 Beiträge

    Default

    Hallo,
    was heißt bei dir "Lokaldaten" ? Daten im STAT-Bereich des FB oder eventuell welche im TEMP-Bereich ?

    Ganz grundsätzlich kann man das machen, was du da tust (ich mache das z.B. bei meinen Kurven-FB's so). Du mußt nur beachten, dass wenn der Aufruf im OB35 etwas ganz anderes macht wie der im OB1, dass du trotzdem ggf. Beeinflussungen verriegeln mußt.

    Gruß
    LL

  9. #8
    tobi221081 is offline Neuer Benutzer
    Themenstarter
    Join Date
    13.01.2009
    Posts
    27
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Default

    Hallo Ralle, hallo vierlagig.

    Also erstmal ein fettes "bin begeistert" an dieses Forum. Die Kommunikation läuft ja fast wie in Echtzeit.

    @Ralle:
    Mit dem Sperren von Alarmen hantier ich gerade rum. Bin gespannt ob der Fehler dann immernoch auftritt. Trotzdem ist dies keine Endlösung.
    Mein Baustein ist halt ein Treiber mit dem der Kunde machen kann, was er gern möchte. Und da wäre es fatal wenn der Treiber grundsätzlich Alarme abschaltet oder zumindest um seine Bearbeitungszeit verzögert.

    @vierlagig:
    Da es sich bei dem Baustein um einen Treiber handelt und nicht "fest zu einem Projekt" gehört, hab ich grundsätzlich nur Einfluss auf den Code innerhalb des Bausteines. Der Kunde kann dann später seine OBs wie wild drum rum projektieren. Deswegen hab ich keinen Einfluss auf die Netzwerke innerhalb des OB35.

  10. #9
    tobi221081 is offline Neuer Benutzer
    Themenstarter
    Join Date
    13.01.2009
    Posts
    27
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Default

    Hallo Larry (Das Spiel hab ich auch schon zu 486er Zeiten gezockt.)

    Ich meine mit Lokaldaten die im TEMP-Bereich. Eine Verriegelung findet auch schon statt. Sobald mein FB merkt, dass er im OB35 liegt macht er ein BE.

    Die Implementierung der Verrieglung ist überprüft und funktioniert. Trotz Verriegelung bleibt das Problem bestehen.
    Last edited by tobi221081; 13.01.2009 at 12:44.

  11. #10
    Join Date
    22.03.2007
    Location
    Detmold (im Lipperland)
    Posts
    12,402
    Danke
    422
    Erhielt 2,536 Danke für 2,108 Beiträge

    Default


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    ... dann haben wir da den Fehler ...
    Der TEMP-Bereich wird von einem Zyklus zum nächsten NICHT gesichert. Wenn du also nicht alles im TEMP-Bereich zunächst zuweisst, dann könnte das schon der Grund sein ...

    Gruß
    LL

Similar Threads

  1. Replies: 8
    Last Post: 09.10.2015, 18:42
  2. Problem mit Lokaldaten
    By Django2012 in forum Simatic
    Replies: 2
    Last Post: 07.08.2012, 18:07
  3. Problem mit Lokaldaten
    By Carsten81 in forum Simatic
    Replies: 30
    Last Post: 22.10.2010, 08:46
  4. Problem mit BLKMOV bei Zugriff auf V-Lokaldaten
    By armadillo in forum Simatic
    Replies: 2
    Last Post: 11.02.2006, 06:38
  5. Problem beim Editieren der temporären Lokaldaten
    By Onkel Dagobert in forum Simatic
    Replies: 0
    Last Post: 08.11.2004, 18:16

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •