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.

 

[da.kapo]

Ich verwende den RUNTIME Befehl der S7-1500 CPU um Laufzeiten im SPS Programm zu vermessen. Der ist sehr genau und auch sehr einfach anzuwenden. Beim Ersten Aufruf wird die Startzeit gemerkt und beim zweiten Aufruf die Differenz berechnet, die dann die Laufzeit wiedergibt. Das Ergebnis wird in Sekunden (LREAL) ausgegeben.
Aber wie hier schon mehrfach geschrieben, es wird nicht nur dein Code sondern die Programmausführung, Unterbrechungen (z.B. durch höher priore OB's), Kommunikation und die Systemlast der CPU mit gemessen. Also der Zyklus. Wichtig ist auch das Online Beobachten die Laufzeit massiv verlängert. Also immer auf Prio15 oder höher vermessen. Dann pfuscht zumindest die Kommunikation und OB's die auf gleicher oder niedriger Prio laufen nicht in die Messung rein.

 

[SvenJohnes]

Darf man fragen, was mit der Signaldauer angestellt wird? Ich lese immer wieder, wie Programmierer hier sich Gedanken um die Zykluszeit und Messgenauigkeit der SPS machen. Oftmals weiß man aber gar nicht, was sie überhaupt machen wollen bzw. erreichen wollen.

Wir hatten bei uns einen Programmierer vom Hersteller für eine Teilanlage unserer Fülllinie. Der hat sich fast ein Bein ausgerissen um einen Auspusher für unsere Produkte zu programmieren. Da die Bandgeschwindigkeit variiert, versuchte er die Zeit zu messen, die ein Produkt durch eine LS benötigte. (Um dessen Geschwindigkeit zu ermitteln) Er hat wilde Berechnungen angestellt, die Produktlänge musste eingegeben werden, die Zykluszeit musste passen... Und und und ... Nach einer Woche hat er aufgegeben und wollte das vertagen und in der Firma bei sich weiter probieren. Unsere Firma wollte aber nicht so lange warten. Daher, wurde ich beauftragt den Pusher in Betrieb zu nehmen. Ich habe das dann mit einem Schieberegister gelöst, der die Produktposition durchreicht. Das geht sauber selbst bei über 1000 Produkten/Minute oder variabler Bandgeschwindigkeit. Ohne Zeitmessungen. Selbst bei Höchstgeschwindigkeit bleiben locker um 50ms zum Verarbeiten der Sensorik. (Leider ist das Magnetventil etwas träge, das bei Hochgeschwindigkeit immer das nachfolgende Produkt mit raus fliegt. Das Ventil schließt nicht schnell genug.)

Daher interssiert mich immer zumindest schemenhaft, was man mit der Methode vorhat. Gibt ja immer wieder Situationen, wo man sich auf was verrennt und andere Möglichkeiten nicht mehr betrachtet.

 

[Martin2XK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist etwas kompliziert, aber ich bin zum Ziel gekommen. Schritt 1 war ein Weg Zeit Gesetz über eine physikalische Formel zu erstellen. Die Geschwindigkeiten der Bänder werden über unsere Antriebstechnik sehr genau bestimmt. Ich wollte auf dieser Basis den Weg errechnen, also zurück rechnen. Und das Ergebnis stimmte. Aber was ich damit mache ist schwierig zu erklären. Schritt 2 ist den Weg als Vergleichswert zu nehmen, um einen bestehenden Ansteuervorgang zeitlich genauer durchzuführen. Für diese Anwendung ist diese Vorgehensweise sehr gut geeignet. Berechnungen dazu gab es vorher schon, jetzt bin ich vielleicht 1% genauer. Muss natürlich nicht unbedingt sein, aber ich wollte es wissen was bei den Rechnungen heraus kommt.