[ S7-200 ] Max. Anzahl Schreibzugriffe aufs EEPROM

caret

Level-1
Beiträge
82
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Im Systemhandbuch der S7-200 steht, dass nach ca. 1*10^6 Schreibzugriffen mittels DATx_WRITE das EEPROM den Geist auf gibt. Wie wird das aber gezählt?
Sind das wirklich 1*10^6 Aufrufe von DATx_WRITE oder hängt das auch noch davon ab wieviel Byte in einem Aufruf mit DATx_WRITE geschrieben werden? Mit dem Rezepturassistenten, der die DATx_WRITE Funktion generiert, kann ich ja z.B. eine Variable mit einem Byte oder aber auch 256 Double Werte ( 256 * 4 Byte = 1024 Byte) als ein Rezept definieren. Zählt da wirklich nur die Anzahl DATx_WRITE Aufrufe, oder auch die Bytegröße der Rezepte?
 
Ich glaube die Aussage ist eher allgemein zu verstehen.
Wenn du 1*10^6 Mal auf ein und dieselbe Speicherzelle schreibst, wird diese
irgendwann danach den Geist aufgeben. Der Wert ist bei fast allen EEPROM
in etwa dieser Größenordnung, gibt wohl noch spezielle Typen. Die Frage ist
eher, ob Siemens wirklich nur die von dir addressierten Bytes beschreibt, oder
noch irgendwelche Informationen ablegt, die immer an der selben Stelle landen.
In diesem Falle wäre es egal, wohin und wieviele Daten du schreibst, ansonsten
könntest du das beeinflussen, indem du irgendwann den Speicherbereich wechselst,
so du überhaupt darauf Einfluß hast, wohin geschrieben wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die mögliche Anzahl von Schreibzugriffen ergibt sich aus den Angaben des Herstellers des eingesetzten EEPROMs. Gezählt wird dabei gar nichts (sonst wäre es ja mal wieder der klassische Teufelskreis, dass irgendwo im EEPROM die Information gespeichert werden müßte, der wievielte Schreibzugriff dies war, was natürlich einen Schreibzugriff ..).

Entsprechende Angaben finden sich auch bei Flashbausteinen, USB-Sticks etc.
Bei letzteren (wie auch manchen SD-Cards, Compact-Flash, ..) finden sich teilweise integrierte Logiken, die versuchen, die sehr häufigen Schreibzugriffe im Directory- und FAT-Bereich auf verschiedene Sektoren zu "verteilen", um die Lebensdauer zu erhöhen.

Die Angaben für die Anzahl der Schreibzugriffe sind üblicherweise garantierte Mindesthaltbarkeiten, sie können deutlich höher liegen. Entscheidend ist die Anzahl der Schreibzugriffe auf jede einzelne Zelle - es hängt also davon ab, wo die Daten im EEPROM zu liegen kommen.

So richtig präzise Auskunft gibt dir in diesem Bereich leider keiner.
Man kann's nur versuchen abzuschätzen, wobei ich einen Aufruf von DATx_WRITE als einen Schreibzugriff zählen würde. Das ergibt dann eine Haltbarkeit von:
1*10^6 / (100 Schreibvorgänge täglich * 365 Tage) = (etwa) 27 Jahre
 
Ich glaube die Aussage ist eher allgemein zu verstehen.
Wenn du 1*10^6 Mal auf ein und dieselbe Speicherzelle schreibst, wird diese
irgendwann danach den Geist aufgeben.
Das klingt logisch.
Die Frage ist eher, ob Siemens wirklich nur die von dir addressierten Bytes beschreibt, oder noch irgendwelche Informationen ablegt, die immer an der selben Stelle landen.
Hm, also von USB-Stick weiss ich, dass die inzwischen selbstständig die Daten verteilen um eben alle Speicherzellen gleichmässig auszulasten. Wie das bei den Siemens EEPROMs ist eine wirklich gute Frage
In diesem Falle wäre es egal, wohin und wieviele Daten du schreibst, ansonsten könntest du das beeinflussen, indem du irgendwann den Speicherbereich wechselst, so du überhaupt darauf Einfluß hast, wohin geschrieben wird.
Den Speicherbereich selbst wechseln kann ich leider nicht. Schreib- und Lesezugriffe aufs EEPROM kann man bei der S7-200 in WinCC NUR über den Rezeptur- bzw. Datenprotokollassistenten machen. Da kann man aber nicht eingreifen wohin gespeichert wird.

Sieht dann wohl schlecht aus für mich: Wollte gerne Datanprotokolle auf das externe EEPROM schreiben (Temperaturverlauf dokumentieren). Da würde ich ungefähr jede Minute einmal schreibend aufs EEPROM zugreifen und zwar immer auf die gleichen Speicherzellen, da ich das 32k EEPROM voll auslasten will/muss. Da würde das EEPROM aber nur knapp 2 Jahre halte. Und ich hab ja auch noch andere Schreibzugriffe (Rezepte, Maschineneinstellungen, ...)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du könntest eventuell (kenn mich mit 200 nicht wirklich aus)
die Daten puffern und einmal pro Stunde wegschreiben...

