Profinet IRT - Messwerte mit Zeitstempel im µs-Bereich versehen

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo in die Runde,

ich arbeite gerade an einer mit Profinet-IRT synchronisierten Anwendung, in der 2 Encoder synchron über Profinet-IRT im Raster von 1 ms von einer S7-1500 ausgelesen werden. Das System läuft grundsätzlich, ich kriege die Werte herein und kann das im Trace sauber nachvollziehen.
Zur Weiterverarbeitung werden die Encoderwerte (zwischen 5 und 10) aufgepuffert und an einen anderen Profinet-Teilnehmer (der kein IRT beherrscht) weitergegeben, wobei jeder Encoder-Wert zuvor beim Einlesen mit einem Zeitstempel versehen wird, um in der Weiterverarbeitung einen sauberen Verlauf nachbilden zu können.

Der Knackpunkt ist nun das Erzeugen des Zeitstempels. Ziel ist es, den Zeitstempel zu erzeugen, dass er den Abtastzeitpunkt abbildet.

Wir haben bei uns im Team 4 Ansätze verfolgt, sind aber mit keinem davon weitergekommen

1. TIME_TCK -> liefert einen Zeitstempel im ms-Bereich, ist also unbrauchbar
2. Systemzeit mit Datentyp LDT --> hat den Nachteil, dass beim Setzen der Systemzeit sprünge auftreten
3. TON mit LTIME, Auslesen des Ausgangs ET --> bringt zwar Zeitwerte mit im ns-Auflösung, die unteren Stelle sind aber weitgehend leer, es werden keine Werte < 1 ms dargestellt
4. RUNTIME-Anweisung im SynchronousCycle-OB, Auswertung der MEM-Variable -> liefert zwar Werte im µs-Bereich, allerdings lässt sich schnell feststellen, dass hier der Zeitpuntk zwischen 2 Aufrufen um +/- 150µs variiert - es bildet also in keinster Weise den Abtasktzeitpunkt ab

Die letzte Variante ließe es zwar zu, mit µs-Stempln zu arbeiten, sie eignet sich aber nicht zum Abbilden des Abtastzeitpunktes.

Kennt hier jemand Möglichkeiten? Die Zeitstempelung oder -synchronisation ist für die Anwendung essentiell.

Dazu ein Link:
https://support.industry.siemens.com/cs/de/de/view/49948856
Seite 211, Bild 5-67.
Ich möchte gerne im Block "Applikation" auf den Zeitpunkt (1) zurückrechnen. Prinzipiell sollte dies über Tv gehen, allerdings variiert der Zeitpunkt (4) je nach Systemlast. Ich benötige den Synchronisationszeitpunkt (also den Übergang Ti zu T_DC).


Jemand eine Idee?

 

[zako]

... wahrscheinlich habe ich jetzt das Problem nicht begriffen
Wenn Dein MCServo alle 1ms aufgerufen wird, dann kann man doch zum Zeitpunkt t=0ms den Positionswert s0 übertragen, dann s1 /1ms, dann s2/2ms usw.
Bei Taktsynchronität ist die Erwartungshaltung dass hier der Jitter zwischen den einzelnen Abtastungen <1 microsec ist.
Wenn Du es noch schneller als 1ms Abtastung brauchst dann eben schneller Abtasten, je nach Rechenperformance. Wenn der Geber an einen SINAMICS S120 hängen würde, könnte da was noch mit einer TEC Extension gehen (das müsstest Du mal bei SIEMENS Rückfragen - aber darum geht es jetzt hier nicht ?)

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

... wahrscheinlich habe ich jetzt das Problem nicht begriffen
Wenn Dein MCServo alle 1ms aufgerufen wird, dann kann man doch zum Zeitpunkt t=0ms den Positionswert s0 übertragen, dann s1 /1ms, dann s2/2ms usw.
Bei Taktsynchronität ist die Erwartungshaltung dass hier der Jitter zwischen den einzelnen Abtastungen <1 microsec ist.
Wenn Du es noch schneller als 1ms Abtastung brauchst dann eben schneller Abtasten, je nach Rechenperformance. Wenn der Geber an einen SINAMICS S120 hängen würde, könnte da was noch mit einer TEC Extension gehen (das müsstest Du mal bei SIEMENS Rückfragen - aber darum geht es jetzt hier nicht ?)

Es geht weder um Sinamics noch um Technologiefunktionen, sondern um synchronisierte Messungen mittels Profinet-IRT-Gebern.

 

[PN/DP]

Ich möchte gerne im Block "Applikation" auf den Zeitpunkt (1) zurückrechnen. Prinzipiell sollte dies über Tv gehen, allerdings variiert der Zeitpunkt (4) je nach Systemlast. Ich benötige den Synchronisationszeitpunkt (also den Übergang Ti zu T_DC).

Ist das Ti nicht konstant bzw. eine fest projektierte Zeit? Kann man die nicht einfach konstant zurückrechnen?

Will Dein anderer Profinet-Teilnehmer zwischen den Encoderwerten interpolieren, oder reicht da nicht auch, wenn er die zusammengehörigen Werte identifizieren kann?


Vorsicht bei der Verwendung von RUNTIME: das ist zur Zeit noch so schlecht implementiert bzw. dokumentiert, daß man die immer wieder auftretenden Überläufe nicht herausrechnen kann, und evtl. funktioniert RUNTIME in einigen CPU-Firmwareversionen fehlerhaft.

Harald

 

[maxder2te]

Ist das Ti nicht konstant bzw. eine fest projektierte Zeit? Kann man die nicht einfach konstant zurückrechnen?

Das sollte im ns-Bereich konstant sein, sonst wird ja das ganze System ad absurdum geführt.

Was wir aber definitiv gemessen haben ist, dass der Zeitpunkt (4) nicht exakt der in den Systemeinstellungen vorgenommenen Verzögerungszeit entspricht, sondern durch irgendwelche höherprioren Prozesse um bis zu 150µs nach hinten geschoben wird - was für eine rein in der S7-CPU synchron laufende Anwendung ja egal wäre.

Will Dein anderer Profinet-Teilnehmer zwischen den Encoderwerten interpolieren, oder reicht da nicht auch, wenn er die zusammengehörigen Werte identifizieren kann?

Im Endeffekt wird der andere Teilnehmer interpolieren, und dazu muss das "Alter" der Messwerte bekannt sein.

Der aktuelle Ansatz lautet nun, einfach die Anzahl der Synchronous_Cycle-Zyklen mitzuzählen und diese als "Zeitstempel" zu nutzen. Man muss halt die "verworfenen" Zyklen mit in die Rechnung aufnehmen, aber die Info bekommt man ja über die OB Startinformation raus.

Vorsicht bei der Verwendung von RUNTIME: das ist zur Zeit noch so schlecht implementiert bzw. dokumentiert, daß man die immer wieder auftretenden Überläufe nicht herausrechnen kann, und evtl. funktioniert RUNTIME in einigen CPU-Firmwareversionen fehlerhaft.

Danke für den Hinweis.
Prinzipiell hat das mit RUNTIME nicht so schlecht ausgesehen, sogar mit Firmware 1.8. Hochgerechnet kann der LREAL-Timer durchgehende µs-Werte über einige Jahre liefern, und wir gehen aktuell davon aus, dass zumindest einmal jährlich ausgeschaltet wird. Von RUNTIME wird ja nur der Zwischenspeicher MEM genutzt - interessant wäre wie die Anweisung diesen Wert generiert - und ob man an den zugrundeliegenden Rohwert anderweitig herankommen kann.