TIA Genauigkeit eines Timers

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebes Forum,

ich arbeite an einem kleinen Maschinenprogramm. Hierfür verwende ich das TIA Portal V19, ein WinCC TP700 HMI, eine S7 1514 CPU, eine ET200 Station und verschiedene Sensorik. Zum Auswerten von Messsignalen nutze ich Trace Funktionen. Ich zeichne sehr viele Abläufe auf. Bspw messe ich die Signaldauer eines Sensors oder ein Taktverhältnis.TON Timer sind ideal um eine Zeitdauer zu ermitteln, aber es gibt neben den Timern auch noch andere Möglichkeiten, wie z B die Verwendung der PLC Zeit mit Hilfe der Funktion TIME_TCK(). Jetzt wollte ich mal in die Runde fragen, ob es egal ist was ich nehme oder kann man sagen, dass TIME_TCK genauer misst? Ich rufe die Funktion zweimal auf und bilde die Differenz zwischen 2 Signalen.

Gruß

 

[Larry Laffer]

Egal wie du es machst - du hast immer ein Thema mit der Zykluszeit deiner SPS und der Verarbeitungszeit der Befehle.
Ich denke mal, dass du mit dem TON schon hinreichend genau genug bist / wirst - aber eine Frage : wie genau soll es denn sein ?

 

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

So genau wie möglich. Aktuell sieht es bei meiner letzten Messung so aus, dass ich um wenige Millisekunden daneben liege. Den Grund dafür muss ich noch untersuchen. Mir kam nur der Gedanke, dass der Time_tck besser ist. Kann auch falsch sein diese Annahme.

 

[Stadtranduser]

du hast immer ein Thema mit der Zykluszeit deiner SPS

Wirkt sich halt wie ein Jitter aus.

Also:

Aktuell sieht es bei meiner letzten Messung so aus, dass ich um wenige Millisekunden daneben liege.

 

[Nickelback156]

Die Genauigkeit hängt immer an der Zykluszeit. Du kannst auch die Zeit des aktuellen Zyklus immer aufaddieren in jedem Zyklus.
Es kommt auch die Zeit des Profinets hinzu. Es kann sein, dass der Profinetzyklus langsamer ist als die CPU, dann stehen garnicht in jedem CPU Zyklus neue IO Daten bereit. Das Stichwort wäre hier taktsychrones Profinet, IRT. Das Programm oder besser nur ein Teil davon wird dann in einem extra OB aufgerufen welcher auf den Profinet Zyklus synchronisiert ist. Bei einer einzigen ET Station ist sicher eine PN Zykluszeit von 1ms möglich.

 

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank für die Antworten. Ich werde nichts mehr ändern. Ich verwende den Time_tck einmal und einmal den TONR, beide werden im interrupt OB (1ms) aufgerufen. Das Ergebnis ist 45 Millisekunden, ich hab 46 erwartet (Weg/Zeit Gesetz) über Excel Formeln errechnet. Es ist ok

 

[Richard P.]

... Aktuell sieht es bei meiner letzten Messung so aus, dass ich um wenige Millisekunden daneben liege...

Neben wem liegst du?

... PLC Zeit mit Hilfe der Funktion TIME_TCK()...

Runtime heißt das neue Time_Tck. Aber wem sage ich das.

 

[Cassandra]

Ich halte die Klimmzüge mit einem 1-ms-OB für fragwürdig. Wenn die Auswertung im normalen Programmzyklus erfolgt, sollte auch die Zeitmessung dort stattfinden. Die Messgenauigkeit wird dann im Wesentlichen durch die Erkennungszeit der Start- und Stop-Flanke begrenzt. Als grobe Abschätzung ergibt sich daher eine maximale Abweichung von etwa 2 × Zykluszeit, zuzüglich eventuell Eingangsfilter- und Busaktualisierungszeiten. Eine 1-ms-Zeitbasis hilft nur, wenn auch die Signalerfassung entsprechend schnell und deterministisch erfolgt.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich verwende den Time_tck einmal und einmal den TONR, beide werden im interrupt OB (1ms) aufgerufen.

Ich würde den TIME_TCK verwenden. Die S7-1500 kann das. Mit TIME_TCK kommt es nicht zu zusätzlichen Startzeit-, Additions- oder Rundungsfehlern. (Außer +/- der Zykluszeit des OB, in dem der TIME_TCK gelesen wird.)

Allerdings würde ich vermutlich ebenfalls nicht die Klimmzüge mit einem 1-ms-OB machen. Was bringt es, die Dauer eines Sensorsignals auf 1ms genau zu erfassen, wenn die SPS z.B. nur alle 15ms drauf reagiert?
Liest du in dem 1ms-OB die Eingangszustände direkt aus der Peripherie? Sind da auch dezentrale Signale (z.B. Feldbus) dabei? Bei wenigen Signalen würde ich über Prozessalarm nachdenken (das kann genauer sein, wenn man eine höher aufgelöste Zeitbasis abfragen kann), insbesondere wenn die SPS unabhängig vom OB1 schnell drauf reagieren soll.

Das Ergebnis ist 45 Millisekunden, ich hab 46 erwartet (Weg/Zeit Gesetz) über Excel Formeln errechnet.

+/-1 ist bei Digitaltechnik immer drin und kein Beinbruch.