TIA Wie am schnellsten ein Profinet Messwert einlesen

V

van

Level-2
Beiträge
485
Reaktionspunkte
164
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich muss den Messwert eines Profinet Sensor möglich schnell und kontinuierlich einlesen.
CPU S7-1214-G2

Wenn ich das im OB1 mache habe ich die Profinet Aktualisierungszeit von 2ms und den OB1 Zyklus von x ms.
Ist also etwas undefiniert und kann schwanken.

In den Eingangs Eigenschaften des Profinet Moduls kann ich einen Prozessalarm definieren.
Der zugeordnete OB40 hat jetzt als Startereignis den I18.0
Triggert der OB40 jetzt nur auf Veränderungen der Adresse E18.0, oder auf die Aktualisierung des gesamten Profinet Moduls E18.0 bis 24.0 ?

Und wie sieht das mit den Teilprozessabbild aus.
Muss da auch der OB40 zugeordnet werden ?


Oder würde man das mit einem 2ms Weckalarm OB lösen?




Screenshot 2026-05-13 131927.png


Screenshot 2026-05-13 132318.png


Screenshot 2026-05-13 132953.png
 

Anhänge

  • Screenshot 2026-05-13 132318.png
    Screenshot 2026-05-13 132318.png
    39,3 KB · Aufrufe: 11
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich muss die dauer der Bewegung eines Bauteils prüfen, bzw das erreichen der Endposition.

Schneller 200ms ist gut, langsamer schlecht.

Wenn ich das jetzt im OB1 mache, der Sps Zyklus zB 10ms hat und auch noch schwankt. Ist halt die Sps Abtastrate des Profinet Sensors schlecht.

Wenn ich das jetzt deterministisch alle 2ms hinbekommen, ist das halt viel genauer.

So meine Gedanken.

Nur hab ich halt noch nie mit Prozessalarm und Weckalarm OBs gearbeitet.
 
Möglichst schnell ist halt eine undefinierte zeitspanne.
Willst du das signal kontinuierlich alle 1ms auswerten? Oder reichrn 50ms?
Ist der abstand zwischen den auswertungen wichtig?
Wa gibt in der 1500er- welt einige möglichkeiten, peripheriesignale schneller/direkter zu erreichen.
In der 1200erwelt kenn ich mich zu wenig aus- aber vlt haben dir meine fragen ein bisschen einen denkschub gegeben…
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich lagere solche Sachen öfter in OB3x aus, die Zeitspanne kann ja eingestellt werden von 2/5/10/.../77/etc ms und schreibe dann direkt die Peripherie zum Beispiel bei einem Drehtisch mit Ini.
 
Es wundert mich, dass der Begriff "Profinet Synchronbetrieb" (IRT - Isochronous Real-Time) noch nicht gefallen ist. Leider habe ich das bisher noch nicht benötigt und kann daher auch nichts empfehlen oder berichten. Aber rein begriffsmäßig wäre doch das doch die erste Wahl?
 
Da gibt es mehrere Faktoren, die eine Rolle spielen.
Zum einen der Profinet Takt.
Wenn der auf 2ms läuft, werden alle 2ms die Daten über das Profinet zur Verfügung gestellt. Ob der Sensor alle 2ms neue Daten zur Abholung hat, ist eine andere Frage.
Wenn das primäre Ziel absolute Konstanz in den neuen Daten ist und Du schreibst 2ms Zykluszeit schwankend ist schlecht und alles unter 200ms Sensor Aktualisierung ist gut - dann würde ich den Weckalarm OB35 auf 20ms oder 50ms stellen. In dem Weckalarm OB muss aber auch der Sensor eingelesen werden per Peripherie-Zugriff. Das ist der einzige Fall, wo man den Peripherie-Zugriff auf S7 -1x00 braucht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bevor man nur an PROFINET-Updatezeit oder SPS-Zykluszeiten optimiert, sollte man zuerst die komplette Signalkette betrachten:
  • Welche Aktualisierungszeit hat der Sensor?
  • Geht das Signal auf einen Analog-Eingang?
  • Wenn ja: Welche Wandlungs-/Filterzeit hat die Analogkarte?
  • Welche PROFINET-Updatezeit ist projektiert?
  • Wie schnell ist der SPS-Zyklus?
Wenn diese Werte nicht bekannt sind, bringt es oft wenig, nur den SPS-Zyklus auf 2 ms zu drücken.
Die Summe der Zeiten bestimmt am Ende die tatsächliche Reaktionszeit.

Und wenn es eigentlich um das präzise Erfassen einer Position bzw. eines Bewegungsereignisses geht, gibt es meist bessere Lösungen als schnelles Polling in der SPS:
  • Latch
  • Touch Probe
  • Capture-Eingang
  • Hardware-Zeitstempel
Solche Funktionen erfassen das Ereignis hardwareseitig deutlich genauer als ein zyklisches Einlesen über PROFINET.
 
van schrieb:
Schneller 200ms ist gut, langsamer schlecht.
Zum Vergrößern anklicken....
200ms ist schon eine lange Zeit. Dies sollte eigentlich machbar sein. Ich nutze eine S7-1214c G2 für ähnliches über ProfiNet mit einem SEW-IO auf einem Motor und ohne verrenken schaffe ich da locker unter 100ms. (Ich brauch nicht mehr. Aber, da geht mehr!)

Wieso sprichst du von 2ms und dann von 200ms...? Was ist deine genaue Reaktionszeit die du benötigst?

