Ereignis-ID 16# 2522

blasterbock

Level-1
Beiträge
373
Reaktionspunkte
35
Zuviel Werbung?
-> Hier kostenlos registrieren
An einer CPU 416-2DP, die seit mehreren Jahren störungsfrei läuft, bekomme ich Fehlermeldungen mit der o.a. Nummer.

Ein FC wird 8x im Zyklus aufgerufen, 6x bringt er mir die Fehlermeldung
Ereignis-ID 16# 2522
Bereichslängenfehler beim Lesen
eigene Lokaldaten, Bitzugriff, Zugriffsadresse 1039

Einen Zeigerfehler schließe ich aus, da alle 8 Aufrufe die betroffene Sequenz durchlaufen.

Der Fehler wird auch nicht immer angezeigt.
Nach dem Aussschalten der CPU und einem Neustart läuft das System zunächst wieder zufriedenstellend.

Hat jemand etwas in der Art schon mal beobachtet ?
 
Vielleicht wird ein Wert erhöht und jetzt nach ein paar Jahren kommt es zum Überlauf des Wertes bzw zu einem Fall das ein Pointer in einem zu hohen Bereich eines DB lesen will.

godi
 
Hatte ich letztens ähnlich, nachdem ich den FC neu ins AG übertragen hatte lief alles wieder wie gehabt. Da muß irgendwas (das hab ich nicht rausfinden können) den FC zerblasen haben. Allerdings hatte der Bausteinvergleich keine Abweichung ergeben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...
Ein FC wird 8x im Zyklus aufgerufen, 6x bringt er mir die Fehlermeldung
Ereignis-ID 16# 2522
Bereichslängenfehler beim Lesen
eigene Lokaldaten, Bitzugriff, Zugriffsadresse 1039

Einen Zeigerfehler schließe ich aus, da alle 8 Aufrufe die betroffene Sequenz durchlaufen.
...
scheinbar will er irgendwo in seinen Lokaldatenbereich lesen/schreiben, den es nicht gibt. Setz doch mal den FC online
 
Zuletzt bearbeitet:
...Da muß irgendwas (das hab ich nicht rausfinden können) den FC zerblasen haben. Allerdings hatte der Bausteinvergleich keine Abweichung ergeben.
Ich würde nicht vermuten, daß der Code des FC verändert wurde. Da ein Bereichsfehler auftritt, muß eine falsche Adresse verwendet werden. Ich würde mir ansehen, wie die Adresse zustande kommt, z.B. Berechnung, Indizierung. Eventuell gehen werden Variablen/Speicherstellen verwendet, die niemals initialisiert wurden und über Jahre gnädigerweise 0 waren...
 
Zottel war schneller! Ich tippe auch ganz heftig auf nicht initialisierte Lokalvariablen. Die können jahrelang schlummern, dann macht jemand eine kleine Änderung irgend wo ganz anders und plötzlich spinnt das Programm.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

eine Hilfe eventuell aus dem Baugruppenzustand den Button 'Baustein öffnen' betätigen. Dann wird der Baustein online geöffnet und springt zu der Stelle dei die Meldung erzeugt ( nur in AWL, event. Baustein in AWL umwandeln). An dieser Stelle Zeiger, bzw L(ade) oder T(ranfer) Befehl überprüfen.

Gruß

moz-screenshot-2.jpg
 

Anhänge

  • Baugruppenzustand.JPG
    Baugruppenzustand.JPG
    69,2 KB · Aufrufe: 96
Ich bin überwältigt von so vielen Hilfestellungen.

@vierlagig
Ich hatte über die Stacks bereits herausgefunden, wo der Fehler auftritt.
An dieser Stelle wird ein Bit in den Lokaldaten gesetzt (das sollte ein schreibender Zugriff sein, es wird aber ein Lesefehler gemeldet).

@marlob
Den Zeigerfehler schließe ich aus, da ich direkt auf die Temp-Variable zugreife.

@Ralle+Zottel
In meinen Gedankengängen bin ich ganz nahe bei Euch. Ich hatte auf einen Fehler im internen RAM getippt. Dazu weiß ich aber zu wenig über die interne Speicherverwaltung der Baugruppe.

@RMA
Nicht initialisiert schließe ich aus, da ich das Bit setze.

