Step 7 Uhrzeitsyncro - Fehler bei vollen Zahlen

sleepless

Level-1
Beiträge
44
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo ihr,

ich habe mir ein kleines Script, bzw. das bekannte Sommer/Winter-Zeit Script umgebaut, sodass eine NTP Synchronisierung damit ebenfalls funktioniert.

Einzig allein eine Tatsache macht mir Kopfschmerzen: Volle zahlen werden falsch geschrieben. (10, 20 Uhr)
heißt, eine Korrektur von 18 auf 19 Uhr geschieht nach einer NTP Zeitsyncro automatisch.
Muss der gute jedoch von 19 auf 20 Uhr korrigieren, passiert nichts und der Set-CLK Baustein gibt eine Fehlermeldung aus.

Anbei ein Screenshot mit meinem Problem. Ich tippe auf ein Datenformat Fehler???

Das gleiche passiert auch mit dem Befehl "INC 1"...

Unbenannt.jpg

Danke euch im Voraus und bitte sagt etwas, auch wenn das noch so unwahrscheinlich sein sollte...
 
Hallo,

kann das sein, dass die Einträge in der Struktur Date_and_Time im BCD- Format sind?
Wenn Du 0x09 incrementierst, kommt 0x0A dabei raus - und das ist kein gültiger BCD-Wert.

mfg
R.Erdmann
 
Hallo,

Sorry, Nachtrag:
Das geht zwar um 10:00, aber nicht um 20:00;

Richtig wäre:
...
L #Stunde
BTI
+ 1
ITB
T LB 3
...

mfg

R.Erdmann
 
Hallo,

Na, dös is net das selbe.
0x08 + 1 = 0x09 -> Das ist das selbe;
0x09 + 1 = 0x0a -> Das ist 10 als dezimal und als BCD ungültig;
0x09 nach INT bleibt 0x09; + 1 => 0x0a; nach BCD => 0x10;
0x10 + 1 = 0x11 -> Das ist das selbe; 10 BCD + 1 = 11 BCD;
0x19 + 1 = 0x1a -> 20 (BCD) + 1 = 0x1a und als BCD ungültig;
0x19 nach INT = 25; + 1 => 26; nach BCD => 0x20;
0x20 + 1 = 0x21 -> Das ist das selbe; 10 BCD + 1 = 11 BCD;

mfg

R.Erdmann
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich habe mir ein kleines Script, bzw. das bekannte Sommer/Winter-Zeit Script umgebaut, sodass eine NTP Synchronisierung damit ebenfalls funktioniert.
[...]
der Set-CLK Baustein gibt eine Fehlermeldung aus.
(Was für ein "bekanntes Sommer/Winter-Zeit Script" meinst Du??)

Wenn eine SPS-Uhr per NTP synchronisiert wird, dann ist es ziemlich sinnfrei, die Uhr auch noch zusätzlich zu verstellen. Bei der nächsten Synchronisation wird die Uhr wieder auf UTC gestellt. Bei synchronisierten Uhren muß die Lokalzeit (CET/CEST) aus der Systemzeit der Uhr (UTC) berechnet werden, jedoch auf keinen Fall die Uhr selber verstellt werden. Für die Umrechnung UTC zu Lokalzeit gibt es von Siemens den Standard-Baustein FC61 "BT_LT" und z.B. einen schlankeren FC BT_LT_3 von mir:
Wenn man bei einer S7-300-PN-CPU oder S7-400-PN-CPU oder ET200-PN-CPU die Uhrzeitsynchronisation per NTP aktiviert, dann läuft die CPU-Uhr in UTC - weil man für diese CPU keine Zeitzone einstellen kann und NTP ja UTC liefert.

Wenn man bei einem IE-CP CP343-1 oder CP443-1 die Uhrzeitsynchronisation per NTP aktiviert, dann berücksichtigt der CP eine einstellbare Zeitzonenkorrektur, so daß die CPU-Uhr bei standardmäßig eingestellter Zeitzone "(GMT +01:00)" "trotz" NTP-Synchronisation in UTC+1 läuft. (Bei flüchtiger Betrachtung könnte der Eindruck entstehen, NTP würde die Uhrzeit in UTC+1 liefern.) Damit auch bei NTP-Synchronisation via CP die CPU-Uhr in UTC läuft, müßte man die Korrektur abschalten, indem man die Zeitzone auf "(GMT)" einstellt.

