TIA Uhrzeitsynchronisation CPU - HMI

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich das so mache dann muss ich doch die Uhrzeitsynchronisation (CPU Master und HMI's Slave) bei den HMI's auf "keine" stellen?

Ja, es geht immer nur eine Uhrzeitsynchronisation. Wenn Du den Bereichszeiger "Datum/Uhrzeit PLC" aktivierst, dann sollte das TIA schon meckern, wenn die "HMI Uhrzeitsynchronisation" auf "Slave" steht.

sowie die Zeitzone im Panel auf "Coordinated Universal Time"

Bei den Basic Panels kann man gar keine Zeitzone einstellen.
Und bei den Comfort Panels sollte man vermutlich CET (UTC+1, "Berlin") einstellen, wenn man die Uhrzeitsync per Bereichszeiger "Datum/Uhrzeit PLC" aktiviert, weil diese Sync davon ausgeht daß die Uhrzeit im Bereichszeiger Lokalzeit ist. Bei Comfort Panels müsste die TIA-"HMI Uhrzeitsynchronisation" aber doch eigentlich funktionieren, wenn man alles richtig einstellt?

Harald

 

[ducati]

Und bei den Comfort Panels muß man vermutlich CET (UTC+1, "Berlin") einstellen, wenn man die Uhrzeitsync per Bereichszeiger "Datum/Uhrzeit PLC" aktiviert, weil diese Sync davon ausgeht daß die Uhrzeit im Bereichszeiger Lokalzeit ist. Da bin ich aber nicht sicher. Bei Comfort Panels müsste die Siemens-"HMI Uhrzeitsynchronisation" aber doch eigentlich funktionieren, wenn man alles richtig einstellt?

Ich würde "behaupten" der Bereichszeiger "Datum/Uhrzeit PLC" stellt einfach die Paneluhr, ohne die Zeitzone zu beachten? Aber grundsätzlich müsste man das testen mit der jeweiligen TIA Version und ner Alarmtafel, ob dann die Zeiten dort stimmen...
Bei den Comfortpanels funktioniert die Uhrzeitsynchronisation schon, aber nicht die Sommer/Winterzeitumstellung... die musst Du zusätzlich noch händisch aus ner anderen Variablen aus der SPS holen... "Behaupte" ich jetzt mal

Grundsätzlich ist und bleibt Uhrzeitsynchronisation in Zusammenhang mit Zeitzonen und Sommerzeit ein leidiges Thema. Auch NTP ist nicht ohne Probleme. Und jetzt im Zusammenhang mit ablaufenden Zertifikaten wirds nochmal kritischer. Wenn dann die Sommerzeit irgendwann abgeschaft wird, gehts wieder los...

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo.

Vielleicht etwas off-topic, aber dennoch die Frage:
Warum wird in den meisten Fällen (bedeutet: wenn ich hier im Forum etwas zu diesem Thema lese) die SPS als "Uhrzeit-Master" angesehen?

Ich persönlich finde es leichter, umgekehrt zu synchronisieren, da im Zweifelsfall ein (autorisierter) Bediener über das HMI sofort und ohne Zusatz-Software (TIA o.ä.) korrigierend eingreifen kann, wenn eine Uhrzeit nicht passt.
Ich verwende dazu eine simple DATE_AND_TIME-Variable plus eine boolsche Variable als sogenanntes ActionFlag, um der Steuerung eine Uhrzeit-Synchronisation mitzuteilen.

Bitte gerne Meinungen dazu.


Gruß, Fred

 

[TheLevel]

Ich würde "behaupten" der Bereichszeiger "Datum/Uhrzeit PLC" stellt einfach die Paneluhr, ohne die Zeitzone zu beachten? Aber grundsätzlich müsste man das testen mit der jeweiligen TIA Version und ner Alarmtafel, ob dann die Zeiten dort stimmen...
Bei den Comfortpanels funktioniert die Uhrzeitsynchronisation schon, aber nicht die Sommer/Winterzeitumstellung... die musst Du zusätzlich noch händisch aus ner anderen Variablen aus der SPS holen... "Behaupte" ich jetzt mal

Ich behaupte: wenn in der SPS in der hw-config die automatische Sommer/Winterzeit Umstellung konfiguriert ist, dann liest die Lokalzeit in der SPS die richtige Uhrzeit aus und das HMI hat dann gar keine Wahl, als genau die auch anzuzeigen.

 

[TheLevel]

Hallo.

Vielleicht etwas off-topic, aber dennoch die Frage:
Warum wird in den meisten Fällen (bedeutet: wenn ich hier im Forum etwas zu diesem Thema lese) die SPS als "Uhrzeit-Master" angesehen?

Ich persönlich finde es leichter, umgekehrt zu synchronisieren, da im Zweifelsfall ein (autorisierter) Bediener über das HMI sofort und ohne Zusatz-Software (TIA o.ä.) korrigierend eingreifen kann, wenn eine Uhrzeit nicht passt.
Ich verwende dazu eine simple DATE_AND_TIME-Variable plus eine boolsche Variable als sogenanntes ActionFlag, um der Steuerung eine Uhrzeit-Synchronisation mitzuteilen.

Bitte gerne Meinungen dazu.


Gruß, Fred

Zwei Gründe:
a) die SPS Uhrzeit läuft genauer als die HMI Uhrzeit (war zumindest in meiner Welt früher so) - also muss man auf dem Weg seltener korrigieren.
b) Auf der SPS funktioniert (zumindest in den "neuen") die automatische Umschaltung zwischen Sommer und Winterzeit und auf dem HMI - naja, siehe diesen Thread.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum wird in den meisten Fällen (bedeutet: wenn ich hier im Forum etwas zu diesem Thema lese) die SPS als "Uhrzeit-Master" angesehen?

