# Mal wieder: Bereichslängenfehler beim Schreiben...



## harzfuchs (4 Dezember 2008)

Hallo erstmal...
Wie Ihr sehen könnt, bin ich ein "Neuling" hier bei euch im Forum.
Ich lese hier schon eine ganze weile mit, aber nun habe ich auch ein Problem.
Ich habe über die Suche schon einige Beiträge gefunden, die aber keine für mich befriedigende Aussage enthalten.

Nun zum Thema:

Ich habe an einer CPU 317-2 PN/DP einen Bereichslängen Fehler.
Hier mal ein Auszug aus dem Diagnose Puffer:

```
Ereignis 1 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
u.s.w.
```
 
Dieser Fehler trit Zyklisch auf.

Nun habe ich hier im Forum schon einige Kommentare gelesen auf den Button "Gehe Zu" zu klicken, geht aber nicht, da inaktiv.
Auch habe ich schon mitbekommen, das gesagt wurde den OB 121 mal Online zu löschen um die CPU in Stop gehen zu lassen.

Aber. Ist das wirklich die einzige Lösung?

Es handelt sich nähmlich um eine im 24 Stunden Betrieb laufende Anlage,
bei der es nicht so ohne weiteres möglich ist diese zu stoppen.
Das Programm wurde von der Hersteller Firma geschriebn und das ist wohl schon von Anfang an so.

Es hätte ja nicht weiter gestört, aber es ist leider ein Fehler im Profi Bus hinzugekommen den man aber leider uber die CPU mit diesem Fehler nicht Diagnostizieren kann.

Hat einer von euch noch einen anderen Tipp wie ich diesem Fehler sonst noch auf die Schliche kommen kann.


----------



## Rainer Hönle (4 Dezember 2008)

Wie sehen denn die Parameter des OB 121 aus? Steht dort kein sinnvoller Hinweis auf die Fehlerursache drin? Dann einfach diesen entsprechend ausprogramiieren und die Fehlerhinweise retten.


----------



## vierlagig (4 Dezember 2008)

Das ganze klingt mir nach einen Schreibzugriff per Pointer in einen Bereich, der nicht da ist, also einen Datenbaustein, der nicht vorhanden ist oder eine Adresse im DB die nicht definiert ist.

Schau dir mal das Ereignis 2 von 100 an, da sollte IMHO der FC/FB drinnen stehen, aus dem der Zugriff passiert. Dazu dann auch die Bausteinadresse, an der der Fehler ausgelöst wird.

Um die Bausteinadresse im Fehler auslösenden FC/FB zu finden, diesen öffnen, Bearbeiten, Gehe zu..., Bausteinadresse... benutzen.

Desweiteren solltest Du, wenn du den Fehler auslösenden FC/FB gefunden hast und selber nicht weiterkommst, Dich nicht scheuen, den Code hier reinzustellen, dann kann dir gezielter weiter geholfen werden.


----------



## Rainer Hönle (4 Dezember 2008)

Jetzt sind es wieder 4444 !


----------



## harzfuchs (5 Dezember 2008)

vierlagig schrieb:


> Schau dir mal das Ereignis 2 von 100 an, da sollte IMHO der FC/FB drinnen stehen, aus dem der Zugriff passiert. Dazu dann auch die Bausteinadresse, an der der Fehler ausgelöst wird.




Hallo noch mal.
ich werde hier nun mal die ganzen Fehlerliste reinstellen:


```
Diagnosepuffer der Baugruppe CPU 317-2 PN/DP

Bestell-Nr./ Bezeichn.            Komponente                        Ausgabestand                  
6ES7 317-2EK13-0AB0               Hardware                          3                             
- - -                             Firmware                          V 2.6.0                       
Boot Loader                       Firmware-Erweiterung              A 10.12.9                     

Baugruppenträger:                 0
Steckplatz:                       2


Ereignis 1 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.277  26.11.2008


Ereignis 2 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.259  26.11.2008


Ereignis 3 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.244  26.11.2008


Ereignis 4 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.229  26.11.2008


Ereignis 5 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.211  26.11.2008


Ereignis 6 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.193  26.11.2008


Ereignis 7 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.179  26.11.2008


Ereignis 8 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.162  26.11.2008


Ereignis 9 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.143  26.11.2008


Ereignis 10 von 10:  Ereignis-ID 16# 2523
Bereichslängenfehler beim Schreiben 
Global -DB , Bytezugriff, Zugriffsadresse:     48
Angeforderter OB: Programmierfehler-OB (OB 121)
Prioritätsklasse:  1
interner Fehler, kommendes Ereignis
05:57:41.125  26.11.2008
```
Wie man erkennen kann wird nirgends ein Baustein angezeigt.
Leider kann ich so mit den Meldungen reichlich wenig anfangen.