Welche SIMATIC S7-300/S7-400 Baugruppen unterstützen das NTP-Uhrzeittelegramm zur Synchronisation der Systemzeit und wie aktiviere ich diese Art der Zeitsynchronisation?

Weil nun wegen dieser CP-Geschichte manche meiner SPS-Uhren in UTC und manche in UTC+1 laufen, gibt es meinen Baustein BT_LT_3 in 2 Versionen, einmal für UTC+1 bei CP in GMT+1, und einmal für UTC bei PN-CPU oder CP mit GMT-Einstellung.

Große Linkliste: Uhrzeitsynchronisation - Zeitsynchronisation im Automatisierungsumfeld

Harald
 
(Was für ein "bekanntes Sommer/Winter-Zeit Script" meinst Du??)
Das hier aus dem Forum

Wenn eine SPS-Uhr per NTP synchronisiert wird, dann ist es ziemlich sinnfrei, die Uhr auch noch zusätzlich zu verstellen. Bei der nächsten Synchronisation wird die Uhr wieder auf UTC gestellt.
In Deutschland ist's nicht sinnfrei. Stichwort "Sommer / Winter"...

Bei synchronisierten Uhren muß die Lokalzeit (CET/CEST) aus der Systemzeit der Uhr (UTC) berechnet werden, jedoch auf keinen Fall die Uhr selber verstellt werden. Für die Umrechnung UTC zu Lokalzeit gibt es von Siemens den Standard-Baustein FC61 "BT_LT" und z.B. einen schlankeren FC BT_LT_3

Die Aussage kann man ergänzen, dann wäre sie vollständig korrekt. Sie aber nur als den einzigen Weg hinzustellen ist schlichtweg falsch.

1. Eine CP macht bei mir diese Arbeit. Kann man im Hardwaremenü per Mausclick auswählen (Zeitzone). Mag sein, das dies evtl. bei den CPU's mit eigener Ethernetschnittstelle nicht der Fall ist, aber bei einer mit einer CP braucht man keine extra Bausteine.
2. Um die Sommer/Winterzeit zu bekommen muss die Stunde verstellt werden.

Nichts anderes habe ich eingepflegt. Ich bearbeite nur die Stunde und bleibe trotzdem synchron.

@ Erdmann: Danke. Das war's. Ich hatte richtigen riecher, aber kein Plan den umzusetzen. Danke auch für das Präzise Hintergrundwissen. Leider bin ich manches mal zu faul zum auflösen dieser Dinge...:rolleyes:
 
2. Um die Sommer/Winterzeit zu bekommen muss die Stunde verstellt werden.

Nichts anderes habe ich eingepflegt. Ich bearbeite nur die Stunde und bleibe trotzdem synchron.
Die Uhr muß nicht verstellt werden. Die Sommerzeit kann aus der unverstellten Uhrzeit berechnet werden. Die Uhr verstellen ist schlichtweg der falsche Weg.

Du scheinst wohl auch bei Deinem eigentlichen Problem keinen Plan zu haben, was Du da eigentlich machst...
Oder erkläre uns mal, wie bei Dir die Uhrzeitsynchronisation und die Winter/Sommerzeitzeitumstellung per Verstellen der SPS-Uhr funktioniert (oder funktionieren soll). Spielst Du zum Umstellungszeitpunkt jedesmal eine geänderte HW-Konfig ein? Oder findet Deine NTP-Synchronisation nur zweimal im Jahr statt?

Nochmal langsam: bei aktivierter Uhrzeitsynchronisation ist es sinnlos die Uhr zu verstellen, weil beim nächsten Synchronisationszeitpunkt die Uhr wieder auf die vom NTP-Server abgeleitete Uhrzeit gestellt wird. Ein einmaliges Verstellen hat keinen Bestand und ein zyklisches Verstellen würde zu einem zyklischen vor/zurück-Springen der Uhr führen. Kannst Du folgen?

