Problem mit CPU Speicherkarten

MCerv

Level-2
Beiträge
824
Reaktionspunkte
126
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Freunde,

ich habe folgendes Problem:

Zwei neue Anlagen (identischer Aufbau) mit jeweils einer CPU 315-PN/DP (V3.2.3) und einer 512kB-Speicherkarte von Helmholz.

In unreglemäßigen Abständen nach Hauptschalter ein meldet die CPU mir einen Speicherkartenwechsel erkannt und führt ein urlöschen durch. Folglich sind allle Aktualwerte weg. Das ist sehr ärgerlich!

Habe bei einer CPU (weil es im Fehlerspeicher so stand), diese bei SIEMENS getauscht. Leider ohne eine Verbesserung.

Defekte Speicherkarten, fehlerhafte Charge? Habe erstmal orginal Speicherkarten von SIEMENS bestellt.

Gibt es vielleicht noch andere Ursachen?
 
Da gab es mal von IBFS nen Beitrag, das es an der Firmware liegt.
S sollte letztens eine neue FW rausgebracht haben. Ich werd mal weitersuchen, vielleicht find ich es noch.
Thomas
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zwei neue Anlagen (identischer Aufbau) mit jeweils einer CPU 315-PN/DP (V3.2.3) und einer 512kB-Speicherkarte von Helmholz.

Gibt es vielleicht noch andere Ursachen?

Hallo MCerv,
Siemens hat bestimmt in der Firmware eine Prüfroutine eingebaut, wo Sie feststellen
das du mit den Speicherkarten fremdgegangen bist. Wahrscheinlich ist jetzt
die ganze CPU unbrauchbar ;)

Grus Helmut
 
Helmut_von_der_Reparatur schrieb:
...du mit den Speicherkarten fremdgegangen bist. Wahrscheinlich ist jetzt die ganze CPU unbrauchbar ;)

Grus Helmut


Hallo Helmut,

aus zutrauen würde ich es dem großen "S". Nur ist die Routine wohl defekt, da bei anderen auch der Fehler auftritt *ROFL*

It's not a Trick ist SIEMENS
 
Hallo Helmut,

aus zutrauen würde ich es dem großen "S". Nur ist die Routine wohl defekt, da bei anderen auch der Fehler auftritt *ROFL*

It's not a Trick ist SIEMENS

Du weist doch da Siemens Software so seine Macken hat, ich glaube
das bei denen Einwandfrei funktioniert ist das Buchhaltungsprogramm,
speziell die Subroutine zur Erstellung der Rechnung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bis jetzt hatte ich mit CPU's von Siemens keinerlei Probleme, eher vom Marktbegleiter "V" (der Sponsor dieser HP steht auch oben im Kopf ;)). Bei dem hatte ich des öfteren (zu oft) absoluten Speicherverlust! Jetzt bin ich wieder beim "S" und dann sowas :sm11:
 
Es liegt nicht an den Speicherkarten. Ich habe die Beobachtung gemacht,
das es besonders nach einem Einspielen der HWKonfig und einem
anschießenden Power-OFF -> Power-On auftritt.

Ich habe es mal provoziert mit zwei identischen CPUs,
HWKonfig neu geladen,
gleichzeitig den Strom weggeschaltet (gleiches Netzteil),
Spannung wieder da,
beide CPU synchron in den STOP anstatt in den RUN,
Ergebnis siehe mein Thread.

Gruß

Frank
 
Das Problem klingt ziemlich interessant. Ich frage mich ob es an der Projektierung liegt und wenn ja an welchem Teil davon.

Hast Du die Möglichkeit HWKonfig zu zippen, daß man sich mal die Sachen anschauen kann oder Du beschreibst die Projektierung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
..Ich habe die Beobachtung gemacht, das es besonders nach einem Einspielen der HWKonfig..
Ich habe auch deinen anderen Thread gelesen und hatte den Eindruck dass das Problem auf sehr spezielle Umstände zurück zu führen ist. Vielleicht liegt es primär garnicht an der CPU bzw. deren Firmware. Jetzt wo du das mit dem Einspielen der HWKonfig erwähnst? Vielleicht ist der Fehler ganz wo anders zu suchen? Ich nehme an, du arbeitest mit aktuellen Softwareständen? Beschreibt doch mal euere Babys. Es muß irgendwo genetische Zusammenhänge geben.