vierlagig schrieb:


> Um die Bausteinadresse im Fehler auslösenden FC/FB zu finden, diesen öffnen, Bearbeiten, Gehe zu..., Bausteinadresse... benutzen.



Wenn ein Baustein angezeigt werden würde, dann hätten wir das auch schon versucht.

Wie ich ja schon geschrieben habe, konnte ich aus anderen Beiträgen hier im Forum schon rauslesen, das uns wohl nur die Möglichkeit bleibt den OB 121 online zu löschen um dann den U- Stack auszulesen.

Leider ist das im Moment schlecht möglich, da wie ich schon geschrieben habe die Anlage im 24 Stunden Betrieb läuft und wir im Moment keinen CPU Stop riskieren können.

Und:



			
				Rainer Hönle schrieb:
			
		

> Jetzt sind es wieder 4444 !



Was soll das bedeuten?


----------



## Rainer Hönle (5 Dezember 2008)

harzfuchs schrieb:


> Wie ich ja schon geschrieben habe, konnte ich aus anderen Beiträgen hier im Forum schon rauslesen, das uns wohl nur die Möglichkeit bleibt den OB 121 online zu löschen um dann den U- Stack auszulesen.
> 
> Leider ist das im Moment schlecht möglich, da wie ich schon geschrieben habe die Anlage im 24 Stunden Betrieb läuft und wir im Moment keinen CPU Stop riskieren können.


Sinnvoller OB121 statt leerer OB121??



> Was soll das bedeuten?


Siehe Thread 4444 http://www.esatex.com/SPS-Forum/showthread.php?t=23562


----------



## blasterbock (5 Dezember 2008)

Du kanst mit "Gehe zu Verwendungsstelle" mit aktiviertem "überlappendem Zugriff" Dein Programm mal kontrollieren, ob irgendwo ein Zugriff stattfindet auf DBD48. Alle Stellen anspringen und kontrollieren, ob der angesprochene DB vorhanden und so lang ist.
Wenn Du Glück hast, ist es ein direkter Schreibzugriff, wenn nicht musst Du mal im Programm nachsehen, wo indirekt auf DB's adressiert wird.

Du kannst die Temp-Variablen des OB86 mal auswerten, obe Du da Informationen über Deinen Profibusfehler bekommst.

Dritte Möglichkeit, im Hardwaremanagere auf Onlinedarstellung schalten, dann bekommst Du auch eine Diagnose zu jedem Teilnehmer, nachdem Du doppelt auf den Teilnehmer geclickt hast.


----------



## dodo (5 Dezember 2008)

In den Temp-Variablen des OB121 gibt es doch die Variable OB!21_BLK_NUM.

Die kann man auslesen, da sollte zumindest drinstehen, in welchem FC/FB der Fehler auftritt!


----------



## harzfuchs (8 Dezember 2008)

Danke erst einmal für eure Tipps

Das mit dem Ob121 und dem Dazugehörigendem DB war eine gute Idee,
nur leider bringt mch das auch nicht weiter.
Der DB sieht folgender massen aus:






Leider keine Anzeige des Fehlerhaften FC/FB.



			
				blasterbock schrieb:
			
		

> ...ob irgendwo ein Zugriff stattfindet auf DBD48...


 
Wenn ich das richtig sehe, dann ist es doch ein Bytezugriff und das Byte wird nirgens beschrieben.
DBD 48 ist nur einmal vorhanden als Lesend gekennzeicnet.

Also noch nicht sehr viel weiter als am Freitag.
Ich versuche immer noch den Programmierer der Anlage ranzubekommen.
Leider bis jetzt ohne erfolg.

Erstmal danke für die Lösungsansätze.

Frank


----------



## vierlagig (8 Dezember 2008)

ist deine CPU teilnehmer eines netzwerkes (Profibus, Ethernet?) und werden daten per PUT und GET ausgetauscht?


----------



## blasterbock (8 Dezember 2008)

