Problem: Selbständiges Urlöschen der CPU nach Einschalten der Maschine

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

hatte das auch mal bei einem Speicherüberlauf der MMC oder des CPU Spiechers, weiss nimmer genau. Ist zu lange her.
JEdenfalls habei ich damals glaub zu viele DB geöffnet und zu viel auf die MMC geschrieben.

Hast du schon mal eine größere MMC versucht?

(Bin damals dann auf OPC ausgewichen)
--

Ein früherer k
Kollege hatte das auch mal Programmtechnisch geschaft.
Er hat sich überlegt das als Sicherheit vor Softwarekopien (bei Serienmaschinen) einzusetzen.
 
zu viele DB geöffnet und zu viel auf die MMC geschrieben
Zum Vergrößern anklicken....

ich hatte in meinem Fall ja gar nichts auf die MMC geschrieben,
das war ja nur eine "Wertesicherungsoperation", die ich da
angedacht hatte.

Aber mit dem Link aus Post #19 ist das Thema für die 315-PN/DP
durch und auch das FW-UPD für die 315-2DP soll wohl bald kommen.


Gruß

Frank
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Firmware

Hallo,

das ist ein Problem dass mit der Firmware 3.2.3 behoben wird. Dieser ist noch nicht für alle neuen CPU's verfügbar. ZB bei der 6ES7315-2EH14-0AB0 V3.2.3 ist dieses Verhalten schon behoben.

