FB der vergleicht um zusätzlichen Ausgang erweitern

[Daimonion]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

Ich habe hier einen FB den mein nicht mehr vorhandener Kollege geschrieben hat. Dieser FB vergleicht zwei eingegebene Stringarrays miteinander.

Er ist recht einfach aufgebaut und hat auch nur ein Netzwerk was so aussieht:

      LAR1  P##A
      LAR2  P##B
      L     D [AR1,P#0.0]
      L     D [AR2,P#0.0]
      ==D   
      SPBN  end0

      LAR1  P##A
      LAR2  P##B
      L     D [AR1,P#4.0]
      L     D [AR2,P#4.0]
      ==D   
      SPBN  end0

      LAR1  P##A
      LAR2  P##B
      L     D [AR1,P#8.0]
      L     D [AR2,P#8.0]
      ==D   
      SPBN  end0

      LAR1  P##A
      LAR2  P##B
      L     D [AR1,P#12.0]
      L     D [AR2,P#12.0]
      ==D   
      SPBN  end0

      LAR1  P##A
      LAR2  P##B
      L     D [AR1,P#16.0]
      L     D [AR2,P#16.0]
      ==D   
      SPBN  end0

      LAR1  P##A
      LAR2  P##B
      L     D [AR1,P#20.0]
      L     D [AR2,P#20.0]
      ==D   
      SPBN  end0

      LAR1  P##A
      LAR2  P##B
      L     W [AR1,P#24.0]
      L     W [AR2,P#24.0]
      ==I   
      SPBN  end0

      CLR   
      =     #oFailure
      SET   
      BE    

end0: SET   
      =     #oFailure
      CLR   
      BE

Vom Prinzio her, schaltet der FB den ENO Ausgang, wenn der Vergleich erfolgreich war.
Nun wollte ich noch einen weiteren Ausgang "oFailure" hinzufügen, der mir geschaltet wird, wenn der Vergleich nicht erfolgreich war. Also habe ich mit meinem bisher erworbenen Wissen die Zeilen

CLR
= #oFailure

und die Zeilen

SET
= #oFailure

an die entsprechenden Stellen geschrieben wie sie auch im oben gezeigten Code sind.

Leider geht mir die CPU immer mit einem Programmierfehler in den Stop und ich weiß leider nicht, wie ich die Zeilen für oFailure schreiben muss, damit es Programmiertechnisch richtig ist.

Könnt ihr mir da auf die Sprünge helfen?
Solltet ihr noch zusätzliche Daten brauchen, dann schreibt einfach.

Vielen Dank im Voraus.

Grüße
Daimonion

 

[Larry Laffer]

... wenn du den FB (in dem Fall an der Schnittstelle) änderst, so mußt du beim Aufruf desselben auch den Instanz-DB neu erzeugen und diesen dann auch an die CPU übertragen (und auch den aufrufenden Baustein).

Gruß
Larry

 

[Daimonion]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das hab ich natürlich gemacht und auch darauf geachtet, dass keine Konflikte mehr existieren. Weiterhin hab ich das an der realen Anlage und aber auch am PLCSIM getestet und nachvollzogen.

 

[Larry Laffer]

Sorry ... außer den genannten Fehler-Möglichkeiten weiß ich sonst nichts mehr. Dann hättest du das auf jeden Fall richtig gemacht.
Was sagt das system den konkret zu dem Fehler und an welche Stelle im Programm verweist dich die Diagnose bei dem Fehler ?

 

[Aventinus]

Du rufst das Ding aber nicht als Multinstanz auf, oder? In dem Fall wäre es sinnvoll mit dem AR2 etwas vorsichtiger umzugehen.

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du rufst das Ding aber nicht als Multinstanz auf, oder? In dem Fall wäre es sinnvoll mit dem AR2 etwas vorsichtiger umzugehen.

selbst bei nicht muliinstanzaufruf verwurschtelt er das AR2
also am anfang speichern TAR2 #dTempAR2 und vor dem zugriff auf #oFailure mit LAR2 #dTempAR2 wiederherstellen

 

[Daimonion]

Okay, das heißt, der Baustein von der eigentlichen Verarbeitung ist verbesserungswürdig. Das nehm ich mal so hin und werde es bei Gelegenheit (nächster Kundenbesuch) so verbessern wie vierlagig beschrieben hat. Das Adressregister vor Abarbeitung sichern und vor verlassen des Bausteins wieder zurückschreiben.
Der Baustein an sich wird nicht als Multinstanz aufgerufen.

Als Fehlermeldung kann ich euch folgendes geben:

Ereignis 2 von 19: Ereignis-ID 16# 4562
STOP durch Programmierfehler (OB nicht geladen oder nicht möglich, bzw. kein FRB vorhanden )
Unterbrechungstelle im Anwenderprogramm: Zyklisches Programm (OB 1)
Prioritätsklasse: 1
FB-Nummer: 310
Bausteinadresse: 184
Bisheriger Betriebszustand: RUN
Angeforderter Betriebszustand: STOP (intern)
interner Fehler, kommendes Ereignis
14:01:38.479 20.05.2011


Ereignis 3 von 19: Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben
Instanz-DB , Bitzugriff, Zugriffsadresse: 78
FB-Nummer: 310
Bausteinadresse: 184
Angeforderter OB: Programmierfehler-OB (OB 121)
OB nicht vorhanden oder gesperrt oder nicht startbar im aktuellen Betriebszustand
interner Fehler, kommendes Ereignis
14:01:38.479 20.05.2011

Edit:

So, ich hab jetzt nochmal den OB121 ausgelesen

FLT_REG sagt: W#16#004E
als Fehler, den ich in der Hilfe nicht finde

OB121_RESERVED_1 sagt: B#16#05
was ein Peripheriefehler auf den Ausgängen sein könnte.

Ich kann mir leider noch keinen genauen Reim auf das Fehlerbild machen. Solltet ihr noch andere Daten brauchen, so sagt bitte bescheid.

Edit2:

So, wenn ich anstelle des #oFailure einen globalen Merker nehme, dann funktioniert der Baustein. Aber wieso kann ich denn in einem Baustein auf diese Weise nicht auf ein Ausgangsbit des FB schreiben?

Edit3:

Wenn ich anstelle eines globalen Merkers das ganze in einen DB schreiben möchte dann stürzt mir der FB zwar nicht ab aber schreiben tut er auch nicht in den FB.

 

[Kai]

1. Multiinstanzfähige FBs

STEP 7 verwendet bei multiinstanzfähigen FBs das Adressregister AR2 als Basisadressregister für die Instanzdaten.

Wenn man in einem multiinstanzfähigen FB das Adressregister AR2 verwenden will, muss man den Inhalt vorher retten und nach der
Verwendung wiederherstellen.

In dem Bereich, in dem man mit dem Adressregister AR2 arbeitet, darf man keinen Zugriff auf Bausteinparameter oder statische
Lokaldaten pogrammieren.

2. Nicht multiinstanzfähige FBs

STEP 7 verwendet bei nicht multiinstanzfähigen FB das Adressregister AR2 nicht.

Bei einem nicht multiinstanzfähigen FB muss in den Eigenschaften des FB der Haken bei Multiinstanzfähigkeit entfernt werden.



Gruß Kai

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

So ... ich habe das gerade mal gegengecheckt ...

Es ist so, wie von 4L beschrieben. AR2 sichern und vor Verwendung von oFailure wieder zurücksichern - dann geht es. Ansonsten geht der Zugriff auf die Instanz-Variable "in die Hose". - Kai hat es ja sehr schön beschrieben ...

Der Merker befindet sich außerhalb der Instanz und wird korrekt adressiert.
Wenn du möchtest, dass es funktioniert solltest du es wie beschrieben machen.
Dann kannst du aber auch gleich die vielen "LAR1 P##A LAR2 P##B" wegmachen - die brauchst du nämlich auch nur einmal (am Anfang). Danach machst du den Rest ja über den Pointer-Offset (P#0.0 , P#4.0 , P#8.0 etc.).

Gruß
Larry

 

[Daimonion]

Vielen Dank für die Erklärungen und die Lösung.

Nachdem ich die Änderungen eingebaut habe funktioniert alles wie gewünscht.

Dann kannst du aber auch gleich die vielen "LAR1 P##A LAR2 P##B" wegmachen - die brauchst du nämlich auch nur einmal (am Anfang). Danach machst du den Rest ja über den Pointer-Offset (P#0.0 , P#4.0 , P#8.0 etc.).

Das hab ich mich auch schon gefragt und du hast mich dann jetzt mit deiner Aussage direkt bestätigt...


Danke nochmal für die Hilfe und ein schönes WE.