# Zwei Uhren in einer SPS



## horseshoe (18 Januar 2006)

An alle Mathematiker/Informatiker!!!

Wer kann mir helfen???
Ich habe folgendes Problem:

Ich moechte zwei Kategorien von Ereignisse mit YEAR/MONTH/DAY/HOUR/MINUTE/SECOND protokollieren/zeitstempeln und in der SPS in einem Stack ablegen:
- Event-Kategorie 1: Parameter-Aenderungen des Operators --> System_Clock
- Event-Kategorie 2: Prozess-Events --> Operator_Clock

Bedingung: Beide Uhren sollen in der SPS - und nicht etwa verteilt in SPS und Terminal - laufen!

Folgende Anforderungen stehen an die Uhren:
--> System_Clock
- soll einfach durchlaufen, ohne dass die Uhr (auf die reale Uhrzeit) gestellt wird
- die Uhr darf/kann nicht vom Operator gestellt oder manipuliert werden
- interessant ist in erster Linie nur das Delta zwischen den Events; durch Rueckrechnen kann der reale Zeitpunkt des Events ermittelt werden

--> Operator_Clock
- die Uhr (Date/Time) kann vom Operator ueber Terminal gestellt/veraendert werden um (fuer den Operator) moeglichst genau die Prozess-Events zu protokollieren
- separate Aenderungen von YEAR, MONTH, DAY, HOUR, MINUTE ueber Tasten (INC/DEC)

Sinn und Zweck:
Ich moechte im Schadensfall anhand der Informationen der System_Clock-Zeitstempel Ablaeufe zeitlich zueinander (z.B. ueber die Differenz der Zeitstempel) protokollieren koennen, ohne das Manipulationen ueber Veraenderung der Operator_Clock (Zurueckstellen und Neudurchfahren des Zeitraums) moeglich sind.

(Das Auslesen der Zeitstempel der System_Clock soll entweder ueber den Programm-Editor oder ueber eine Passwort-geschuetzte Seite im Terminal erfolgen.)

Da es in der SPS aber nur eine Uhr gibt, habe ich gedacht, die Operator_Clock ueber einen Offset auf die System_Clock laufen zu lassen.
Der (variable) Offset ergibt sich durch die Einstellung der Operator_Clock (Aenderung von YEAR, MONTH, DAY, HOUR, MINUTE ueber Tasten (INC/DEC)).

Die Sache ist aber doch nicht so einfach, da ich jeden moeglichen Uebertrag (Beispiel Day = 26 / Offset = 12 --> 26+12=38 --> hat der betrachtete Monat nun 28, 29, 30 oder 31 Tage usw.) betrachten muss.

Hat jemand eine Idee, wie ich dass Problem in einer SPS(!) loesen kann???
Ein moegliches Stichwort waere z.B. "Julianischer Kalender".

Noch ein Hinweis: Ein (sekundengenauer) programm-gesteuerter Zaehler (Zaehlumfang z.B. 1 Jahr) kommt nicht in Frage, da mir beim Stop der SPS das Delta zwischen Zaehlerstand_heute und Zaehlerstand_Event verfaelscht wird und somit ein Rueckrechnen auf die Event-Uhrzeit nicht mehr moeglich wird.


Bin gespannt auf Eure Vorschlaege!!!

Danke im Voraus!


----------



## Ralle (19 Januar 2006)

Mit welcher SPS arbeitest du?
In Step7 gibt es das Format Date:



> DATE	16	Jahr-Monat-Tag	D#1990-01-01	D#2168-12-31
> 
> Das Datum wird als vorzeichenlose Ganzzahl in Tagen dargestellt, wobei der erste Tag der 1. Jan. 1990 ist.



Damit kann man ganz normal rechnen, also z.Bsp. 15 Tage aufaddieren. Das errrechnete Datum wird mit den richtigen Tagen etc. umgerechnet.


Ähnliches gilt für fas Format Time of Day:



> Datentyp	                                Länge (Bit)	   Format
> 
> TIME_OF_DAY oder TOD	32	   Tageszeit in
> 
> ...


----------



## horseshoe (19 Januar 2006)

Hallo Ralle,

habe im konkreten Fall eine MISUBISHI Q-System auf dem Tisch.

