TIA Zeitmessung zwischen zwei Impulsen

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

ich möchte gerne mittels eines Sensors die Zeit zwischen zwei Impulsen (S7-1200) messen. Der Motor dreht ca. von 0 bis 350 U/min.

Dazu habe ich schon mal den Baustein "RD_SYS_T" beschaltet.

Die Frage ist nun, welche Zeiteinheit





ziehe ich für die Berechnung heran?


Geht das mit "NANOSECOND"?


Vielen Dank!

 

[M-Ott]

Würde ich mit dem T_DIFF machen. Da kannst Du beide DTL dran hängen und bekommst Deine Differenz heraus.

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das geht schon. Bedenke wenn du das im Normalen Zyklus machst hast du da einen Jitter von mehreren Milisekunden drin. Da bringen dir die Nanosekunden also nicht so viel.
Wenn der Takt nur alle 100ms kommt, könntest du das mit einem Interrupt machen und die Systemzeit vergleichen.
Allerdings gibt es für die Drehzahlerfassung von Motoren eigentlich Karten die dafür gebaut wurden.
z.B. 6AT8007-1AA10-0AA0

mfG René

 

[spirit]

Vielen Dank schon mal.

@M-Ott: Aber auch da brauche ich ja eine Einheit für die Zeit - welche?

@vollmi: Mal von so einer Karte abgesehen; wäre dann die Zeiteinheit "SECONDS" besser geeignet?


Am Ende soll dann die Drehzahl rauskommen ...

 

[vollmi]

Nah die kleinste Einheit die du verrechnen kannst verkleinert ja auch den Fehler. Wenn du Nanosekunden hast, dann nimm sie.

 

[Mecha2211]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die 1200 hat doch schnelle Zähleingänge. Schau Dir die mal an, damit kannst Du das vielleicht auch erreichen. Wenn Du die Drehzahl suchst, kannst Du ja die Frequenzmessung nutzen.

 

[spirit]

Beitrag war Unfug ...

 

[RONIN]

Den Beitrag mit dem T_DIFF von M-Ott hast du im zweiten Anlauf ja gesehen.

Auch Siemens selber schlägt das so vor in einem seiner FAQs vor.
https://support.industry.siemens.com/cs/ww/de/view/52258130
Dort wird allerdings auch nicht auf die Problematik einer Systemzeitänderung hingewiesen, deshalb nochmal der Hinweis von mir.
Bedenke, wenn du die Systemzeit verwendest, dass diese auch zwischen den Anfangs- und dem End-Stempel verstellt werden kann.
Der End-Zeitstempel ist dann vielleicht sogar jünger als der Anfangszeitstempel - heißt negatives Ergebnis am T_DIFF.
Das musst du entsprechend behandeln (der gute alte TIME_TCK war schon praktisch...)

Die Genauigkeit der Messung (bzw. der Jitter) hängt natürlich von deiner Zykluszeit, Eingangsverzögerung, etc. ab.
Hatte die Thematik (für die 300er) hier mal ausführlich beschrieben.
http://www.sps-forum.de/simatic/695...hnen-visualisieren-post481563.html#post481563

Bei einer 1200er könnte der HSC mit Tech-Objekt aber sogar weniger Aufwand sein.

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den Beitrag mit dem T_DIFF von M-Ott hast du im zweiten Anlauf ja gesehen.

Yep, habe ich (noch) gesehen!

Läuft soweit erst mal alles ... *freu*

Dort wird allerdings auch nicht auf die Problematik einer Systemzeitänderung hingewiesen, deshalb nochmal der Hinweis von mir.
Bedenke, wenn du die Systemzeit verwendest, dass diese auch zwischen den Anfangs- und dem End-Stempel verstellt werden kann.
Der End-Zeitstempel ist dann vielleicht sogar jünger als der Anfangszeitstempel - heißt negatives Ergebnis am T_DIFF.
Das musst du entsprechend behandeln.

--> von Außen kommt doch eigentlich niemand an die Systemzeit heran, oder?

Und falls doch; würde hier eine Überwachung auf <0 helfen - um dann mittels "MOVE" einfach eine Null in die "Systemzeit_alt" zu schieben?

 

[RONIN]

--> von Außen kommt doch eigentlich niemand an die Systemzeit heran, oder?