Das ist ja genau meine Idee gewesen. Wollte erst mal 4kB Daten im Hauptspeicher puffern und dann ins EEPROM schreiben lassen. Die Frage war dann ob das eben ein Speicherzugriff ist, da ich nur einmal DATx_WRITE aufrufe oder ob es mehrere Zugriffe sind.
 
Zuletzt bearbeitet:
Habe eine allgemeine Frage:

Wie ist das bei Festplatten. Die tollen Defragmentierungs Tools legen ja ausnahmslos alle die meist benutzten Dateien an den Anfang der HD.
Währe es da nicht besser wenn dieser Bereich jeden Monat mal wo anders währe?

Grüsse
 
Habe eine allgemeine Frage:

Wie ist das bei Festplatten. Die tollen Defragmentierungs Tools legen ja ausnahmslos alle die meist benutzten Dateien an den Anfang der HD.
Währe es da nicht besser wenn dieser Bereich jeden Monat mal wo anders währe?

Grüsse
Nein.
Die Magnetschicht ist "verschleissfrei".
Allein schon der Bereich, der von der Auslagerungsdatei belegt ist, wird ja im laufe eines Tages schon tausende von Malen neu beschrieben....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Caret,

Deine Idee erst mal die Werte in den V-Speicher jede Minute zu speichern und einmal am Tag auf die EEPROM-Karte zu schreiben hört sich erst mal ganz gut an.

Achtung: mit der Funktion Datalog kann max. 203 Bytes je datarecord geschrieben werden. Davon sind 3 Bytes Overhead, 3 Bytes Datum und 3 Bytes Zeitstempel. Somit bleiben effektiv 194 Bytes übrig. Wenn du vier Recodrs definierst, so kannst du max 4 mal 203 bytes schreiben. Das sind nach Adam seinen Riesen 812 Bytes.

Wenn du mehr brauchst, überleg dir mal, das mit den Rezepten zu machen. Hier kannst du ~65000 Werte in ~65000 Sätzen speichern. Allerdings werden die Rezept nicht im CSV-Format gespeichert.

Übrigens gibts bei S7-200 nur zwei EEPROM-Größen 64kB oder 256kB mit denen Datalog möglich ist.

Hoffe das hilft dir weiter.

Gruss

Helmut
 
Achtung: mit der Funktion Datalog kann max. 203 Bytes je datarecord geschrieben werden. Davon sind 3 Bytes Overhead, 3 Bytes Datum und 3 Bytes Zeitstempel. Somit bleiben effektiv 194 Bytes übrig. Wenn du vier Recodrs definierst, so kannst du max 4 mal 203 bytes schreiben. Das sind nach Adam seinen Riesen 812 Bytes.

Wenn du mehr brauchst, überleg dir mal, das mit den Rezepten zu machen. Hier kannst du ~65000 Werte in ~65000 Sätzen speichern. Allerdings werden die Rezept nicht im CSV-Format gespeichert.
Ich werde mehr brauchen (256k EEPROM) und werde auf jeden Fall den Rezepturassistenten verwenden (müssen), da der Datenprotokollassistent keine Funktion zum auslesen der Daten bereitstellt (auslesen nur über S7-Explorer möglich). Mit Rezepturassistent und libnodave kann ich aber selbst definierte Datenprotokolle mit meiner eigenen PC-Anwendung auslesen und auch beliebig weiterverarbeiten (CSV und Excel, direkt in MySQL schreiben, ...)

Mein Problem ist im Moment nur noch der besch......eidene Rezepturassistent. Kann man den eigentlich umgehen und irgendwie anders Zugriff auf das EEPROM bekommen? Das Problem ist, dass ich wenn ich z.B. 4kB große Blöcke damit schreiben bzw. lesen will, mind. 1024 Variable (1024 * 4Byte Double-Werte) darin deklarieren muss. Das ist kein Spass mit dem Teil (langsam, immense Klick- und Tipparbeit) und vor allem auch vollkommen unnötig, da ich den Speicher ja gar nicht symbolisch adressieren will.
Mir ist schon klar das der Rezepturassistent dafür nicht gedacht ist und ich den sozusagen für eigene Zwecke vergewaltigen will. Das Problem ist aber eben, dass der Rezepturassistent meines Wissens nach die einzige Möglichkeit ist ins EEPROM zu schreiben UND auch wieder davon zu lesen. Oder gibt es da noch andere Möglichkeiten bei der S7-200?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
vielleicht hilft dir dieser link.

Linear access to external eeprom
http://www.s7-200.net

Vielen Dank für den Tip. Hilft zwar nur indirekt, da dort die gleiche Idee umgesetzt wird, wie ich sie auch hatte (Blockweiser Zugriff aufs ext. EEPORM über Rezepturassistenten), aber es erspart mir den Implementierungsaufwand da ich die fertige Bibliothek einsetzen kann.
 
Zuletzt bearbeitet:
Zurück
Oben