Mit dem Firmware-Update V3.2.3 werden die folgenden Änderungen wirksam:

  • Nach Netz-aus kommt es nicht mehr sporadisch zu Aktualwertverlusten durch Urlöschanforderung wegen Speichertausch (Ereignis-ID 16# 6526)

  • Die Remanenzsicherung bei Netz-aus wurde stabilisiert (betrifft hochsporadische Remanenzverluste mit Ereignis-ID 16# 4580 „Backup-Pufferinhalt inkonsistent“).

  • Hinzufügen eines Schrittes in S7-Graph und anschließender Baustein-Download führt nicht mehr für einen Zyklus zu einem Bereichslängenfehler. Ab sofort können wieder mehrere Bausteine zusammen eingekettet werden.

  • Antwortet ein Slave auf das erste Datentelegramm des Masters negativ (z.B. mit „habe keinen Speicher für Data-Response“), dann führt dies nicht mehr dazu, dass der Slave später nicht aufgenommen wird.

  • Bei einem mit dem SFC12 aktivierten und anschließend ausgefallenen Slave, wird bei der darauffolgenden Slave-Wiederkehr am DP-Strang nun wieder der OB86 aufgerufen. Auch bleibt bei Slave-Wiederkehren während des Übergangs von STOP nach ANLAUF (u.a. im Hochlauf der CPU) nicht mehr sporadisch die Kennung für einen Peripheriezugriffsfehler gesetzt.

  • Die Befehlsabfolge „L MW 2, TAK, T MW 3, TAK“ funktioniert ab sofort auch, wenn die Bereiche von „T“ und „L“ (wie in der genannten Befehlsabfolge) überlappend sind.

  • Projektierte aber nicht vorhandene PA-Eingänge können nun wieder mittels VAT gesteuert werden.

  • Die Projektierung einer Profinet-Verbindung ohne Devices führt nach dem Download nicht mehr zum Anknipsen der BF2-LED.

  • Die AWL-Anweisung DTB „DWord-To-BCD“ führt bei einem ungültigen Eingangswert (kein BCD-Wert) nicht mehr zum Defekt mit Z1=f11c.

  • Ein SDB0 mit ungültiger Baudrate führt nicht mehr zum Defekt mit Z1=914A; stattdessen wird ab sofort die MPI-Default-Baudrate von 187,5 kBd voreingestellt.

  • Ein Netz-aus während Baustein online beobachten führt nicht mehr sporadisch zu einem Defekt mit Z1=0019 oder Z1=F104.

  • Der SFC1 "READ_CLK" wandelt ab sofort die Jahreszahl immer korrekt in eine BCD-Zahl. Nachfolgende auf das BCD-Format aufsetzende Anweisungen (z.B. BTI „BCD-To-Integer“) führen somit nicht mehr zu Wandlungsfehlern (z.B. Ereignis-ID 16# 2521 „BCD-Wandlungsfehler).
Zum Vergrößern anklicken....
Beitrags-ID 40360647

André
 
sps-concept schrieb:
Hallo,

das ist ein Problem dass mit der Firmware 3.2.3 behoben wird. Dieser ist noch nicht für alle neuen CPU's verfügbar. ZB bei der 6ES7315-2EH14-0AB0 V3.2.3 ist dieses Verhalten schon behoben.


Beitrags-ID 40360647

André
Zum Vergrößern anklicken....

Ich muss Dich leider enttäuschen, ich habe eine getauschte (SIEMENS Retouren-Center) CPU 315-PN/DP mit FW V.3.2.3 und eine neue, bei der ich die CPU selbst mit der neusten FW versehen haben, beide haben das gleiche Verhalten!
==> Verlust der Aktualdaten!

siehe auch: http://www.sps-forum.de/showthread.php?t=42393
 
Also die Ereignis-ID 16# 6526 „Urlöschanforderung wegen Speichertausch“ kann doch unmöglich etwas mit der Hardwareconfig zu tun haben. Ich habe zwar mal vorsichtshalber die Konfig komplett neu erstellt und meine "Marktbegleiter"-Speicherkarten durch SIEMENS eigene ersetzt. Das Ganze aber auch nur, weil die Anlagen kurz vor der Auslieferung stehen und ich eine Lösung brauche.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Michael,
wenn ich mir die Problemme von dir und Frank (IFBS) so anschaue, dann
wünsche ich mir das Zeitalter der Pufferbatterie zurück. Da wusste mann
was los war, oder es ging wenigstens eine Lampe am Netzteil an.

Ich finde das ist Ummöglich, das Siemens eine so wichtige Eigenschaft wie
Remanenz nicht in den Griff bekommt. Vlt. liegt es auch garnicht an den
Speicherkarten oder Software, sondern es ist eine Hardwareproblemm der
CPU.

gruß helmut
 
Hi Freunde,

habe grad mit dem SIEMENS-Support gesprochen. Leider sind die auch ratlos. Das Ganze wird jetzt eine Etage höher gegeben in der Hoffnung eine Lösung zu finden.

Neu Vorgehensweisen als meine bisherigen gibt es auch nicht.

Was hab ich bisher getan:
1. eine von zwei CPU 315-2 PN/DP getauscht - ohne Erfolg
2. Eigenes Fehlerprotokoll mit Fehlerliste (500 Einträge) aus dem Baugruppenzustand erstellt
3. Hardwarekonfig neu erstellt, zuvor Hardwarekatalog aktualisiert - Ergebnis offen
4. Firmware erneut heruntergeladen und aufgespielt - Ergebnis offen
5. Speicherkarte getauscht. - Ergebnis offen
6. S-SUPPORT eingeschaltet - Fehlerprotokoll zugemailt - Rückmeldung, leider ohne Ergebnis
 
Zuletzt bearbeitet:
Helmut_von_der_Reparatur schrieb:
Ich finde das ist Ummöglich, das Siemens eine so wichtige Eigenschaft wie
Remanenz nicht in den Griff bekommt. Vlt. liegt es auch garnicht an den
Speicherkarten oder Software, sondern es ist eine Hardwareproblemm der
CPU.

gruß helmut
Zum Vergrößern anklicken....

Das Problem bei der Remanenz der aktuellen Generation ist, daß die Flashes nicht mehr so gut sind wie früher. Durch die Shrinkmassnahmen wird die Qualität dermaßen schlecht, daß die Sicherung nicht immer durchgeführt werden kann. Im Netzaus hat die CPU ja nur eine gewisse Zeit um alles zu sichern. Ich denke kaum, daß da noch genug Zeit ist alles zurückzulesen und zu validieren und dann ggf. neu zu schreiben. Da ist es es doch allemal besser per CRC zu testen ob der Inhalt stimmt und wenn nicht die Remanenz über Bord zu schmeissen, anstatt der dem Nutzer inkonsistente Daten zu liefern.

Pufferbatterie hin oder her. Was alt war muss nicht schlecht sein :)
 
Richter.John schrieb:
Ich würde halt gerne mal das Programm sehen und es bei mir austesten. Kannst Du es nicht abspecken und archivieren?
Zum Vergrößern anklicken....

@Richter.John

Das liegt mit 1000%iger Garantie nicht am Programm sondern an
den völlig überlasteten Rettungs- und Sicherungsroutinen.

Gib es zu, du willst doch nur spielen :ROFLMAO:

Frank
 
@Richter.John.....ähm....ich meine euer Ehren, ich habe so den Eindruck
als wenn du selber für Siemens arbeitest oder einen ähnlichen Steuerungs
Hersteller :rolleyes:
 
Ich bin halt nen Tüftler, darf man da nicht ein wenig Neugierig sein? :) Bei mir läuft alles soweit. Mit Remanenzproblemen habe ich mit Gott sei dank noch nicht grossartig rumärgern müssen. Ich kenne nur eben gerne Grenzen und was sie verursacht um dem Problem aus dem Weg zu gehen, mehr nicht ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ein weiterer Kontakt mit dem S-Support:
Zur genaueren Analyse benötigt Siemens den Diagnosepuffer der CPU als Text und im HEX-Format. Leider konnte ich den Fehler im HEX-Code nicht mehr liefern, da nach meinem erneuten Firmware-Update der DiagPuffer gelöscht wurde uns somit der alte Fehler nicht mehr vorhanden war. Leider konnte ich den Fehler noch nicht wieder reproduzieren. Ein weiterer Vorschlag vom Support war halt der Tausch der Speicherkarte, dieses hatte ich jedoch bereits mit dem Firmwareupdate zusammen erledigt.

Für weitere Unterstützung muss der Fehler nochmal auftreten. Bleibt zu hoffen, das dieser nach meinen Aktionen nicht mehr auftritt!
 
Seit dem ich die Speicherkarten von Helmholz gegen orginal Speicherkarten von Siemens getauscht habe ist der Fehler noch nicht wieder aufgetreten. Die getauschten Karten sind nun zur Überprüfung auf dem Weg nach Helmnholz..

Fortsetzung folgt ... ;)
 