Bei uns bekommt die SPS die Uhrzeit vom Leitsystem und reichts an das Panel weiter...

Ich behaupte: wenn in der SPS in der hw-config die automatische Sommer/Winterzeit Umstellung konfiguriert ist, dann liest die Lokalzeit in der SPS die richtige Uhrzeit aus und das HMI hat dann gar keine Wahl, als genau die auch anzuzeigen.

Siemens schreibt doch selber, dass das nicht geht:

SIOS

support.industry.siemens.com

oder meinst Du die VAriante mit dem Bereichszeiger? Dann wäre das vermutlich so

 

[TheLevel]

Bei uns bekommt die SPS die Uhrzeit vom Leitsystem und reichts an das Panel weiter...


Siemens schreibt doch selber, dass das nicht geht:

SIOS

support.industry.siemens.com

oder meinst Du die VAriante mit dem Bereichszeiger? Dann wäre das vermutlich so

Moment, mein Fehler, ich bezog mich auf den Bereichszeiger - die von dir verlinkte Anleitung auf HMI-Zeitsynchronisation als Slave

 

[PN/DP]

Warum wird in den meisten Fällen (bedeutet: wenn ich hier im Forum etwas zu diesem Thema lese) die SPS als "Uhrzeit-Master" angesehen?

"Traditionell" hatten die Siemens Panels immer nur eine ganz billige Software-Uhr ohne Pufferung eingebaut, die bei Spannung Aus auch nicht weiterlief. Die SPS ist meistens immer eingeschaltet oder die Uhr läuft Batterie- oder Kondensator-gepuffert. Und die SPS-Uhr läuft gewöhnlich genauer, auch ohne Uhrzeit-Sync.
Wie gut die Uhr in neueren Comfort-Panels ist weiß ich nicht.

Wenn das HMI der Uhrzeit-Master ist, und es wird ein HMI-Panel ausgetauscht oder hochgefahren und die Uhr ist noch nicht korrekt gestellt (na, welcher Service-Mann stellt die Panel-Uhr bevor er das Netzwerk-Kabel ins Panel steckt? ), dann würde alleine das zum Verstellen der SPS-Uhr führen - und welche Auswirkungen das auf das SPS-Programm hat??? Das kann bis zum STOP der CPU führen falls da Uhrzeit-Alarme aktiviert sind oder plötzlich negative Zeitdifferenzen berechnet werden oder ...

