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

Seite 5 von 14 ErsteErste ... 34567 ... LetzteLetzte
Ergebnis 41 bis 50 von 140

Thema: Wenn ein PEW als Eingang an einem FC nicht erreichbar ist, wird FC nicht bearbeitet

  1. #41
    Registriert seit
    23.04.2009
    Ort
    Allgäu
    Beiträge
    3.021
    Danke
    235
    Erhielt 859 Danke für 613 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo ducati,

    für die S7-1500 steht meines Wissen auch der Befehl PEEK für eine solche Zuweisung zur Verfügung.
    Ich glaube dann darf der Baustein sogar optimiert sein.
    Gruß
    Paule
    ----------------------------------------------------------------------------
    > manchmal verliert man und manchmal gewinnen die anderen <

  2. #42
    Registriert seit
    29.03.2004
    Beiträge
    5.080
    Danke
    128
    Erhielt 1.479 Danke für 1.089 Beiträge

    Standard

    Vielleicht kann ja jemand mal testen, ob der Fehler auch in SCL/FUP auftritt, oder nur bei AWL.

    Und ob das nur passiert wenn das PEW mit Zugriffsfehler als Parameter übergeben wird, oder auch als letzte Anweisung vor dem Call.
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  3. #43
    ducati ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    09.08.2006
    Beiträge
    3.148
    Danke
    765
    Erhielt 558 Danke für 466 Beiträge

    Standard

    Stefan hatte gleiches Problem beim Aufruf in KOP und Baustein in SCL.
    Beim Zugriff aufs PEW vor dem CALL tritt das Problem nicht auf...

  4. #44
    Registriert seit
    29.03.2004
    Beiträge
    5.080
    Danke
    128
    Erhielt 1.479 Danke für 1.089 Beiträge

    Standard

    Die Erklärung, warum in dem Fall die Funktion nicht aufgerufen wird, wäre auf jeden Fall interessant.
    Ich habe bei der 1200 schon mal versucht etwas über den Befehlssatz der SPS herauszufinden. Es scheint zumindest, dass bestimmte Anweisungen erlauben das EN/ENO-Flag zu setzen, oder auch in Abhängigkeit vom EN-Flag ausgeführt zu werden (d.h. ohne Sprünge). Das ist aber nur aktiv, wenn der Haken bei "ENO automatisch setzen" gesetzt wurde. Diese Option ist bei AWL-Bausteinen jedoch nicht vorhanden.
    Wenn der Call-Befehl jetzt auch an das EN-Flag gekoppelt ist, und bei einem fehlerhaften Zugriff würde dieses zurückgesetzt, dann könnte das eine Ursache sein. Oder da werden irgendwelche Registerinhalte nach dem Aufruf des Fehler-OBs nicht gesichert/zurückgesichert.
    Ich habe mir den erzeugten Code bei der 1500, im Speziellen bei AWL, aber noch nicht angeschaut.

    Beim nächsten Servicepack steht dann wieder nur "das Verhalten beim Zugriff auf Peripherieadressen wurde verbessert".
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  5. #45
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    9.411
    Danke
    799
    Erhielt 2.770 Danke für 2.237 Beiträge

    Standard

    Ich kann mir lebhaft vorstellen, wo der Bug herkommt. Ich glaube nicht, daß der Bug etwas mit dem EN/ENO-Mechanismus zu tun hat. Ich glaube eher, das hat was damit zu tun, daß jede "Hochsprachen"-Quelltext-Anweisung in (jeweils mehrere Maschinenbefehle lange) Sequenzen compiliert wird und es vielleicht nicht sinnvoll ist, bei einem Fehler direkt den nächsten Maschinensprach-Befehl auszuführen, sondern zum Anfang der nächsten Sequenz bzw. "Hochsprachen"-Quelltext-Anweisung zu springen. Allerding besteht ein Baustein-Aufruf aus mehr als einer Sequenz/Teilaufgabe, was die Compilerbauer/-optimierer vermutlich fehlerhaft umgesetzt haben...

    Testet mal folgenden Code:
    Code:
          CALL  "FC01"
           IN_WORD_1:=%EW204:P
           IN_WORD_2:=%EW206:P
    
          NOP 0
    Erzeugt der Code 2 Diagnosepuffereinträge für 2 Peripheriezugriffsfehler?
    Zitat Zitat von Diagnosepuffer
    ... Temporärer CPU-Fehler: Fehler beim Lesezugriff auf Peripherie (E-Adresse 206) in OB 1
    ... Temporärer CPU-Fehler: Fehler beim Lesezugriff auf Peripherie (E-Adresse 204) in OB 1
    Ich vermute, schon der erste Fehler führt zum kompletten Abbruch der CALL-Bearbeitung und es wird keinen zweiten Peripheriezugriffsfehler (zur E-Adresse 206) geben. (was aber "natürlich" falsch wäre)

    Ich vermute, der obige Code wird in etwa solchen fiktiven Maschinencode compiliert:
    Code:
    1    L    PEW204    //PEW204 lesen
    2    T    LW50      // und den Wert auf Parameterstack legen
    3    L    PEW206    //PEW206 lesen
    4    T    LW52      // und den Wert auf Parameterstack legen
    5    L    P#L50.0   //Anfangsadresse des benutzten Parameterstacks
    6    T    PSBP      // in Parameterstack-Basepointer für FC legen
    7    CALL FC1       //FC1 aufrufen
    8    NOP 0
    Wenn jetzt bei der Anweisung in Zeile 1 ein Peripheriezugriffsfehler auftritt, dann wird das Programm unterbrochen, ein Diagnosepuffereintrag erzeugt, dann der OB122 aufgerufen und danach zur Anweisung nach der fehlerhaften Anweisung gesprungen - bei S7-300/400 wäre das die Zeile 2. Bei der S7-1500 haben die Compilerbauer vermutlich so implementiert, daß zur nächsten "Hochsprachen"-Anweisung gesprungen wird - das wäre zur Zeile 8.

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

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  6. #46
    Registriert seit
    29.03.2004
    Beiträge
    5.080
    Danke
    128
    Erhielt 1.479 Danke für 1.089 Beiträge

    Standard

    Ja, das ist auch denkbar. Das müsste man feststellen können, ob es einen Unterschied macht wenn es einer der ersten oder der letzte Parameter ist.

    Bei meiner 1200 an der ich da mal nachgeforscht habe, die allerdings kein AWL kann, gibt es beim Aufruf eines Bausteins einen Call-Frame.

    Beispiel SCL-Quelle:
    Code:
    MW0 := 17476;
    TestFcAddInt(
      IN1:=12,
      IN2:=34,
      OUT=>"MW2"
    );
    MW0 := 17476;
    Und generiert wird so ganz grob (alles meine Interpretation):
    Code:
    SET                #BoolStack@01                                                // Setze Bit <1:OUT>
    MOVE               [WORD] M0, 0x4444                                            // Lade und transferiere <1:OUT, 2:IN>
    CALL               Params#0x0002, 1                                             // Call Befehl einleiten <1:PARAM, 2:NR>
    MOVE               [WORD] #IntStack@03, 0x0C                                    // Lade und transferiere <1:OUT, 2:IN>
    MOVE               [WORD] #IntStack@07, 0x22                                    // Lade und transferiere <1:OUT, 2:IN>
    CALL_EXECUTE                                                                    // Call Befehl ausführen
    MOVE               [WORD] M2, #IntStack@11                                      // Lade und transferiere <1:OUT, 2:IN>
    CALL_FRAME_CLEAR                                                                // Call Befehl abschließen
    MOVE               [WORD] M0, 0x4444                                            // Lade und transferiere <1:OUT, 2:IN>
    RET                #BoolStack@01                                                // Bausteinende <1:IN>
    Wie das ganz genau mit der Parameterübergabe funktioniert habe ich auch nicht nachvollziehen können, ob PEWs anders behandelt werden habe ich noch nicht getestet. Es gibt aber definitiv diese beiden Anweisungen für den Call und Call-Frame-Clear.
    Dann würde bei einem Fehler evtl. aus diesem Call-Frame herausgesprungen.
    Die Genialität einer Konstruktion liegt in ihrer Einfachheit – Kompliziert bauen kann jeder.

    (Sergei Pawlowitsch Koroljow, sowjetischer Konstrukteur von Raketen und Weltraumpionier)

  7. #47
    ducati ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    09.08.2006
    Beiträge
    3.148
    Danke
    765
    Erhielt 558 Danke für 466 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Testet mal folgenden Code:
    Code:
          CALL  "FC01"
           IN_WORD_1:=%EW204:P
           IN_WORD_2:=%EW206:P
    
          NOP 0
    Erzeugt der Code 2 Diagnosepuffereinträge für 2 Peripheriezugriffsfehler?
    Ja, es werden 2 Zugriffsfehler im Diagnosepuffer angezeigt, Baustein wird trotzdem NICHT bearbeitet.

    Gruß.

  8. #48
    ducati ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    09.08.2006
    Beiträge
    3.148
    Danke
    765
    Erhielt 558 Danke für 466 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    S7-1500 habe ich keine, in der S7-300 funktioniert folgendes:
    Code:
          CALL  "MyFC"
           IN_PEW:=PEW204
    
    
    //Im FC "MyFC":
    //  IN: IN_PEW : POINTER
    
          L     P##IN_PEW           //Adresse des FC-IN-Parameters IN_PEW (Typ POINTER)
          LAR1
    
          L     D [AR1,P#2.0]       // Speicherbereich + Adresse aus dem außen angeschalteten POINTER
          LAR1                      //P#P204.0 = 16#80 + 16#000660
    
          L     PEW [AR1,P#0.0]     //lesen des Peripherieeingangs (entspricht: L PEW204)
    //    diese Anweisung löst ggf. den OB122 wegen Peripheriezugriffsfehler aus
    Harald
    Hallo Harald,

    für ein PEW funktioniert der Code soweit auch unter 1500.

    aber:
    Deinige meiner Bausteine werden am Eingang (INTEGER) wahlweise mit PEW, EW, MW, db1.dbw0 oder sogar mit einer Temp.Variablen beschaltet...
    Hast Du ne Idee für "bereichsübergreifende Zeiger" also wo auch der Operandenbereich bzw. auch der DB mit im Pointer übergeben wird?
    Zumindest falls es nicht 30 Zeilen Code werden.

    Auf ne kurzfristige Lösung von Siemens will ich nicht vertrauen.

    Gruß.

  9. #49
    ducati ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    09.08.2006
    Beiträge
    3.148
    Danke
    765
    Erhielt 558 Danke für 466 Beiträge

    Standard

    Zitat Zitat von ducati Beitrag anzeigen
    Deinige meiner Bausteine werden am Eingang (INTEGER) wahlweise mit PEW, EW, MW, db1.dbw0 oder sogar mit einer Temp.Variablen beschaltet....
    Hab jetzt die Lösung für PEW, EW, MW, und Temp. DB ist erstmal egal...

    Code:
          CALL  "MyFC"
           IN_PEW:=PEW204
    
    
    //Im FC "MyFC":
    //  IN: IN_PEW : POINTER
    
          L     P##IN_PEW           //Adresse des FC-IN-Parameters IN_PEW (Typ POINTER)
          LAR1
    
          L     D [AR1,P#2.0]       // Speicherbereich + Adresse aus dem außen angeschalteten POINTER
          LAR1                      //P#P204.0 = 16#80 + 16#000660
    
          L     W [AR1,P#0.0]     //lesen des Wortes
    //    diese Anweisung löst ggf. den OB122 wegen Peripheriezugriffsfehler aus
    Danke Dir.

    Jetzt warte ich mal auf Siemens.

  10. #50
    ducati ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    09.08.2006
    Beiträge
    3.148
    Danke
    765
    Erhielt 558 Danke für 466 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Antwort vom 2.Level Support :

    das von Ihnen beschriebene Verhalten konnten wir bei uns nachvollziehen.
    Für weitere Untersuchungen Ihrer Anfrage haben wir unsere Entwicklung hinzugeschaltet.
    Über den Fortgang der Untersuchung werden wir Sie auf dem Laufenden halten.

    Als Workaround empfehle ich Ihnen direkte Peripheriezugriffe zu meiden. In der S7 1500 liegen sämtliche E/A Module innerhalb des Prozessabbilds bzw. einem TPA. Der Zugriff auf das Prozessabbild ist immer ein definierter Zugriff, es kann dadurch im Anwenderprogramm kein Programmierfehler auftreten.
    wobei bei mir im Anwenderprogramm kein Programmierfehler vorliegt, sondern das entsprechende PEW zur Zeit nur nicht erreichbar ist, weil ich der ET200S die 24V geklaut habe...
    Geändert von ducati (07.10.2016 um 11:19 Uhr)

  11. Folgende 2 Benutzer sagen Danke zu ducati für den nützlichen Beitrag:

    DeltaMikeAir (07.10.2016),Nico1977 (07.10.2016)

Ähnliche Themen

  1. Step 7 In SCL ermittel ob ein FB Eingang belegt ist oder nicht
    Von BlueDogi im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 11.06.2015, 20:35
  2. Hilfe wenn ein Beitrag oder Thema nicht freigeschaltet wird
    Von rostiger Nagel im Forum Stammtisch
    Antworten: 5
    Letzter Beitrag: 04.03.2014, 21:01
  3. Step 7 Bit wird nicht bearbeitet
    Von Der Dreschi im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 26.04.2013, 16:52
  4. Eingang wird nicht bearbeitet
    Von namseg2 im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 11.03.2011, 08:12
  5. Baustein wird nicht bearbeitet
    Von rabit im Forum Simatic
    Antworten: 17
    Letzter Beitrag: 23.09.2010, 10:48

Lesezeichen

Berechtigungen

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