Ich habe es mal provoziert mit zwei identischen CPUs, HWKonfig neu geladen, gleichzeitig den Strom weggeschaltet (gleiches Netzteil), Spannung wieder da, beide CPU synchron in den STOP anstatt in den RUN, Ergebnis siehe mein Thread...
Was haben beide CPUs gemeinsam? Die selbe Firmware, das selbe Netzteil und das selbe Werkzeug zum Programmieren. Was ist es für eine Netzteil? Was ist es für ein Werkzeug? Hast du es schon einmal mit dem Rechner eines Kollegen probiert? Irgendwo steckt da was in deinem System, denke ich.
 
Hi.
Das mit den Verlust der Aktualwerte ist natürlich schlecht.
Deswegen hab ich bei mir immer eine kleine Funktion laufen, die in bestimmten Zeitabständen die Aktualwerte der DB auf die Flash schreibt. Dann sind die auch bei Urlöschen nicht wech. Das sollte man natürlich nicht zu oft machen, da die Dinger je nach Hersteller und Umgebungstemperatur max. ca. 100000 Schreib/Löschvorgänge vertragen.
Es grüßt
Sailor
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist ja prizipiell ein gute Idee sich die HWKonfig auszusehen.
Allerdings wird das nicht viel helfen, denn es tat der Fehler
bei mehreren Programmierern sowohl an CPU315-2DP und auch
CPU315-PN/DP auf. Insgesamt Acht verschiedene CPUs von
insgesamt vier Programmierern mit STEP7 V5.4 - SP4 / SP5
sowie V5.5. Sowohl STEP7 (Normal) als auch STEP 7 Prof.

Da ich im "Labor" keine Peripherie hatte, habe ich einfach das
Programm einer CPU genommen und der HWKonfig "entkernt" bis
nur noch die CPU ohne SM/FM-Baugruppen übrig war, also auch
kein GSD-Zeug mehr. Nur noch OB1 (leer) und viele DBs sonst nix.

Der Grund für diese Vorgehensweise der, dass mir sonst die fehlenden
Baugruppen den Diagnosepuffer vollmüllen und der CPU sehr lange
hochläuft.

Als Netzteil habe ich ein normales Puls-Netzteil verwendet, was wir
schon seit Jahren einsetzen.

Zum Test dann Netzteil Primär "entsaftet" und schön gewartet bis
die Restspannung weg war - 15 Sekunden - dann wieder Spannung
zugeschaltet --> und siehe da - statt das die CPUs nach dem
Hochlauf in den RUN gehen blieben sie im STOP.

Auf beiden CPUs waren nachher identische DIAG-Einträge.

Es wäre geadezu absurd, wenn es vor "bestimmten" Konfigurationen
abhinge oft sowass passiert.

Ich mache das jetzt seit über zehen Jahren und in all der Zeit habe
ich auf das saubere Verhalten der SI-CPUs geschwohren.

Dabei habe ich schon CPUs im dreistelligen Bereich belebt. Aber erst
seit einem Jahr ging der Käse los. Das ist besonders "lustig" wenn
die betreffende Anlage in Übersee oder Asien ohne Fernwartung
im Einsatz ist. Nicht jeden Kunden kann man zur Fernwartung
überreden.

Frank
 
...
Deswegen hab ich bei mir immer eine kleine Funktion laufen, die in bestimmten Zeitabständen die Aktualwerte der DB auf die Flash schreibt. Dann sind die auch bei Urlöschen nicht wech.
...

Das ist keine "anscheinend" sondern nur eine "scheinbar" gute Idee,
denn wenn du die Maschine wieder einschaltest, woran willst du
SICHER erkennen, das es DIESEN Fehler gab?

Wenn du z.B. eine Test-DB mit Wert 0 auf 1 setzt und nach dem
Wiedereinschalten hast du 0, da weißt du, es ist passiert. Blöd
nur, wenn jemand auf die RAM-TO-ROM-Idee kommt während dein
Testwert 1 ist. Wie willst du das dann noch erkennen.