Harald

 

[TheLevel]

Zuviel Werbung?
-> Hier kostenlos registrieren

"Traditionell" hatten die Siemens Panels immer nur eine ganz billige Software-Uhr ohne Pufferung eingebaut, die bei Spannung Aus auch nicht weiterlief.

Und hier sieht man wieder, wer älter ist *duckundweg*

Wenn das HMI der Uhrzeit-Master ist, und es wird ein HMI-Panel ausgetauscht oder hochgefahren und die Uhr ist noch nicht korrekt gestellt (na, welcher Service-Mann stellt die Panel-Uhr bevor er das Netzwerk-Kabel ins Panel steckt? ), dann würde alleine das zum Verstellen der SPS-Uhr führen - und welche Auswirkungen das auf das SPS-Programm hat??? Das kann bis zum STOP der CPU führen falls da Uhrzeit-Alarme aktiviert sind oder plötzlich negative Zeitdifferenzen berechnet werden oder ...

Vor allem: wer in dieser Situation steht und von hinten über den Diagnosepuffer eine Fehlersuche anfängt, hat eine ganze Weile Beschäftigung...

 

[faust]

Hallo zusammen,

danke für das schnelle Feedback.

"Traditionell" hatten die Siemens Panels immer nur eine ganz billige Software-Uhr ohne Pufferung eingebaut, die bei Spannung Aus auch nicht weiterlief. Die SPS ist meistens immer eingeschaltet oder die Uhr läuft Batterie- oder Kondensator-gepuffert. Und die SPS-Uhr läuft gewöhnlich genauer, auch ohne Uhrzeit-Sync.
Wie gut die Uhr in neueren Comfort-Panels ist weiß ich nicht.

Wenn das HMI der Uhrzeit-Master ist, und es wird ein HMI-Panel ausgetauscht oder hochgefahren und die Uhr ist noch nicht korrekt gestellt (na, welcher Service-Mann stellt die Panel-Uhr bevor er das Netzwerk-Kabel ins Panel steckt? ), dann würde alleine das zum Verstellen der SPS-Uhr führen - und welche Auswirkungen das auf das SPS-Programm hat??? Das kann bis zum STOP der CPU führen falls da Uhrzeit-Alarme aktiviert sind oder plötzlich negative Zeitdifferenzen berechnet werden oder ...

Harald

Das Problem des Panel-Tauschs stellte sich mir in dieser Form bis dato nicht, da
+ bei unseren Maschinen die Uhrzeit SPS-programmtechnisch keine Relevanz hat (nur im HMI),
+ immer nur vorbespielte und korrekt parametrierte (Comfort-)Panels ausgetauscht wurden.

Vor allem: wer in dieser Situation steht und von hinten über den Diagnosepuffer eine Fehlersuche anfängt, hat eine ganze Weile Beschäftigung...

Auch dieses Problem würde sich für uns nicht stellen, da unsere bzw. die Kunden-Servicetechniker ja wissen würden, dass die Uhrzeit vom Panel gesteuert wird.


Gruß, Fred

 

[JSEngineering]

Warum wird in den meisten Fällen (bedeutet: wenn ich hier im Forum etwas zu diesem Thema lese) die SPS als "Uhrzeit-Master" angesehen?

Ich würde das mal ganz pragmatisch so sehen: Die SPS ist die zentrale Einheit, die zentrale Logik. Da drumherum gruppiert sich alles. Also kommt die Zeit aus der zentralen Stelle.
Außerdem kann ich ein HMI auf unbestimmte Zeit abschalten, die Maschine läuft trotzdem weiter, weil die SPS läuft. Wer versorgt nun die SPS mit der aktuellen Zeit?

Dein Konzept ließe mich spätestens beim zweiten Panel die Frage stellen: Wer ist denn jetzt Master? Aus welchem Panel heraus stelle ich die Zeit?

