Genauer Zeittakt

[ukofumo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

Ich benötige einen genauen Taktgeber (Sekunden-Takt) um Laufzeiten von bestimmten Aktionen zu bestimmen. Leider sind die Standardmöglichkeiten der S7-300/400 CPU's da "etwas Ungenau"
Mit dem Sekunden-Takt zähle ich einfach einen INT-Wert hoch, bei Messzyklen um die 15 Minuten habe ich aber zum Teil erhebliche Abweichungen.
Anfangs habe ich mir aus dem Taktmerker (Mxxx.5) einen Flankenmerker gebildet der mir dann den Wert hochzählt. Später bin ich zu den Normalen Timern übergegangen, Vorteil: ich kann durch verändern der Zeitkonstante den Takt selber bestimmen. Für Sekundentakt: S5T#1s, was aber abhängig von der Zykluszeit auch zu zum teil erhebliche Abweichungen führt, durch Anpassen der Zeitkonstante (z.B. S5T#970ms) kann ich das Verhalten dann entsprechend anpassen.
Ich muss dann aber bei jeder neuen Anlage den Taktgeber jedesmal neu ausstoppen und entsprechend einstellen
Es muss doch eine Möglichkeit geben einen Sekundengenauen Takt zu erzeugen der Unabhängig von der Zykluszeit arbeitet und auch den Vergleich mit einer Stoppuhr standhält (Abweichung bei 15 Min. max. 100ms)

Gruß ukofumo

 

[mitchih]

Probiers mal mit dem OB35.

Das Aufrufintervall kanst du einstellen und dieser baustein würde dann jede Sekunde durchlaufen. Und das Passt auch. So mache ich mir meine "Zeiterfassung" wenn ich Belegtzeiten etc.. auswerten muss.

 

[jabba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diese vorgehendweise ist zyklusabhängig, der mögchliche Fehler von z.B. einem Zyklus kann sich dann jede Sekunde aufaddieren, bei 15m hast du ja 900* mit einem Fehler in der zeit gerechnet.

Ich würde wenn es genau sein soll ganz anders rangehen.

Wenn Du nur die Laufzeiten von Aktionen messen willst, schreib dir eine Baustein dazu.
Bei start wird die aktuelle Systemzeit mittels SFC64 gelesen, bei Stop die Diffferenz ermiitelt und ausgegeben. Dann hast du nur in zwei Zyklen den Fehler,je nachdem wann Start oder Stop ausgewertet wird.
Aber Achtung im baustein must du auf den Überlauf am Timer achten.

 

[Thomas_v2.1]

Leider lässt sich Siemens in den Beschreibungen zur Genauigkeit des SFC64 nicht aus. Ich würde aber mal davon ausgehen, dass die Funktion die Genauigkeit der Systemuhr einer S7 hat.
Der Systemuhr S7-300 weist das Datenblatt eine Abweichung pro Tag < 10s aus.
Das würde für das 15 Minuten Intervall bedeuten, dass die Uhr in diesem Intervall systembedingt eine Abweichung von max. 104 ms haben kann (10s / 1440 = 6,9ms pro Minute). Im Normalfall wird die Uhr genauer sein, aber zur Auslegung muss man immer vom schlechtesten Wert ausgehen.

Also kann man es drehen und wenden wie man will, ohne Zusatzmaßnahmen (DCF77, NTP, etc.) bekommt man es nicht genauer hin.

 

[Blockmove]

Also kann man es drehen und wenden wie man will, ohne Zusatzmaßnahmen (DCF77, NTP, etc.) bekommt man es nicht genauer hin.

Doch kann man:
Du ermittelst die Abweichung der Systemuhr über einen längeren Zeitraum (1 Monat).
Daraus kannst du dir dann einen Korrekturfaktor berechnen.
Damit kannst du deine Messergebnisse bewerten.

Gruß
Dieter

 

[Proxy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt noch eine möglichkeit.

Mach einen Startmerker ab wann gemessen wird. Dann zähl die letzte zykluszeit in dein DINT und am ende stoppst du dann die merker wieder dann hast du die zeit wie lange dein teil bearbeitet wurde.

 

[jabba]

Die Lösungen scheinen ihn nicht zu interessieren.

Das mit der Zykluszeit hört sich zwar gut an, bringt aber Fehlerquellen, da die Zykluszeit einen Fehler von +-1ms haben kann (Auflösung) .
Bei schätzen wir 20ms Zykluszeit währen das im extremfall 45s.
Die wenigsten Fehlerzeiten hätte man in ohne Zusatzkosten Kombination aus meiner Lösung und der von Blockmove.

 

[ukofumo]

Moin zusammen

Ich hab mir nun mal über alle gemachten Möglichkeiten Gedanken gemacht, Die Möglichkeit die Systemzeit bei Start und Ende der Messung auszuwerten scheidet m.E. aus, der Bediener möchte gerne die "laufende Uhr" wärend des Prozesses sehen. Imoment erscheint mir der OB35 noch am sinnvollsten, allerdings benötigen wir den auch für div. anderen Funktionen (PID / Siwarex etc.) und leider nicht immer mit einem Zeittakt der ganzzahlig in einer Sekunde aufgeht.
Noch was zur Basis: Aktuell habe ich das Problem bei einer 314 CPU die inzwischen Programmtechnisch ziemlich bis zum Anschlag ausgereizt, Arbeitsspeicher ca.85%; Zykluszeit Mittelwert um die 15-20ms, kann jedoch bis auf 70-80ms hochschnellen. (ein Austausch der CPU scheidet wg. Kostengründe aus! zusätzliche Hardware auch).
Mit einer Abweichung von 104ms wie sie Thomas_v2.1 angedeutet hat kann ich durchaus leben. Wichtig wäre das wenn eine Stoppuhr z.B. 14min 38sec anzeigt, meine gemessene Zeit auch 14min 38sec anzeigt und das ganze sollte möglichst "universell" anwendbar sein, egal welche CPU ich mit welcher Zykluszeit betreibe, so das ich mir nich immer wieder bei jedem neuen Projekt gedanken zur "Genauigkeit" machen muss...
Eigendlich würde ich den OB35 da schon als ausreichend Ideal empfinden, Leider haben wir aber auch Anwendungen wo der Weckalarm z.B mit 150ms getaktet wird. Dummerweise haben die "kleineren" CPU's oft nur einen Weckalarm zur Verfügung.
Ich bin inzwischen auf die OSCAD.lib gestoßen die mehrere Taktgeber (z.B. CLK_PRG) zur Verfügung stellt, ich finde da aber keinen genaueren Hinweiß wo und wie bei diesen Bausteinen der Zeittakt abgeleitet wird, und kann somit auch nicht auf die Genauigkeit schließen.

Gruß ukofumo

 

[crash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Aufrufintervall des OB35 ist doch egal.
Du addierst im OB35 deine Zeit entsprechen des Aufrufintervalls auf.
Bei 150ms also immer 150 dazu addieren.
Zur Anzeige musst du das nur noch in Minuten und Sekunden umrechnen...fertich!

 

[ukofumo]

Aaahrrg....

Manchmal sieht man den Wald vor lauter Bäumen nicht

Gruß Uwe

 

[Larry Laffer]

Die Möglichkeit die Systemzeit bei Start und Ende der Messung auszuwerten scheidet m.E. aus, der Bediener möchte gerne die "laufende Uhr" wärend des Prozesses sehen.

Das mit der Systemzeit ist dann aber auch noch drin ... die abgelaufene Zeit ist nämlich immer die aktuelle Zeit minus der Start-Zeit - und das kannst du auch zyklisch berechnen (ohne Aufwand) ...

Gruß
LL

 

[jabba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Rüüschtisch.

In der zeit wo du dir Gedanken gemacht hast und hier rumschreibst, wären die zwei oder drei Netzwerke schon lange fertig, und das auf ein paar ms genau. Die Lösungen kamen schon sehr früh, aber Versuch du ruhig weiter eine Lösung zu finden.

 

[Blockmove]

Die Lösungen kamen schon sehr früh, aber Versuch du ruhig weiter eine Lösung zu finden.

Ach Jabba manche sind halt etwas lernresistent.
Da lohnt sich die ganze Mühe halt kaum.
Ist in der virtuellen Welt nicht als, als in der Realen.

Gruß
Dieter

 

[Thomas_v2.1]

In der zeit wo du dir Gedanken gemacht hast und hier rumschreibst, wären die zwei oder drei Netzwerke schon lange fertig, und das auf ein paar ms genau. Die Lösungen kamen schon sehr früh, aber Versuch du ruhig weiter eine Lösung zu finden.

Wenn du jetzt noch die Quelle für die Genauigkeit "paar ms" nennen könntest.

Weil die Siemens Dokumentationen folgendes offen lassen:

a) Ob die Hardware-Uhr (welche mittels READ_CLK gelesen werden kann) die gleiche "Taktbasis" wie die Systemzeit (auszulesen mit TIME_TICK) hat.
Daraus folgt auch die Frage, ob der Anpassfaktor aus der Hardwarekonfiguration nur auf die Hardware-Uhr, oder eben auch auf den Systemtakt wirkt.

b) Keine Angaben zur Genauigkeit der Systemzeit.
Zitat Online-Hilfe:
"Das Zeitraster und die Genauigkeit der Systemzeit betragen bei S7-400 und bei der CPU 318 1 ms, bei allen anderen CPUs der S7-300 10 ms."

1 ms pro Woche? Pro Tag? Oder gar pro Sekunde?


Was ich gefunden habe, ist ein Dokument zur Genauigkeit von OB35 Aufrufen:
http://support.automation.siemens.com/WW/view/de/21626316

Eine Messmethode ist dort das Auslesen der Systemzeit eben mit einem SFC (welcher SFC bleibt undokumentiert, aber "mikrosekundengenauigkeit" wird erwähnt). Aber auch dort fehlt eine Angabe zur Genauigkeit eben dieser CPU-Zeit.

 

[jabba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ging hier darum, das er ja z.B. 104ms wie berechnet akzeptieren würde.

Mein Grundvorschlag ist einfach in der Hinsicht zu beachten, da wenn man einen Timertick baut, ich diese Fehler iwe in meiner Berechnung 900* habe.

Über die Systemzeit habe ich nur den Fehler der zwei Zyklen in denen das abgefragt wird und die Ungenauigkeit der internen Systemzeit.

Wenn man das so wie vorgeschlagen macht ist man bestimmt nicht im Bereich von 1ms bei 15Min, aber bestimtt unter 500ms.

Und deutlich besser als ein Taktmerker oder so etwas.

 

[crash]

Immer dieses rumgehacke auf dem Taktmerker

Und deutlich besser als ein Taktmerker oder so etwas.

Jetzt muss ich den armen Taktmerker aber mal in Schutz nehmen.
Programmiert doch mal eine Uhr mit Hilfe des Taktmerkers.
Sind ja nur ein paar Zeilen.
Also jede Sekunde die Flanke zum aufaddieren der Sekunden.
Sekunden = 60 -> Minuten +1 und Sekunden auf 0.
Minuten = 60 -> Stunden +1 und Minuten auf 0.
usw...
Dann werdet ihr sehen dass das Ding absolut synchron zur Systemzeit läuft.
Abweichungen könnten sich erst ergeben wenn die Zykluszeit so groß wird
dass man Flanken des Taktmerkers nicht mehr mit bekommt.

Ich lehne mich jetzt mal wieder zurück... :sm19:

So jetzt kommt ihr...

 

[Blockmove]

b) Keine Angaben zur Genauigkeit der Systemzeit.
Zitat Online-Hilfe:
"Das Zeitraster und die Genauigkeit der Systemzeit betragen bei S7-400 und bei der CPU 318 1 ms, bei allen anderen CPUs der S7-300 10 ms."

1 ms pro Woche? Pro Tag? Oder gar pro Sekunde?

Eigentlich sagt doch genau der Begriff Zeitraster um was es hier geht:
Die Ticks kommen entweder alle 1 ms oder alle 10ms.
Timer haben bei den normalen S7-300 eine mögliche Abweichung von 10ms (unabhängig vom Zyklus).
Ist vergleichbar mit dem berühmten letzten Digit bei Digitalmultimetern.

Wenn du es genau haben willst, dann ist das Auslesen der Echtzeituhr und das Bewerten mit einem Korrekturfaktor das Genaueste und eigentlich auch das Einfachste.

Gruß
Dieter

 

[Tom...]

Zuviel Werbung?
-> Hier kostenlos registrieren

var
sekundentakt:bool;
Systemzeit_sekunden,gemerkte_sekunden:int;
end_var

lies doch einfach die Systemzeit deiner Steuerung aus und speichere die Sekunden in: Systemzeit_sekunden.
Dann machst Du

sekundentakt:=(systemzeit_sekunden<>gemrkte_sekunden);
gemerkte_sekunden:=systemzeit_sekunden;

Dann fast Du einen Sekundentakt ( für einen Zyklus ) absolut synchron zur Uhr Deiner Steuerung...

Thomas

 

[jabba]

J
Ich lehne mich jetzt mal wieder zurück... :sm19:

So jetzt kommt ihr...

Kommen noch ein paar, ich lehne mich auch mal zurück, hab ja heute schon einen vergrault, das reicht für heute.

 

[Longbow]

Jetzt muss ich den armen Taktmerker aber mal in Schutz nehmen.
Programmiert doch mal eine Uhr mit Hilfe des Taktmerkers.
Sind ja nur ein paar Zeilen.
Also jede Sekunde die Flanke zum aufaddieren der Sekunden.
Sekunden = 60 -> Minuten +1 und Sekunden auf 0.
Minuten = 60 -> Stunden +1 und Minuten auf 0.
usw...
Dann werdet ihr sehen dass das Ding absolut synchron zur Systemzeit läuft.
Abweichungen könnten sich erst ergeben wenn die Zykluszeit so groß wird
dass man Flanken des Taktmerkers nicht mehr mit bekommt.

Ich lehne mich jetzt mal wieder zurück... :sm19:

So jetzt kommt ihr...

Die Zeit hängt ohne weitere Maßnahmen (GPS-Uhr, Zeitsynchronisation, DCF77) immer von einem Oszillator ab!

Wenn die CPU gut ist, dann hat sie einen Oszillator für alles!

Beispiel:
SIEMENS CPUs (z.B. 318/319/414) verwenden z.B. für die Systemzeit und für den Profibus Master unterschiedliche Oszillatoren, deswegen läuft die
Zeit zwischen dem Äquidistanzzyklus im Profibus DPV2 der Systemzeit davon.


Je nach eingesetztem Oszillatoren und Temperatur kann das schon mal 100ppm sein. Hört sich nicht viel an, aber das sind in 1 Sekunde bereits 100µs Unterschied!


Wenn man wirklich eine genaue Zeit braucht hilft nur GPS oder DCF77 (oder die eigene Atomuhr ;-) )