- Beiträge
- 10.490
- Reaktionspunkte
- 3.287
-> Hier kostenlos registrieren
Meine Idee war da mal, die DBs absolut zu adressieren und die 1500er-SPS als 300er im HMI anzulegen... Habs aber nicht weiter verfolgt...
TIA Uhrzeitsynchronistation Siemens S7-1200 / S7-1500 mit Problematik keine HMI-Verbindung wegen Zertifikat
- Ersteller hubert
- Erstellt am
-> Hier kostenlos registrieren
Stoky
Level-2
- Beiträge
- 396
- Reaktionspunkte
- 58
-> Hier kostenlos registrieren
Passt nicht 100% zum Thema, gehört aber doch irgendwie dazu.
Ein Kollege wies mich auf diesen Abschnitt in den Änderungen für TIA19 Update 1 hin:
Ein Kollege wies mich auf diesen Abschnitt in den Änderungen für TIA19 Update 1 hin:
- Beiträge
- 24.551
- Reaktionspunkte
- 8.712
Na bravo 
.
.
Stoky
Level-2
- Beiträge
- 396
- Reaktionspunkte
- 58
-> Hier kostenlos registrieren
Würde ich jetzt erwarten. Testen kann ich es in nächster Zeit leider noch nicht.
Ich frage mich auch, ob damit dann ein selbst erstelltes Zertfikat angepasst wird. Nicht dass das Zertifikat dann auf einmal doch nicht mehr bis 2099 gültig ist...
skorpion37
Level-2
- Beiträge
- 180
- Reaktionspunkte
- 65
Warum ändert sich ein einmal angelegtes Zertifikat? Das ist eigentlich unsinnig!
Wir haben folgendes Procedere in diesem Fall:
Standalone Anlagen, die auch schon mal mehrere Wochen aus sein können (Kampagnenbetrieb) . Hierbei trat dann dies hier beschriebene Verbindungsproblem auf,
sobald CPU und oder Panel ihre Reale Uhrzeit "vergessen" haben.
Wir setzen auf der CPU (je nach Maschinenreihe) 1200er oder 1500er Steuerungen ein.
Auf den CPUen liegen eigene Zertifikate, die bis weit jenseits der 2050 angelegt sind.
Bei einem Schwarz-Kaltstart nach langer Ausschaltperiode kommt es vor, das sich beide Partner (CPU und panel) nicht synchronisieren wollen.
Damit das zertifikat greift, dürfen CPU und Panel von ihrem Datem/Uhrzeit nicht allzusehr auseinanderliegen. Wenn das erfüllt ist, wir das Zertifikat gezogen. gültiger Zeitbereich im Zertifikat = alles läuft.
Eine Änderung der Panelzeit ohne dem Establish der Kommunikation über die übliche Panel-S7 Kommunikation ist unmöglich, da diese aufgrund nicht validiertem Zertifikat abgewiesen wird.
Dies geht nur über die Hintertür, also nicht Verwendung der Panel-S7 Kommunikation
bei uns ist folgendes programmiert:
im Anlauf: ist die CPU zeit vor dem 1.1.2023, dann setzte CPU zeit auf 1.1. 2023
im Zyklus:
SNTP Server aus der Siemens Bibliothek
Im Panel:
Zeitserver eingestellt auf die CPU
Hochstart sieht nun so aus:
CPU startet, wird bei leerem Uhrzeitpuffer über den OB100 auf 1.1.2023 gesetzt
wenn das Panel z.b. 1.1.201x hat (altes Comfort Panel) wird trotz gültiger Zertifikatszeitspanne noch keine Kommunikation aufgebaut
das Panel bezieht seine Zeit hinterrückt über den SNTP Server der CPU
da nun die Zeiträume gültig (da ja gleich sind) findet das Zertifikathandling statt
Die Verbindung wir nun als gültig erkannt, die S7 Kommunikation ist established und läuft
Ab hier ist auch Uhrzeitsetzen im Panel der "richtigen" CPU Uhrzeit möglich.
Gruss, Mike
Standalone Anlagen, die auch schon mal mehrere Wochen aus sein können (Kampagnenbetrieb) . Hierbei trat dann dies hier beschriebene Verbindungsproblem auf,
sobald CPU und oder Panel ihre Reale Uhrzeit "vergessen" haben.
Wir setzen auf der CPU (je nach Maschinenreihe) 1200er oder 1500er Steuerungen ein.
Auf den CPUen liegen eigene Zertifikate, die bis weit jenseits der 2050 angelegt sind.
Bei einem Schwarz-Kaltstart nach langer Ausschaltperiode kommt es vor, das sich beide Partner (CPU und panel) nicht synchronisieren wollen.
Damit das zertifikat greift, dürfen CPU und Panel von ihrem Datem/Uhrzeit nicht allzusehr auseinanderliegen. Wenn das erfüllt ist, wir das Zertifikat gezogen. gültiger Zeitbereich im Zertifikat = alles läuft.
Eine Änderung der Panelzeit ohne dem Establish der Kommunikation über die übliche Panel-S7 Kommunikation ist unmöglich, da diese aufgrund nicht validiertem Zertifikat abgewiesen wird.
Dies geht nur über die Hintertür, also nicht Verwendung der Panel-S7 Kommunikation
bei uns ist folgendes programmiert:
im Anlauf: ist die CPU zeit vor dem 1.1.2023, dann setzte CPU zeit auf 1.1. 2023
im Zyklus:
SNTP Server aus der Siemens Bibliothek
Im Panel:
Zeitserver eingestellt auf die CPU
Hochstart sieht nun so aus:
CPU startet, wird bei leerem Uhrzeitpuffer über den OB100 auf 1.1.2023 gesetzt
wenn das Panel z.b. 1.1.201x hat (altes Comfort Panel) wird trotz gültiger Zertifikatszeitspanne noch keine Kommunikation aufgebaut
das Panel bezieht seine Zeit hinterrückt über den SNTP Server der CPU
da nun die Zeiträume gültig (da ja gleich sind) findet das Zertifikathandling statt
Die Verbindung wir nun als gültig erkannt, die S7 Kommunikation ist established und läuft
Ab hier ist auch Uhrzeitsetzen im Panel der "richtigen" CPU Uhrzeit möglich.
Gruss, Mike
- Beiträge
- 17.285
- Reaktionspunkte
- 6.884
-> Hier kostenlos registrieren
Das ist doch schon seit V17 mit dem Classic Panels so.
RONIN
Level-3
- Beiträge
- 2.574
- Reaktionspunkte
- 805
Das trifft im Endeffekt auch auf die Comfort-Panels zu. Sobald du bei der CPU-Projektierung etwas so weit änderst, dass TIA eine Änderung des Kommunikationszertifikats erfordert, ist auch dort die Kommunikation unterbrochen, bis das Panel wieder neu eingespielt wurde.
Nein das nicht. Soweit ich bis jetzt testen konnte, führt nicht jede HW-Änderung zu einem Zertifikatstausch. Eher so Änderungen wie CPU-Tausch oder vielleicht Änderungen an den CPU-Sicherheitseinstellungen. Aber ich weiß auch noch nicht genau, welche Änderungen dann das Zertifikat beeinflussen.
Ein Thema ist zum Beispiel das kopieren einer CPU in ein anderes Projekt. Hatte das schon bei einer Kommunikationsanbindung. Lieferant schickte mir sein TIA-Projekt wo nur die CPU mit den Austausch-Datenbausteinen drin waren. So wie er das bisher auch immer gewohnt war. Ich hab dann dort einen Scada-Export gemacht und wollte die Datenpunkte in WinCCv8 anbinden. Ergebnis war Zertifikatsfehler. Der Kollege hatte die CPU per STRG+C/V in ein neues Projekt kopiert und dann alles rausgelöscht was mich nicht belangte. Das führt auf jeden Fall zu einem neuen Zertifikat.
RONIN
Level-3
- Beiträge
- 2.574
- Reaktionspunkte
- 805
Die Idee finde ich gar nicht mal schlecht. Danke.
Stoky
Level-2
- Beiträge
- 396
- Reaktionspunkte
- 58
-> Hier kostenlos registrieren
Wir haben jetzt schon ein paar Maschinen mit 17.0.7 gemacht. Bisher nie Probleme gehabt. Muss dann wohl schon ein wirklich gravierender Eingriff sein der das neue Zertifikat erstellt.
- Beiträge
- 17.285
- Reaktionspunkte
- 6.884
So gravierend war das nicht, zb Rechnerwechsel von Konstrukteur -> Monteur
oder eine einfache Hardwareänderung.
Funktioniert bestens. Ich glaube das es bei Standalone Anlagen gut praktizierbar ist.
-> Hier kostenlos registrieren
Wir haben folgendes Problem:
Auf Standardstationen verwenden wir die gleiche Siemens Bibliothek zum Steuern der Kinematics (Besteht aus PLC code und HMI Pages). Die HMI wird nur zum Einrichten der Station benötigt.
Idee war nun dass wir ein Mobile Panel per Linie haben dass dann mit den jeweiligen Stationen an X1 verbunden wird. Funktioniert auch soweit wenn wir das gleiche TIA Projekt laden und nur an den Bausteinen ein paar Station spezifische Änderungen einspielen.
Sobald wir jedoch die IP von X2 ändern (um aus den Stationen eine Linie zu bauen) und die HW-Config laden wird das Zertifikat neu erzeugt und somit baut das Mobile Panel keine Verbindung mehr auf. Alle Versuche mehrere Zertifikate im Panel zu hinterlegen blieben erfloglos.
Hat jemand eine Idee? Danke, Fab
Auf Standardstationen verwenden wir die gleiche Siemens Bibliothek zum Steuern der Kinematics (Besteht aus PLC code und HMI Pages). Die HMI wird nur zum Einrichten der Station benötigt.
Idee war nun dass wir ein Mobile Panel per Linie haben dass dann mit den jeweiligen Stationen an X1 verbunden wird. Funktioniert auch soweit wenn wir das gleiche TIA Projekt laden und nur an den Bausteinen ein paar Station spezifische Änderungen einspielen.
Sobald wir jedoch die IP von X2 ändern (um aus den Stationen eine Linie zu bauen) und die HW-Config laden wird das Zertifikat neu erzeugt und somit baut das Mobile Panel keine Verbindung mehr auf. Alle Versuche mehrere Zertifikate im Panel zu hinterlegen blieben erfloglos.
Hat jemand eine Idee? Danke, Fab
Unsere Erfahrung ist dass allein durch IP Adressen Änderung und anschließender HW-Config laden das Zertifikat neu erzeugt wird.
NBerger
Level-3
- Beiträge
- 1.584
- Reaktionspunkte
- 486
Hatte dieses Problemchen vor einigen Tagen auch...
Was geholfen hat:
- "Nur Secure Kommunikation zulassen" AUSSCHALTEN !!!
- SPS: Zugriffsteuerung deaktivieren UND Vollzugriff inkl. fehlersicher ... KEIN PASSWORT !!!
Entsprechend augf dem HMI kein Passwort einstellen...
Was geholfen hat:
- "Nur Secure Kommunikation zulassen" AUSSCHALTEN !!!
- SPS: Zugriffsteuerung deaktivieren UND Vollzugriff inkl. fehlersicher ... KEIN PASSWORT !!!
Entsprechend augf dem HMI kein Passwort einstellen...
skorpion37
Level-2
- Beiträge
- 180
- Reaktionspunkte
- 65
-> Hier kostenlos registrieren
Auch eine Möglichkeit: Die hmi Firmware auf V16 zurückstellen. Da gab es den ganzen Spuk mit den Zertifikaten noch nicht!
Stoky
Level-2
- Beiträge
- 396
- Reaktionspunkte
- 58
Bei uns (TIA 17.0.7) ist das zumindest noch nie passiert. Ich habe aber das Siemens Zertifikat nicht gelöscht, sondern nur ein eigenes zusätzlich erstellt. Kann also sein, dass das Siemens Zertifikat geändert wird, da es aber nicht benutzt wird stört es nicht. Also probier mal ein zweites Zertifikat zu erstellen, was du dann an allen Stellen benutzt. Keine Ahnung ob das klappt, ist nur eine Idee.
Zuletzt bearbeitet:
Similar threads