Die SPS in der Mitte ist der Master und drum herum kann ich nun "beliebig" viele HMI anordnen, die dann die Zeit-Slaves sind.

Meine Vermutung wäre auch, daß nicht die HMI keine Zeit-Master sind, weil sie ungenau sind, sondern umgekehrt: Sie sind ungenau, weil man erwartet, daß sie von der SPS synchronisiert werden.

 

[Gustel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,
mich wundert es das an einem TP2200 die richtige Uhrzeit angezeigt wird und an den anderen zwei, eine Stunde zu wenig. Ich habe heute mal nach unterschieden geschaut.
Das Panel mit der richtigen Uhrzeit hat F-State 07 die anderen beiden 05.
Unter Systeminformation -> Versionen ist die Datei die ACE_HMI.dll noch bei allen gleiche, doch die FwBaseRes404, 405 usw haben eine unterschiedliche Version.
Könnte da das Problem liegen warum eins die richtige Uhrzeit anzeigt und die anderen beiden nicht?

Gruß

 

[escride1]

Hallo zusammen,

danke für das schnelle Feedback.


Das Problem des Panel-Tauschs stellte sich mir in dieser Form bis dato nicht, da
+ bei unseren Maschinen die Uhrzeit SPS-programmtechnisch keine Relevanz hat (nur im HMI),
+ immer nur vorbespielte und korrekt parametrierte (Comfort-)Panels ausgetauscht wurden.


Auch dieses Problem würde sich für uns nicht stellen, da unsere bzw. die Kunden-Servicetechniker ja wissen würden, dass die Uhrzeit vom Panel gesteuert wird.


Gruß, Fred

Du beschreibst ein Verhalten bei Euren bisherigen Steuerungen.
Wenn Ihr aber in Zukunft irgendwann dann doch mal die SPS-Zeit nutzen müsst dann könnt Ihr von da an zweigleisig in verschiedenen Projekten fahren. Mal so, mal so. Das will eigentlich niemand, immer eine Notiz irgendwo hinschreiben: Achtung, hier tickt die Uhr anders als sonst!

mich wundert es das an einem TP2200 die richtige Uhrzeit angezeigt wird und an den anderen zwei, eine Stunde zu wenig. Ich habe heute mal nach unterschieden geschaut.

Das TP2200 kann mit Berlin (+1) und Sommer (+1) umgehen. Die anderen bekommen Sommer (+1) aber haben keinen Peil von Berlin (+1) und addieren demzufolge ne Stunde zu wenig auf die UTC.

Aus welchem Grund das so ist weiß nur Siemens. Ich hätte früher mal behauptet das es nicht so schwer sein kann in nem Basicpanel die Uhrzeitfunktion einzubinden und in die anderen zu übernehmen, aber Pustekuchen. Wird wohl für jede Panelvariante was neues erfunden, wohl noch nicht rund genug.


Wie schon mehrfach beschrieben:
Die Einstellung im HMI mit Bereichszeiger sowie in der CPU mit RD_LOC_T ist eine Kleinigkeit.
Das Panel kann dennoch die Zeit in der CPU verstellen. Einfach ein kleines Bildchen mit einem Datum/Uhrzeit aktuell, eines mit Soll sowie ein Button "Uhrzeit stellen" um der SPS dann mitzuteilen sie soll mit dem Sollwert ihre Uhr einstellen. So machen wir das seit Jahren und es gibt nie Probleme, kann auch jederzeit auf jedem Paneltypen aus der Bibliothek reinkopiert werden was wieder rum die Programmierzeit für den Part auf "nahezu" null reduziert.

Die richtige Zeit in einer Anlage sollte mMn generell in der CPU liegen. Die HMIs sind so dumm wie möglich zu halten (daher auch nur im "Notfall" auf Skripte zurückgreifen), um eine Konsistenz der gesamten Daten möglichst in der CPU zu behalten. Das erleichtert auch den Austausch der HMI im Fehlerfall: Austauschen, Projekt laden, Starten. Da muss man nicht erst noch irgendwelche Daten hier und dort sichern oder kopieren etc.
Dies erleichtert aber auch wie angesprochen die Fehlersuche im Diagnosepuffer. Wenn der erstmal 1980 eingetragen hat und dann wieder ne richtige Zeit und dann wieder 1980 dann werden die Zeilen zwar anhand der Nummer dennoch richtig in der Reihenfolge sortiert, aber man hat Mühe diese Zeitpunkte eventuellen anderen Ereignissen zuzuordnen.

 

[Gustel]

Du beschreibst ein Verhalten bei Euren bisherigen Steuerungen.
Wenn Ihr aber in Zukunft irgendwann dann doch mal die SPS-Zeit nutzen müsst dann könnt Ihr von da an zweigleisig in verschiedenen Projekten fahren. Mal so, mal so. Das will eigentlich niemand, immer eine Notiz irgendwo hinschreiben: Achtung, hier tickt die Uhr anders als sonst!


Das TP2200 kann mit Berlin (+1) und Sommer (+1) umgehen. Die anderen bekommen Sommer (+1) aber haben keinen Peil von Berlin (+1) und addieren demzufolge ne Stunde zu wenig auf die UTC.

Aus welchem Grund das so ist weiß nur Siemens. Ich hätte früher mal behauptet das es nicht so schwer sein kann in nem Basicpanel die Uhrzeitfunktion einzubinden und in die anderen zu übernehmen, aber Pustekuchen. Wird wohl für jede Panelvariante was neues erfunden, wohl noch nicht rund genug.


Wie schon mehrfach beschrieben:
Die Einstellung im HMI mit Bereichszeiger sowie in der CPU mit RD_LOC_T ist eine Kleinigkeit.
Das Panel kann dennoch die Zeit in der CPU verstellen. Einfach ein kleines Bildchen mit einem Datum/Uhrzeit aktuell, eines mit Soll sowie ein Button "Uhrzeit stellen" um der SPS dann mitzuteilen sie soll mit dem Sollwert ihre Uhr einstellen. So machen wir das seit Jahren und es gibt nie Probleme, kann auch jederzeit auf jedem Paneltypen aus der Bibliothek reinkopiert werden was wieder rum die Programmierzeit für den Part auf "nahezu" null reduziert.

Die richtige Zeit in einer Anlage sollte mMn generell in der CPU liegen. Die HMIs sind so dumm wie möglich zu halten (daher auch nur im "Notfall" auf Skripte zurückgreifen), um eine Konsistenz der gesamten Daten möglichst in der CPU zu behalten. Das erleichtert auch den Austausch der HMI im Fehlerfall: Austauschen, Projekt laden, Starten. Da muss man nicht erst noch irgendwelche Daten hier und dort sichern oder kopieren etc.
Dies erleichtert aber auch wie angesprochen die Fehlersuche im Diagnosepuffer. Wenn der erstmal 1980 eingetragen hat und dann wieder ne richtige Zeit und dann wieder 1980 dann werden die Zeilen zwar anhand der Nummer dennoch richtig in der Reihenfolge sortiert, aber man hat Mühe diese Zeitpunkte eventuellen anderen Ereignissen zuzuordnen.

Ich meinte nicht die KTP1200, sondern es sind drei TP2200 verbaut. Ein TP2200 (das mit F-State 07) zeigt die richige Zeit die anderen beiden TP2200 (mit F-Sate 05) zeigen 1 Stunde zuz wenig. Alle drei TP2200 sind von der Systemzeit (Berlin, UTC+1 usw) gleich eingestellt
Die Versionsunterschiede beziehen sich auch nur auf die TP2200.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich meinte nicht die KTP1200, sondern es sind drei TP2200 verbaut. Ein TP2200 (das mit F-State 07) zeigt die richige Zeit die anderen beiden TP2200 (mit F-Sate 05) zeigen 1 Stunde zuz wenig. Alle drei TP2200 sind von der Systemzeit (Berlin, UTC+1 usw) gleich eingestellt
Die Versionsunterschiede beziehen sich auch nur auf die TP2200.

Jo, und Siemens bekommt es nicht gebacken den Standort und die Sommerzeitverschiebung auf allen Panels gleich einzupflegen und deshalb ist bei dem einen Panel +2 weil Berlin und Sommerzeit, beim anderen nur die Sommerzeit +1 und beim anderen wiederrum nur die Ortszeit +1 in der Rechnung.

Wieso das so kompliziert sein muss weiß (keiner) "?".
Mein Beispiel folgt eben der "Annahme" das Siemens es nicht hinbekommt (wie man ja deutlich an verschiedenen FW-Versionen mit unterschiedlichem Verhalten sowie dem unterschiedlichen Verhalten auf Varianten der Panels (Basic, Comfort) sehen kann).

Also kann ich nur empfehlen die ganze Umwandlung im Panel zu deaktivieren, das immer, wenn einstellbar auf UTC stehen lassen und die CPU (welche interessanterweise über Generationen hinweg richtig läuft) immer seine Lokalzeit in einen DB, den DB als Bereichszeiger in den Panels zu verlinken. Dadurch ist es immer richtig im Panel und man muss nicht mehr beachten ob das nun so oder so ist.

 

[volker]

ich habe jetzt nicht alle beiträge gelesen. Aber wenn die CPU die korrekte uhrzeit hat.....
deaktiviere ntp auf dem panel und füge im panel einen bereichszeiger 'datum uhrzeit sps' hinzu.
minimale abgleichzeit ist 1 minute.

 

[faust]

Hallo nochmal,

@JSEngineering und @escride1: vielen Dank auch für Euer Feedback.

Ist natürlich (fast) eine Philosophie-Frage, deshalb möchte ich meinen Off-Topic-Querschuss auch nicht allzu weit vertieft sehen.

Für 99% unserer Anwendungsfälle
+ Ein Master-HMI pro Steuerung,
+ Anbindung der Maschine ans Hausnetz zum Datenaustausch über eine separate Schnittstelle des HMI,
+ Fernzugriffs-Anbindung über Modem,
+ keine oder nicht prozessrelevante Verwendung der Uhrzeit in der Steuerungslogik,
hat sich unser Ansatz bewährt.

Was ja nicht heißen muss, dass man auf ewig so verfährt und -vor allen Dingen- ihn auf einen Sockel hebt und als Allheilmittel ansieht )


