TIA Zeitmessung zwischen Sensor und Aktor

Avi

Level-1
Beiträge
3
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo erfahrene SPSler,

ich bin Student und arbeite dieses Semester mit einer SPS CPU 314-C 2 (https://mall.industry.siemens.com/ma...314-6EH04-0AB0) und dem TIA Portal V16.

Ich möchte im Rahmen meines Projekts Zeiten mit Hilfe der SPS erfassen.
Ist es möglich die Zeit zwischen folgenden Start- und Endzeitpunkten zu erfassen:
  • Startzeitpunkt: Sensor wird ausgelöst Endzeitpunkt: Aktor wird geschaltet / Also die Zeit zwischen dem Auslösen eines Sensors und bis der betreffende Aktor ausgelöst wird

  • Startpunkt: S1 wird gedrückt Endzeitpunkt: S2 wird gedrückt


Vielen Dank schonmal und viele Grüße
Avi
 
Zuletzt bearbeitet:
Moin Avi,

ja, das ist möglich.

Allerdings gibt es da 1001 verschiedene Möglichkeiten von einfach bis genau ;)

z.B.:
- mit einem Sekundentakt und einem Freigabesignal einen Wert inkrementieren
- in einem Weckalarm-OB einen Wert inkrementieren
- Bei Start und Stopp jeweils die Systemzeit auslesen und die Differenz bilden
- ...


VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
(1) Wie genau soll denn die Messung sein? Die SPS alleine kann nur die Zeit messen ab wann der Digitaleingang vom Sensor geschaltet wird und die SPS den Wert des Digitaleingangs einliest bis zur Ausgabe des Aktor-Schaltbefehls an den Digitalausgang.
(2) Was hat S2 mit Deiner Aufgabe zu tun?

Harald
 
Hallo und danke für die schnellen Antworten,

ich möchte die Zeit erfassen wie es in (1) beschrieben ist.
S1 und S2 sind nur Beispiele und haben nichts direkt mit meiner Aufgabe zu tun.

Grüße
Avi
 
Moin,

noch ein paar Fragen:
- Wie genau muss die Messung sein ( +/- 1s, ...)?
- Wie klein muss die Auflösung sein (Sekunden, Millisekunden, ...)?
- Wie lang kann eine Aufzeichung werden (Stunden, Tage, Jahre, ...)?

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus,

eine Auflösung in Millisekunden ist angedacht. Die Länge einer Aufzeichnung spielt sich im Millisekunden oder Sekunden-Bereich ab.
Zur Genauigkeit habe ich mir keine Gedanken gemacht, aber so genau wie möglich wäre wünschenswert.

Grüße
Avi
 
... dann würde ich zyklisch die Systemzeit auslesen und bei Start und Stop jeweils speichern. Die Differenz daraus ist dann deine Aktionszeit - das wäre dann Millisekunden-genau - allerdings mußt du die Zykluszeit der SPS dabei dann als möglichen Messfehler mit einkalkulieren (oder vernachlässigen 8)).

Gruß
Larry
 
Alternativ und ähnlich genau:

Mit dem Startsignal einen Timer starten (TON) und kontinuierlich den Timerausgang ET (Elapsed Time) auslesen bis das Stopp-Signal kommt.
Der zuletzt anliegende Wert im ET übernehmen.
Wichtig: erst Wert übernehmen, dann Timer stoppen. Sonst ist das Ergebniss null.

Den Parameter PT ( Prozesstime) auf einen ausreichend hohen Wert legen, z.B. 1 Minute.
 
Da er eine 314-C zur Verfügung hat, könnte er auch mit Hilfe der Zählereingänge messen. Laut Handbuch von Siemens:

Bei einer max. Zählfrequenz von 1 kHz wird immer die Zeit zwischen zwei aufeinanderfolgenden Zählflanken gemessen. Die gemessene Periodendauer können Sie entweder direkt über die Eingangsdaten (E-Daten) des Submoduls "Zählen" lesen oder durch Direktzugriff auf die Peripherie.

Die Belegung der Eingangsdaten müssen Sie parametrieren. Entweder ist der Zählwert oder die Periodendauer lesbar.

Man könnte überlegen, parallel den Sensor und Aktor zusätzlich auf einen Zählereingang zu legen. Damit hätte man eine von der Zykluszeit unabhängige und deutlich genauere Messung.
 
Da er eine 314-C zur Verfügung hat, könnte er auch mit Hilfe der Zählereingänge messen. Laut Handbuch von Siemens:



Man könnte überlegen, parallel den Sensor und Aktor zusätzlich auf einen Zählereingang zu legen. Damit hätte man eine von der Zykluszeit unabhängige und deutlich genauere Messung.

Da finde ich die Verwendung die Verwendung von interupts etwas übersichtlicher.
Den Umweg über den schnellen Zähler, würde ich als sehr exotisch empfinden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... dann würde ich zyklisch die Systemzeit auslesen
Achtung, damit ist TIME_TCK (SFC64) gemeint - nicht die Uhrzeit! (*)
Und darauf achten, den alle ca. 24 Tage auftretenden Überlauf herauszurechnen.

(*) Die Uhrzeit sollte man nicht verwenden, weil die während der Zeitmessung verstellt werden könnte, z.B. durch Uhrzeit-Synchronisation.

Harald
 
Da finde ich die Verwendung die Verwendung von interupts etwas übersichtlicher.
Den Umweg über den schnellen Zähler, würde ich als sehr exotisch empfinden.

Ist natürlich auch eine Möglichkeit. Aber:

... aber so genau wie möglich wäre wünschenswert.

Ich glaube, genauer geht's nicht. Denn bei Interrupts hast Du auch noch wiederum die Programm-Umschaltzeit dabei.

Klar: Ob man die Genauigkeit benötigt, muß der TE entscheiden, kann aber ggf. interessant sein, wenn man Aktor-Reaktionszeiten messen möchte.
 
Ist natürlich auch eine Möglichkeit. Aber:



Ich glaube, genauer geht's nicht. Denn bei Interrupts hast Du auch noch wiederum die Programm-Umschaltzeit dabei.

Klar: Ob man die Genauigkeit benötigt, muß der TE entscheiden, kann aber ggf. interessant sein, wenn man Aktor-Reaktionszeiten messen möchte.

Die Umschaltzeit bewegt sich eher in microsekunden, kann man getrost vernachlässigen.
Ansonsten macht ein Alarm-Eingang keinen Sinn.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke die Aussage "so genau wie möglich" ist hier das Problem.
Wenn man das als Ansatz sieht, dauert es nicht lange und es werden Atomuhren gefordert.

Die Idee mit den Zählereingängen ist eigentlich sehr gut, aber für mich wie Kanonen auf Spatzen.
Wenn der TE nicht weiß, wie man auf einer SPS eine Zeit misst,... na dann viel Spaß bei der IBN einer Zählerkarte!

Es sollte eswas Praktikabeles dabei sein, etwas was man auf Bedarf schnell einfügen kann.
 
Ich kann Euch ja verstehen, anders herum:

Wenn ich als Prof. einem Studenten schon eine SPS mit solch einem Feature an die Hand gebe, dann erwarte ich auch, dass er mehr macht, als zwei Mal die CPU-Zeit zu lesen oder einen Timer auszulesen... [emoji6]

Schlussendlich ist es ein Aufzeigen einer Möglichkeit, wer was wie umsetzen würde bleibt dahin gestellt: 1000 Wege / Rom, ... [emoji3]
 
Zurück
Oben