Nach dem Kaltstart der CPU tritt im Moment der Fehler nicht mehr auf.
 

Anhänge

  • FC704.jpg
    FC704.jpg
    210,5 KB · Aufrufe: 78
Kaltstart alleine scheint keine Dauerlösung zu sein.
Der Fehler trat gestern wieder auf.
Der Baustein wurde jetzt neu auf die CPU geladen.
Mal schauen, ob das hilft.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
I
@vierlagig
Ich hatte über die Stacks bereits herausgefunden, wo der Fehler auftritt.
An dieser Stelle wird ein Bit in den Lokaldaten gesetzt (das sollte ein schreibender Zugriff sein, es wird aber ein Lesefehler gemeldet).
.
Ich könnte mir Vorstellen, daß das Schreiben eines einzelnen Bits der Lokaldaten je nach internem Aufbau der CPU durch einen Read-Modify-Write-Zugriff auf die Word-Adresse, in der das Bit steht, durchgeführt wird. In diesem Fall wird dann zuerst gelesen. Wenn eine Adresse der Lokaldaten nicht existiert:
- Ist diese Adresse fest (z.B. L 12.0) oder wird sie berechnet?
- Steht grundsätzlich genügend Stack zur Verfügung?
- Variiert die Stacktiefe, z.B. durch bedingte Bausteinaufrufe, Bausteinaufrufe in Schleifen, Alarm- und Zeit-OBs, rekursive (sich selbst aufrufende) Bausteine (geht das auf der S7?) ?
 
Die Adresse ist über die symbolische Definition der Temp-Variablen adressiert.
Das Bit wird an zwei Stellen nur über die Symbolik im FC angesprochen (siehe Listing weiter oben). Es wird nichts gerechnet.
Der Baustein steuert 8 Antriebe an, also 8 Aufrufe je Zyklus.
Der Aufruf geschieht nicht aus Verschachtelungen heraus, es ist ein linearer Programmablauf (OB1 ruft FC34, FC34 ruft 8 mal FC704).
Es laufen keinerlei Zeitinterupts, es werden auch keine Schleifen gebildet.

Von den 8 Aufrufen landen nur 6 im Fehlerspeicher (kann man sehen an den zeitlichen Abständen zwischen den Fehlermeldungen ~1ms, Zykluszeit ca. 6 ms)
Ich kann nicht sagen, welche von den 8 Aufrufen zum Fehler führten.

Die Größe des Stacks kann ich nicht bewerten, habe mir darum eigentlich noch nie Gedanken machen müssen.

Der Programmspeicher ist üblicherweise zu ca. 40% gefüllt.
 
Was mich daran irritiert, ist die Fehlermeldung. Da wird versucht, auf den Global-DB zuzugreifen. Das Programm arbeitet aber eigentlich an dieser Stelle mit den Lokaldaten. Gibts einen Alarm-OB oder andere Interrupt-Möglichkeit?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aua, so kann man in die Irre gehen :ROFLMAO:!

Zugriffsadresse 1039 für Lokaldaten (wenn da mal der Stack des Bausteins gemeint ist????) wäre aber auch schon recht üppig, oder?
 
Der aufrufende Baustein hat 100 Worte in den Lokaldaten belegt, der aufgerufene Baustein 14 Worte.
Ist 1039 die Stackadresse ?
Was legt die CPU auf den Stack beim Programmaufruf ?
 
Bin mir zwar jetzt nicht sicher ob das mit dem Problem zu tun haben könnte, aber mir ist in Deinem FC107 folgender Code aufgefallen:

Code:
.....
LAR1 P##steuerwort
L [COLOR=red]LW[/COLOR] [AR1,P#0.0]
LAR1 #AdrPW1
.....
.....
Da Du ja indirekt adressierst, ist meiner Meinung nach die Angabe LW zumindest überflüssig, weil doppelt gemoppelt. Das Adressregister bezieht sich durch den Pointer ja bereits auf die Lokaldaten. Ob die CPU in bestimmten Situationen damit "durcheinander" kommen kann weis ich nicht.
Aber testweise würde ich das statt dessen mal so schreiben:

Code:
.....
LAR1 P##steuerwort
L [COLOR=red]W[/COLOR] [AR1,P#0.0]
LAR1 #AdrPW1
.....
.....
 
Zurück
Oben