Gruß, Fred

 

[Olli_BS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie geht ihr denn mit der "2029"-Problematik um?
Unter der Prämisse PLC soll Master sein und bei "Slave" bei Verbindung angeben funktioniert die Aktualisierung (manchmal/oft ?) nur bei Neuaufbau...
...dann bleibt man ja auf dem Bereichszeiger "Datum/Uhrzeit PLC" hängen. Und der funktioniert ganz offiziell nur bis zum Jahr 2029.
Das war mal weit weg, aber jetzt ?!?

Hinweis Beachten Sie bei der Eingabe in den Datenbereich "Jahr", dass die Werte 80-99 die Jahreszahlen 1980 bis 1999 und die Werte 0-29 die Jahreszahlen 2000 bis 2029 ergeben.

 

[escride1]

War mir bisher nicht bekannt.
Wie darf man den Satz verstehen? Nach 2029 würde 30 nicht 2030 sein sondern eventuell 1930? Und warum sollte das relevant sein wenn das Datum und Jahr nach 01-01-1980 eingegeben werden und nicht 01-01-80?

 

[Olli_BS]

Steht so in der Hilfe und in Dokumenten.
Und Jahr 2031 funktioniert wirklich nicht. Fehlermeldung "Datum/Uhr konnte nicht gestellt werden" (oder so ähnlich)
Gestern getestet. Runtime V16 aktuell.
Deinen restlichen Fragen schliesse ich mich total an.
Genaugenommen ist es natürlich ein 2030-Bug...