Helmut_von_der_Reparatur schrieb:
...Vlt. liegt es auch garnicht an den Speicherkarten oder Software, sondern es ist eine Hardwareproblemm der CPU...
Zum Vergrößern anklicken....
Da dachte ich auch schon hin. Das wäre natürlich fatal. Vielleicht gibt es dann die größte Rückrufaktion in der Geschichte der SIMATIC. Kann eigentlich jemand eine Aussage treffen, bei welcher FW dieser Fehler öfter auftritt? Ich habe noch zwei 315 DP/PN vorrätig, von denen eine in Kürze zum Einsatz kommen soll. Beide haben noch nicht die aktuelle Firmware (glaube 3.1.1). Es werden Programme geteacht - viele remanente Daten, mehr denn je.

Oder ist es besser, eine 315 2DP zu verwenden. Eigentlich kam mir der Speed der DP/PN in diesem Fall äußerst gelegen. Apropos "Speed" ... vielleicht greife ich besser auf Vipa zurück. Das ist jetzt nicht sarkastisch gemeint, es ist nur eine logische Konsequenz. Die Baustelle ist 450km entfernt. Die Kosten möglicher Remanenzprobleme nimmt uns vermutlich niemand ab.


Richter.John schrieb:
Das Problem bei der Remanenz der aktuellen Generation ist, daß die Flashes nicht mehr so gut sind wie früher...
Zum Vergrößern anklicken....
Ist diese Aussage deiner Fantasie entsprungen, oder kannst du das irgendwie untermauern?
 

Similar threads

J
TIA Unregelmäßiger CPU Stop und Wiederanlauf 1513-1 PN auf Grund eines IO Devices
2
Antworten
24
Aufrufe
5K
DeltaMikeAir
DeltaMikeAir
C
Step 7 Bereichslängenfehler beim Lesen
Antworten
13
Aufrufe
2K
Thomas_v2.1
T
A
TIA Problem bei der Hardwarekonfiguration einer CPU 315-2 PN/DP und HMI
Antworten
15
Aufrufe
1K
Andre99
A
M
TIA Profinet IO: Stationswiederkehr (Ereignis-ID:16#38cc)
Antworten
1
Aufrufe
1K
Per
Per
B
Step 7 Bereichslängenfehler 16# 2522
Antworten
14
Aufrufe
5K
Onkel Dagobert
Onkel Dagobert
Zurück
Oben