(Im übrigen reicht es bei (zyklischem) Verstellen nicht, nur die Stunde zu verstellen. Ab 23:00 müßte auch das Datum verstellt werden.)

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Sommerzeit kann aus der unverstellten Uhrzeit berechnet werden. Die Uhr verstellen ist schlichtweg der falsche Weg.
Und das funktioniert nicht. Die Uhr verstellen ist der einzige Weg.
Warum?
Weil es kein Trigger gibt, der mir sagt "So, jetzt wurde per NTP Synchronisiert". Wurde mir hier im Forum schon mehrfach bestätigt. Also, wat willst dann wie berechnen lassen, wenn du nicht weißt, wann er rechnen soll?
Bin jedenfalls offen für eine Lösung, um das synchron umrechnen zu lassen. Das war mein erster Ansatz - und darauf konnte mir niemand bis dato eine Lösung Präsentieren.

Du scheinst wohl auch bei Deinem eigentlichen Problem keinen Plan zu haben, was Du da eigentlich machst...
Oh, wohl mehr als du glaubst. Ich hab meine Variante seid zwei Wochen Astrein am laufen. NTP Synchron und um eine Stunde verstellt - Sommerzeit :cool:

Ein einmaliges Verstellen hat keinen Bestand und ein zyklisches Verstellen würde zu einem zyklischen vor/zurück-Springen der Uhr führen. Kannst Du folgen?
Vollkommen richtig. Nur wer sagt, das ich das einmalig mache?
Mein Eingangs gezeigtes Script lässt eher auf eine Aktion / Reaktion Programmierung schließen.
Um's ganz grob zu sagen habe ich es so realisiert: Stellt der Horst mir die Stunde um 1 während der Sommerzeit zurück (Aktion), so verstelle ich die Stunde wieder um 1 nach oben (Reaktion).
Und es wird per NTP Stündlich Synchronisiert.

Und dieses Prinzip funktioniert wunderbar. Um das ganze halt nur auf die Sommerzeit zu beschränken brauchte ich das fertige Script zur Ermittlung "Wann ist Sommer"...

(Im übrigen reicht es bei (zyklischem) Verstellen nicht, nur die Stunde zu verstellen. Ab 23:00 müßte auch das Datum verstellt werden.)
Reicht, wenn man das auf Tag & Monat beschränkt...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vollkommen richtig. Nur wer sagt, das ich das einmalig mache?
Mein Eingangs gezeigtes Script lässt eher auf eine Aktion / Reaktion Programmierung schließen.
Um's ganz grob zu sagen habe ich es so realisiert: Stellt der Horst mir die Stunde um 1 während der Sommerzeit zurück (Aktion), so verstelle ich die Stunde wieder um 1 nach oben (Reaktion).
Und es wird per NTP Stündlich Synchronisiert.

Gut hast du nix am laufen, dass zu einer bestimmten Zeit etwas tun muss.
Ist dir klar dass diese krude Programmierung z.B. bei den Neuen CPUs und Panels dann auch zu einem Zeitspringen im Panel führen kann? Völlig unvorhergesehen?

Wann Syncht eigentlich NTP synch die ZEIT? am Anfang des Zyklus? am Ende? Mittendrin?

mfG René
 
Ist dir klar dass diese krude Programmierung z.B. bei den Neuen CPUs und Panels dann auch zu einem Zeitspringen im Panel führen kann? Völlig unvorhergesehen?
Diese Programmierung ist bei den neuen Panels auch nicht mehr notwendig, da die Panels am Netzwerk hängen, selbst syncen und weil Betriebssystem auch fein selber die Sommerzeit bilden.
Und dann synct man sowieso vom Panel zur sps und nicht anders herum.

Deshalb verstehe ich deine Frage nicht...

Wann Syncht eigentlich NTP synch die ZEIT? am Anfang des Zyklus? am Ende? Mittendrin?
Kein Plan. Habs in den Dokumentationen gesucht und net gefunden. Und dafür extra etwas zu basteln schien mir zu aufwendig. Ich teste lieber... Und bis jetzt alles top.
Selbst den logs, die auf dem Panel geschrieben werden, stört das net, da zu träge...
 
Wie Harald schon gesagt hat

Die Uhr muß nicht verstellt werden. Die Sommerzeit kann aus der unverstellten Uhrzeit berechnet werden. Die Uhr verstellen ist schlichtweg der falsche Weg.