Du sagst, dass ein  Zugriff auf das DBD48 stattfindet. Wenn Du an dieser Stelle im Programm nachschaust, welcher DB zu diesem DBD48 gehört, kannst Du feststellen, ob der betreffende DB entsprechend groß (also mindestens bis DBD48 oder DBW50) ausgelegt ist. Wenn nicht, brauchst Du den DB nur entsprechend zu erweitern, um den Fehler auszuschließen.

Beim erweitern bitte daran denken, die Änderung am DB in der Online-Version zu machen, sonst verlierst Du alle Daten aus diesem DB.


----------



## vierlagig (8 Dezember 2008)

mich wundert, dass der zugriff aus dem nichts kommt ... bei allen versuchen, die ich bisher zur fehler reproduktion unternommen habe wurde mir der entsprechende baustein angezeigt ... zugegeben, mit know_how_protect-bausteinen hab ich es noch nicht probiert, aber ich geh einfach mal davon aus, dass selbst dann die bausteinnummer im diagnosepuffer stehen würde.


----------



## harzfuchs (8 Dezember 2008)

vierlagig schrieb:
			
		

> st deine CPU teilnehmer eines netzwerkes (Profibus, Ethernet?)



Das ist eine Idee die ich bis jetzt außer Acht gelassen habe.

Es gibt eine Ethernet Verbindung an der auch einige Mobile Panels dranhängen.

Kann es sein das es von denen kommt wenn diese nicht angesteckt sind.

Leider kann ich die Netzkonfiguration nicht im vollem Umfang hier Posten,
aber ich glaube das ist der Teil auf den es ankommt.





Ich werde mir das Programm nochmal ansehen auf die PUT und GET Befehle hin durchsuchen.

Melde mich wieder...

Edit:

Ich habe mir das Programm noch mal angesehen und habe nur einen GET Befehl (Aufruf SFB14) in einem FB211 gefunden.
Aber das kann ja nicht das Problem sein, da ja sonst der FB 211 oder der SFB14 in der Fehlermeldung stehen müsste.
Außerdem ist das ja ein Lesezugriff...
Ich verstehe das Prinzip nicht...


----------



## vierlagig (8 Dezember 2008)

harzfuchs schrieb:


> Kann es sein das es von denen kommt wenn diese nicht angesteckt sind.



nein, das schließe ich aus. denn wenn sie nicht da sind, schreiben sie ja auch nicht.

möglich wäre:

1. eine steuerung oder panel greift auf einen datenbausteinbereich zu, der nicht definiert ist
2. deine steuerung greift auf einen datenbereich in einer anderen steuerung zu, der nicht definiert ist
3. der 4L irrt sich


----------



## harzfuchs (8 Dezember 2008)

Danke erstmal für deine Hilfe, ich werde das noch mal checken und mich dann noch mal melden.

Schönen Tag noch

Frank


----------



## harzfuchs (7 Januar 2009)

Hallo,

nochmal abschließend zu sagen was nun los war.
Der Programmierer der Anlage hatte einen Programmfehler gemacht den wir so nie gefunden hätten.
Da er sich in seinem Programm sehr gut auskennt :TOOL: hat er natürlich nur ca. 15 Minuten gebraucht um die Stelle zu finden wo er auf diesen Bereich zugegriffen hat.
Es handelte sich hier um eine Indirekte Adressierung.

Noch mal vielen Dank an alle die versucht haben uns hierbei zu helfen.


----------



## Harry (22 August 2009)

Hatte das gleiche Problem und bin folgendermassen vorgegangen um die Programmstelle mit dem Aufruf der nicht existierenden Adresse zu eruieren:

- vor jedem Aufruf einer Funktion (z.B. im OB1) die Funktionsbaustein-Nummer in ein Merkerwort schreiben:

z.B.
_L 155
T MW10_
CALL FC155

_L 131
T MW10_
CALL FC131

etc...

Dann im OB 121:

_L MW10
T MW12_


So konnte durch Anzeige des Inhalts von MW12 ermittelt werden, in welchem Baustein die fehlerhafte indirekte Adressierung war.
Hat man den verantwortlichen FC auf diese Weise ermittelt und ist dieser beispielsweise sehr umfangreich, könnte mit diesem Verfahren innerhalb des FC's die Ursache noch weiter eingegrenzt werden, um den problematischen Befehl zu finden. 

Möglicherweise gibt es eine einfachere Lösung, leider habe ich diese nicht herausgefunden....


----------