Der dort vorhandene Datentyp TIME (32 bit) hat ein Range von -24dxxx ... +24dxxx. Das ist fuer meine Zwecke nicht ausreichend.
(In dem von mir geschilderten Fall kann es ohne weiteres sein, dass die Operator_Clock von der System_Clock um mehr als +/-24d abweicht.)

Anmerkung: Ich habe - nach Auslesen der System-Uhr - die einzelnen Date/Time-Werte (YEAR/MONTH/DAY/HOUR/MINUTE/SECOND) im INT16 zur Verfuegung.

Gruss horseshoe


----------



## Ralle (19 Januar 2006)

Lies dir das mal durch:

http://www.coding-board.de/board/archive/index.php/t-14847.html

Sind auch etliche brauchbare Hinweise drin. Um ein wenig Rechnerei kommst du wohl nicht herum, hat denn deine Mitschubitschi  :lol: kein Date-Format?

Noch ein Link: http://home.nordwest.net/hgm/kalender/kal-prt.htm


----------



## MSB (19 Januar 2006)

Die Q hat wie S7-300 auch nur eine Systemuhr, diese läuft auch bei Spannung aus.
Es gibt keine Softwaremäßige Möglichkeit den Zeitpunkt des Abschaltens mitzubekommen.
Und nichts was außer der Systemuhr nach Spannung-Aus noch weiterlaufen könnte.

@Ralle wofür das Format DATE? Braucht man das wohl? Bei Mitsubishi jedenfalls nicht!
Jetzt im Ernst es gibt nur diesen Namen nicht, bei Mitsubishi ist das einfach ein Array,
ähnlich dem Date Format von Siemens.

Rechnen kann auch die Q siehe Befehle:
Date +
Date -

Wenn dann ist das irgendwie im HMI-System zu lösen, und nicht auf der SPS.

Mfg
Manuel


----------



## Ralle (19 Januar 2006)

@MSB
Ich kenne die Q nicht, mein erster Vorschlag war ja Date zu nutzen.
Eine Uhr reicht ja, die zweite Uhrzeit (vom Bediener verstellbar) soll ja nur als feste Differenz zur "Hauptuhr" laufen, die Differenz ist einstellbar.
Da die Differenz > 1 Tag sein kann, muß man auch mit dem Datum rechnen können, oder?


----------



## Markus (19 Januar 2006)

ok ich mach das jetzt mal ganz vereinfacht:

V_SystemUhr
diese uhr läuft auch bei Spannung aus und kann vom bediehner eingestellt werden.


V-OperatorUhr
dieser Uhr kann nicht vom Operator verstellt werden, läuft aber synchron zur systemuhr mit einem beliebigen offset.



in einem interuppt der zb. jede secunde aufgerufen wird passiert folgendes: (bei der s7 wäre das ein ob35 oä - siehe hw-config)

V_TimeDif = V_SytemUhr - V_SystemUhr_Last_Cycle

IF V_TimeDif <= 2 Sekunden
THEN
V_Operator_Uhr = V_OperatorUhr + TimeDif
ELSE 

// Sytemzeit wurde neu eingestellt weil Differenz zum letzten Zyklus nicht plausibel ist

V_Operator_Uhr = V_OperatorUhr + 1 Sekunde

// V_OperatorUhr wird bei jeder Änderung der Systemzeit (eventuell) um <1S verfälscht, aber das sollte tolerierbar sein

END IF




V_SystemUhr_Last_Cycle = V_SystemUhr // Sichern für nächsten Zyklus





Bei SPS Anlauf passiert das:
(bei S7 wäre das zb im OB100)


V_TimeDif = V_SytemUhr - V_SystemUhr_Last_Cycle

V_Operator_Uhr = V_OperatorUhr + TimeDif

// es darf nicht möglich sein die systemzeit bei cpu-stop zu ändern
// terminal kann ja softwareseitig so veriegelt werden über eine zwsp
// variable die nur im laufenden programm in die systemzeit schreibt.
// oder was weiß ich gibt viele möglichkeiten bis zur holzhammer
//  methode das display über einen sps ausgang schaltet...




hab das jetzt so hiegeschrieben wie es aus mir rausgequollen ist.
fange ab jetzt an auch darüber nachzudenken, was gefällt euch daran nicht? irgendwo wird doch noch ein haken sein...