Es ist auch für die 300er ein völlig sinnloses unterfangen die uhrzeit entgegen die NTP synchronisation zu verstellen. Ich sehe auch überhaupt keine Notwendigkeit drin, denn für alles was man im Programm macht, kann man die lokalzeit errechnen (inkl. Sommerzeit) da man ja die Zeit eh erst in eine Variable kopieren muss. kann man da auch gleich eine globale Lokalzeitvariable erstellen.

Das einzige das bei der 300 direkt mit der Systemzeit arbeitet ist die Diagnose. Da könnte man ja die Lokalzeit wollen, nur so wie du das jetzt machst weiss man in der Diagnose überhaupt nie welche zur Lokalzeit abgelegt wurde und welche zu UTC (oder GMT). Weil du ja frischfröhlich azyklisch an der Systemzeit rumschraubst.

Aber vielleicht fehlt uns auch der Durchblick und du kannst uns auch nur einen sinnvollen Grund für deine Vorgehensweise nennen?

Und das funktioniert nicht. Die Uhr verstellen ist der einzige Weg.
Warum?
Weil es kein Trigger gibt, der mir sagt "So, jetzt wurde per NTP Synchronisiert". Wurde mir hier im Forum schon mehrfach bestätigt. Also, wat willst dann wie berechnen lassen, wenn du nicht weißt, wann er rechnen soll?
Bin jedenfalls offen für eine Lösung, um das synchron umrechnen zu lassen. Das war mein erster Ansatz - und darauf konnte mir niemand bis dato eine Lösung Präsentieren.

Wozu brauchst du einen Trigger um zu merken jetzt wurde per NTP synchronisiert? Es reicht doch das du weisst die Systemzeit wird regelmässig synchronisiert.
Mir read_clk liest du die Zeit addierst die ggf Zeitzone (wenn Systemzeit auf UTC synchronisiert wird) ggf noch die Sommerzeit und schon hast du die Lokalzeit welche du in einer Variable hast. Und mit der Variable kannst du immer arbeiten weil da immer die korrekte Lokalzeit drin steht, scheissegal wann NTP das letzte mal synchronisiert hat.
Rechnen tust du also immer. In jedem Zyklus. Nur schreibst du nicht die Systemzeit zurück sondern arbeitest mit der Lokalzeit in der Variable.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur schreibst du nicht die Systemzeit zurück sondern arbeitest mit der Lokalzeit in der Variable.
Richtig, demnach wäre der Mist überflüssig.

Nur WinCC arbeitet nicht mit selbst erstellten Variablen zusammen. Das verkorkste Programm ever nimmt für Kurvendarstellungen, Fehlerlogs etc. immer die Systemzeit der CPU. Und darin liegt der Grund meiner Auswahl.
Es seidenn, ich hab irgendwo im WinCC Flex. eine Einstellung übersehen, in der man dafür eine Individuelle Variable nehmen kann... :ROFLMAO:
 
Aber du synchronisierst doch die CPU Zeit mit dem NTP Server. Nicht das Panel.
Dem panel schickst du dann die Lokalzeit zum Synchronisieren.
Ich nehme an mit Fehlerlogs meinst du die Meldebehandlung. Da nimmt er die Panelzeit, nicht die CPU Zeit. Die ist dem Panel egal.

mfG René
 
Bekommt man auf der 300/400, in Verbindung mit Uhrzeit-OBs wie OB10-17 keine Uhrzeitfehler?
Wenn die Systemzeit der CPU vom NTP auf UTC+1 und dann erst irgendwo im Zyklus auf CEST gestellt wird,
müsste, sofern man die OBs nutzt, doch wahrscheinlich jedesmal ein Fehler kommen wenn die Systemzeit sich ändert.

Gibt's dafür nicht sogar ein Diagnoseereignis wegen "Uhrzeitsprung" mit OB80-Aufruf?

Wenn per NTP und die CPU nicht auf UTC laufen darf, dann würd ich auch eher NTP->Panel->CPU machen bevor ich da ständig Uhrzeitsprünge hab.

Edit: Hatte das Problem vor einiger Zeit sogar schon mal... :p
http://www.sps-forum.de/simatic/31171-cpu-stop-durch-uhrzeitsprung.html
 
Zuletzt bearbeitet:
Zurück
Oben