Frank
 
Man muss natürlich abwägen, was einen wichtiger ist: Alle Sollwerte beim Teufel oder die Diagnose. Bei vielen Anlagen ist es der reinste Horror, wenn die aktuellen Sollwerte weg sind!!
Selbstverständlich werden da auch Anlagenzustände "wiederhergestellt", so das man aufpassen muss, was beim Neustart passiert. Macht man da Fehler, ist das Flashen sogar gefährlich.
Wer sich da nicht sicher ist, bitte Finger weg.
@IBFS: Wer an diesen Thread-Problem arbeitet, sollte schon wissen was er tut.
Gruß
Sailor
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist ja prizipiell ein gute Idee sich die HWKonfig auszusehen.
Allerdings wird das nicht viel helfen, denn es tat der Fehler
bei mehreren Programmierern sowohl an CPU315-2DP und auch
CPU315-PN/DP auf. Insgesamt Acht verschiedene CPUs von
insgesamt vier Programmierern mit STEP7 V5.4 - SP4 / SP5
sowie V5.5. Sowohl STEP7 (Normal) als auch STEP 7 Prof.

Da ich im "Labor" keine Peripherie hatte, habe ich einfach das
Programm einer CPU genommen und der HWKonfig "entkernt" bis
nur noch die CPU ohne SM/FM-Baugruppen übrig war, also auch
kein GSD-Zeug mehr. Nur noch OB1 (leer) und viele DBs sonst nix.

Der Grund für diese Vorgehensweise der, dass mir sonst die fehlenden
Baugruppen den Diagnosepuffer vollmüllen und der CPU sehr lange
hochläuft.

Als Netzteil habe ich ein normales Puls-Netzteil verwendet, was wir
schon seit Jahren einsetzen.

Zum Test dann Netzteil Primär "entsaftet" und schön gewartet bis
die Restspannung weg war - 15 Sekunden - dann wieder Spannung
zugeschaltet --> und siehe da - statt das die CPUs nach dem
Hochlauf in den RUN gehen blieben sie im STOP.

Auf beiden CPUs waren nachher identische DIAG-Einträge.

Es wäre geadezu absurd, wenn es vor "bestimmten" Konfigurationen
abhinge oft sowass passiert.

Ich mache das jetzt seit über zehen Jahren und in all der Zeit habe
ich auf das saubere Verhalten der SI-CPUs geschwohren.

Frank

Okay, kann ich davon ausgehen, daß HWKonfig für die CPUs nur noch aus der reinen CPU ohne spezielle Peripherie oder Anschaltungen besteht und der Download des Anwenderprogramms die Ursache ist?

Wie lädst Du denn runter? Anwenderprogramm laden auf MMC aus dem SIMATIC Manager oder anders?

Wenn Du nur HWKonfig überlädst wird ja das Anwenderprogramm nicht beeinflusst. Die Frage ist wenn Du nur das eine hast tritt der Fehler immernoch auf?

Wenn es geht könntest Du das Projekt mal archivieren, sofern keine sensiblen Daten Deienrseits vorhanden sind. Mich würde es interessieren ob es am Laden der DBs liegt und der Remanenzsicherung im Netzaus oder evtl. doch an was anderem. U.u. ist auch im Netzausfall die Zeit nicht ausreichend oder da tritt dann der Fehler auf.
 
Ich wollte nur nochmal den Fall zusammenfassen, damit auch
andere ggf. erkennen - ja, das ist ja wie bei mir!

Fakt ist, das SIEMENS diese Fehler sehr gut bekannt sind,
sonst würden sie als Grund für eine FW-Update nicht
auch das o.g. Verhalten mit anführen.

Daher ist es schlicht verschwendete Zeit das jetzt nochmal
zum tausendsten Mal nachvollziehen zu wollen.

Leider läßt das CPU315-2DP-Update immer noch auf sich warten.
[So, I am still waiting patiently for this next firmware update]

In dem Sinne

Frank
 
und so wie es aussieht gibt es bei der neuen FW V3.2.3 in der CPU 315-2 PN/DP immernoch diesen Fehler, obwohl der laut SIEMENS abgestellt sein soll!
 
Zurück
Oben