----------



## horseshoe (26 Januar 2006)

Hallo Leute,

vielen Dank fuer Eure Muehe, aber die richtige Loesung war - denke ich - noch nicht dabei.

Ich versuche nochmal das Problem (vielleicht etwas einfacher) darzustellen:

Ich moechte die System-Uhr (= System_Clock) der SPS bei Auslieferung der SPS auf GMT (Datum/Uhrzeit) stellen. Auf diese System-Uhr soll der Operator keinen(!) Zugriff haben. (Eigentlich soll/braucht er nicht mal wissen, dass diese Uhr in der SPS existiert!) Durch diese Uhr sollen (bestimmte) Events zwecks Protokollierung (mit der nicht manipulierbaren System_Clock) Zeit-gestempelt und in der SPS in einem Stack (Event-Nr. + System_Clock-Zeitstempel) archiviert werden.

Eine zweite - fuer den Operator (z.B. auf Ortszeit) einstellbare Uhr (= Operator_Clock) soll (die) Events mit dem Zeitstempel der Ortszeit versehen und die Informationen (Event + Operator_Clock-Zeitstempel) in einem anderen Stack ablegen. Die in diesem Stack gespeicherten Informationen sind fuer den Operator ueber Terminal einsehbar.

Vorstellung:
Die Operator_Clock hat als Basis die System_Clock und laeuft zu dieser mit einem variablen (positiven oder negativen) Offset. Verstellt nun der Operator die Operator_Clock, so verstellt er nur den Offset.

Sinn und Zweck:
Ich moechte eine nicht manipulierbare Zeitbasis (= System_Clock) zum Zeit-stempeln von Events nutzen, dem Operator aber eine einstellbare Uhr fuer seine Zeitstempel zur Verfuegung stellen.

Grund, warum ich nicht die Terminal-Uhr fuer die Operator_Zeit nehme:
1. Ich habe mehrere Terminals und muesste diese untereinander synchronisieren.
2. Ich benoetige beide Zeitbasen zentral in der SPS.
3. Ich moechte die Terminals (hinsichtlich Programmierung) ziemlich "dumm" halten.

Hat jemand eine Loesung???

Gruss horseshoe


----------



## Helmut (26 Januar 2006)

Hallo horseshoe,

warum packst du nicht einfach eine neue Uhr hinzu?

Möglichkeiten:

1. Mit DCF77. Gibts für Siemens ab ~100€
(Info: www.siemens.de/siplus). Läuft über dig. Eingänge

2. Mit GPS-Empfänger (läuft über ASCII-Protokoll)

Die "Standarduhr" kannst dann für den Anwender verwenden. Die "DCF77/GPS-Uhr" für deine "Zeitbasis".

Damit hast immer eine Uhr für deine Protokollierung und eine, die der Anwender auch einstellen kann.

Gruss

Helmut


----------



## Markus (26 Januar 2006)

was ist an meiner lösung nicht ok?


----------



## Helmut (26 Januar 2006)

Hallo Markus,

was ich aus deinem Vorschlag noch nicht verstanden habe ist, wenn die CPU in Stop oder Spannung aus und intern nur eine Uhr vorhanden ist, wie verhält sich das mit der "Operator-Uhr"? Die kann ja eigentlich nicht laufen, da CPU in Stop.

Oder läuft die auch ohne Saft?

gruss

Helmut


----------



## Markus (26 Januar 2006)

habe ich doch ganz uznten geschrieben:


```
Bei SPS Anlauf passiert das: 
(bei S7 wäre das zb im OB100) 


V_TimeDif = V_SytemUhr - V_SystemUhr_Last_Cycle 

V_Operator_Uhr = V_OperatorUhr + TimeDif 

// es darf nicht möglich sein die systemzeit bei cpu-stop zu ändern 
// terminal kann ja softwareseitig so veriegelt werden über eine zwsp 
// variable die nur im laufenden programm in die systemzeit schreibt. 
// oder was weiß ich gibt viele möglichkeiten bis zur holzhammer 
// methode das display über einen sps ausgang schaltet...
```

die uhr steht zwar bei cpu-stop, und wird erst im anlauf wieder angepasst, aber das solte ja auch kein problem sein. wozu brauche ich die uhr schon bei cpu stopp....


----------