Naja, hängt davon ab.
...wenn du am Panel eine Möglichkeit hast die Uhrzeit zu verstellen (also irgendwo WR_SYS_T oder WR_LOC_T im Programm...
...wenn du die Panel-Zeit mit der CPU-Zeit synchronisiert hast und das Panel Master ist...
...wenn die CPU über irgendeinen Weg per (z.B. per NTP) synchronisierst...
...Sommer/Winterzeit (aber nur wenn man so blöd ist die Lokalzeit zu nehmen)
...etc.

Und falls doch; würde hier eine Überwachung auf <0 helfen - um dann mittels "MOVE" einfach eine Null in die "Systemzeit_alt" zu schieben?

Reicht schon, bedenke auch noch die andere Richtung, wenn der Endzeitstempel viel viel älter ist als der vom Anfang.

Kann je nach Anwendung durch einfache Maßnahmen abgefangen werden, es gehört aber bedacht.

 

[spirit]

Ähm, noch ne dumme Frage - aber wie vergleiche ich eigentlich die Systemzeit (DTL) auf "<0"

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ähm, noch ne dumme Frage - aber wie vergleiche ich eigentlich die Systemzeit (DTL) auf "<0"

Da hast du tatsächlich was missverstanden...

Die Zeitstempel musst du nicht <0 prüfen, sondern die Zeitdifferenz die du aus dem T_DIFF rausbekommen hast.
Die ist vom Format TIME(LTIME). Die kannst du <0 prüfen.

Beispiel:
Start-Messung: 12:00:00
... die Systemzeit geht vor und jemand stellt nach...
Ende-Messung 11:59:30

Ergebnis von T_DIFF (IN1:=Starzeit; IN2:= Endzeit) ist dann minus 30 Sekunden.

 

[vollmi]

Ich würd das dann sowiso über einen Median FIFO von mindestens 10 Werten filtern. Damit hast du so einzelne Ausreisser oder Fehler draussen.

mfG René

 

[RONIN]

@vollmi: Oder am besten beides. Bedenken muss man es halt...

Gibt schließlich schon genug Anlagen auf dem Planeten die Crash bauen wenn Einer an der Uhr dreht.
Müssen dann nicht unbedingt eine Neue dazubauen.

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da hast du tatsächlich was missverstanden...

Die Zeitstempel musst du nicht <0 prüfen, sondern die Zeitdifferenz die du aus dem T_DIFF rausbekommen hast.
Die ist vom Format TIME(LTIME). Die kannst du <0 prüfen.

Beispiel:
Start-Messung: 12:00:00
... die Systemzeit geht vor und jemand stellt nach...
Ende-Messung 11:59:30

Ergebnis von T_DIFF (IN1:=Starzeit; IN2:= Endzeit) ist dann minus 30 Sekunden.

Lieben Dank RONIN,

ja das habe ich echt völlig falsch verstanden!


Um das Problem zu umgehen, müsste frau dann eine Null in T_DIFF schieben. War das so gemeint?

Naja, hängt davon ab.

...Sommer/Winterzeit (aber nur wenn man so blöd ist die Lokalzeit zu nehmen)
...etc.

... dachte eigentlich, dass das System das durch den Haken vor "Sommerzeitumstellung aktivieren" eigenständig regelt!

 

[RONIN]

1)

Das hängt ganz von deiner Anwendung ab.
Ich stelle die Frage anders: Was musst du machen wenn aus deiner Zeitmessung (dann umgerechnet in Umdrehung/min) plötzlich irgendeinen Fehlwert (2112312U/min oder -1231U/min) rauskommen. Je nachdem was du mit deinem Drehzahlmesswert machst kann sich das ja schlecht auf deinen Prozess auswirken. Wenn die Uhrzeit verstellt wird kann (da die Zeit zwischen zwei Impulsen falsch gemessen wird) ja so ein Wert wie oben aus der Berechnung rauskommen.

Was kannst du dagegen tun. Eine Filterung einbauen die solche Fehlmessungen korrekt aussortiert.
Entweder einfach über Grenzen oder Median.

Wichtig ist halt dass deine falscher Zeitwert es nicht in deine U/min-Berechnung schafft und möglicherweise Chaos in der Anlage macht. Sofern der Messwert einen Einfluss auf die Anlage hat.
​

2)

Das hängt davon ab welchen Baustein du zum Auslesen der Systemzeit nimmst.
RD_SYS_T: Alles OK, der ist in UTC -> keine Zeitumschaltung
RD_LOC_T: Schlecht, sofern genanntes Häckchen an ist spring die Uhr dann ja 2x im Jahr um. Heißt dann auch 2 Fehlmessungen.