Für 200ms brauchst du nicht asyncron abtasten. Das schafft der normale OB1 Zyklus. Je nach, wie nun deine echte Auflösung sein muss, könntest du z.B. die minimale Zykluszeit nutzen, um deine Auflösung entsprechend zu generieren. Wenn dein Zyklus so 2-3ms beträgt, streckst du auf 5ms um eine feste Zeit zu haben. Dies gleicht Variation der Zykluszeit aus. (Solange das Programm einen Durchlauf unter 5ms schafft, hat es 5ms. Wenn es in einem Zyklus 2.8ms braucht und im nächsten durch bedingte Abarbeitungen 3.4ms, wird die fehlende Zeit bis 5ms dynamisch angepasst. Das Programm hat einen definierten Zyklus, der nur im µs-Schwankt. Dies dürfte für deinen Zweck ausreichend sein. Für alles, was nicht im µs-Bereicht schwanken darf, ist die S7 mit 1ms minimaler einstellbarer Zyklus eh die falsche Hardware.)

Sind dir denn die Zeiten bekannt, die weiter oben schon mal erwähnt wurden? Wie ist die Zeit, die dein Modul benötigt um einen Wert zu wandeln? Wie oft aktualisiert der Sensor? Wenn dieser Sensor seinen Wert analog raus gibt, wie nimmt er diesen auf? Ein ADC der dann wieder als DAC die Werte abgibt? Oder ist es ein Analoger Sensor? Wie stark ist dein Netz ausgelastet? Welche Zeiten schafft es überhaupt? Fragen über Fragen!

MfG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
bitte immer auch Prüfen (und im Programm entsprechend reagieren), ob die Daten überhaupt gültig sind (keine Kommunikation, ModuleDiffBlock, Provider Status = FALSE., etc.). das gilt für alle SPSen, bin halt kein Siemens Fachmann, um da Tips geben zu können.
 
Der Hinweis mit dem direkten Peripheriezugriff im Alarm-OB war schon mal hilfreich. Dann brauch ich keine Teilprozessabbilder.
Und ob jetzt Weckalarm oder Prozessalarm werde ich mal sowieso Testen müssen.

Auf einen Analog Eingang wollte ich verzichten, da das noch einmal ein Bauteil in der Messkette ist.
Außerdem ist die kleinste einstellbare Integrationszeit 2,5ms (SM 1231 AI8)
Und ob jetzt Analogeingang oder Profinet Slave Anschaltung am Sensor macht sich preislich jetzt auch nicht mehr so viel.

Latching bzw das zwischenpuffern der Messwerte im Sensor wäre auch noch interessant, kann der aber nicht.

In der Vergangenheit hab ich etwas einfachere Zeitmessungen auch schon im OB1 gemacht, solange keiner das Ergebnis hinterfragt ist das ja ok, aber irgendwann kommen die fragen ...


Zu der Aufgabe und warum ich das etwas besser als "mach ich irgendwie im OB1" will:

Der Kunde hat ansonsten viel mit Koordinatenmesstechnik zu tun. Und da steht auch gleich DAkkS Kalibrierung im Raum, das konnten wir ihm aber ausreden. Und MFU, und etc ....
Und ob jetzt der 1ms TIME_TCK der SPS auch 1ms ist ....

Der Sensor hat einen Abtastzyklus von 0,3 bis 5ms, einstellbar.
Die von TIA berechnete Profinet Aktualisierungszeit ist bei 2ms.

Meine Zielgröße von 200ms ist eigentlich irrelevant, das könnten auch 2 Stunden sein.
Es kommt afaik auf die geforderte Toleranz an.
Eine richtige Toleranz habe ich bis jetzt noch nicht, größer 200ms = schlecht, kleiner = gut.
Aber nehmen wir einmal +-10ms an.

Die goldene Regel der Messtechnik ist eine Faustregel die besagt, dass die Unsicherheit eines Messgerätes ein Zehntel, im äußersten Fall ein Fünftel der Toleranz nicht überschreiten sollte.
Zum Vergrößern anklicken....

Die Toleranzfeldbreite wird durch 10 geteilt und ein Messmittel ausgewählt, dessen Messunsicherheit geringfügig kleiner ist als der berechnete Wert.
Zum Vergrößern anklicken....

Dann haben wir eine Toleranzfeldbreite von 20ms
geteilt durch 10 = 2ms

Somit denke ich das wenn ich die 2ms deterministisch erreiche, schonmal in einen guten Bereich bin.
Und kann dem Kunden sagen das ich einen Abtastzyklus von 2ms habe,
 
Eventuell kommst du mit einem Prozessalarm hinreichend genau hin.
Auf eine gesamte Messunsicherheit von 2 ms kommst du dadurch aber nicht automatisch.
Die einzelnen Zeiten der Messkette addieren sich bzw. müssen zumindest in der Unsicherheitsbetrachtung berücksichtigt werden.

Beispiel:
  • 2 ms Sensor-Abtastzyklus
  • 2 ms PROFINET-Aktualisierungszeit
  • Reaktionszeit/Jitter bis zum Alarm-OB
  • Genauigkeit der Zeitbasis/Zeitstempelung in der CPU
  • ggf. interne Filterung oder Signalverarbeitung im Sensor
Damit ist ein 2-ms-PROFINET-Zyklus nur ein Teil der Betrachtung.

Wenn am Ende ±10 ms als Zielgröße im Raum stehen, kann das trotzdem gut ausreichen.
Nur würde ich die erreichbare Genauigkeit nicht allein aus der PROFINET-Aktualisierungszeit oder dem SPS-Zyklus ableiten, sondern aus der kompletten Messkette.
 
Zurück
Oben