​

 

[spirit]

1)

Das hängt ganz von deiner Anwendung ab.
Ich stelle die Frage anders: Was musst du machen wenn aus deiner Zeitmessung (dann umgerechnet in Umdrehung/min) plötzlich irgendeinen Fehlwert (2112312U/min oder -1231U/min) rauskommen. Je nachdem was du mit deinem Drehzahlmesswert machst kann sich das ja schlecht auf deinen Prozess auswirken. Wenn die Uhrzeit verstellt wird kann (da die Zeit zwischen zwei Impulsen falsch gemessen wird) ja so ein Wert wie oben aus der Berechnung rauskommen.

Was kannst du dagegen tun. Eine Filterung einbauen die solche Fehlmessungen korrekt aussortiert.
Entweder einfach über Grenzen oder Median.

Wichtig ist halt dass deine falscher Zeitwert es nicht in deine U/min-Berechnung schafft und möglicherweise Chaos in der Anlage macht. Sofern der Messwert einen Einfluss auf die Anlage hat.
​

2)

Das hängt davon ab welchen Baustein du zum Auslesen der Systemzeit nimmst.
RD_SYS_T: Alles OK, der ist in UTC -> keine Zeitumschaltung
RD_LOC_T: Schlecht, sofern genanntes Häckchen an ist spring die Uhr dann ja 2x im Jahr um. Heißt dann auch 2 Fehlmessungen.

​

Offensichtlich stelle ich mir die Situation unter 1) zu einfach vor ...


Ich war eigentlich der Meinung, dass folgendes Konstrukt





direkt hinter dem Baustein T_DIFF eingefügt, Abhilfe schaffen sollte, damit es so ein falscher (negativer) Zeitwert NICHT in die U/min-Berechnung schafft. Oder habe ich hier wieder die Rechnung ohne "Zyklusdenken" gemacht?



Soweit ich mich noch erinnere, hat mein Vorgänger immer davon gesprochen, dass es sich bei



schon um die Systemzeit, also RD_SYS_T, handelt.


Puh, diese SPS-Technik ...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zeitmessung abhängig von der Systemuhr würde ich nicht machen. Hat die S7-1200 tatsächlich nichts vergleichbares wie den TIME_TCK (SFC64)? Oder kann man da die OB1-Zykluszeit addieren? Es geht ja um Zeiten, die ca. 170ms kurz sein können. Die bekommt man mit einen IEC-Timer nicht genau genug erfasst.

Mal weiter denken:
Wie lang ist der Nocken der den Sensor betätigt? Wie lang ist die Zykluszeit der SPS?
Bei 360 U/Min und 10 Grad Nockenlänge ist der Impuls nur ca. 4,6ms lang.
Ich würde einen schnellen Zähleingang der S7-1200 nehmen, vielleicht als "Frequenzmessung".

Harald

 

[spirit]

Hi Harald,

leider gibt es TIME_TCK bei der S7-1200 nicht.

Einen IEC-Timer verwende ich nicht zur Berechnung der Drehzahl. Es läuft so weit auch alles stabil.


Bezüglich Fehlerkorrektur nochmals (allgemein) gefragt:

- in NW3 ist der Baustein T_DIFF programmiert
- in NW4 ist der Vergleich auf <0 programmiert // Schutz (siehe Thread #17)
- in NW5 erfolgt die Berechnung der Drehzahl

--> hätte dann der programmierte Schutz aus NW4 direkten Einfluss auf das nachfolgende NW5, so dass ein "falscher Wert" NICHT in die nachfolgende Berechnung einfließt?

 

[RONIN]

direkt hinter dem Baustein T_DIFF eingefügt, Abhilfe schaffen sollte, damit es so ein falscher (negativer) Zeitwert NICHT in die U/min-Berechnung schafft.

Ne, du denkst schon richtig. So killst du die falsche Zeitmessung.
Aber... Dafür gehst du mit einem Wert von 0 in deine U/min-Berechnung.
Damit kommt dann wahrscheinlich wieder ein falscher U/min-Wert raus, oder gar einen Division durch Null.

Besser wäre es wenn du bei einer fehlerhaften Zeitmessung die Berechnung nicht durchführst und den Fehlerwert einfach verwirfst.

schon um die Systemzeit, also RD_SYS_T, handelt.

Wie liest du denn die Sytemzeit zum Füttern des T_DIFF aus?