Step 7 Fragen zum OB90 "Hintergrundbearbeitung"

[Semo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nabend,

derzeit spiele ich mit dem Gedanken, mit einigen Funktionen in den in den Hintergrund-OB zu wechseln.

Derzeit setzen wir den OB90 nicht ein und haben auch meistenes keine Mindestzykluszeit gesetzt.



1. Abarbeitungsreiehenfolge

Soweit ich weiß läuft der normale Zyklus schon seit etlichen Jahren wie folgt:

• Aktualisierung PAA - Aktualisierung PAE - Bearbeitung OB1

. . . und nicht wie früher (irgendwann vor 2000):

• Aktualisierung PAE - Bearbeitung OB1 - Aktualisierung PAA

Wenn ich jetzt davon Ausgehe, dass die Beschreibungen zum OB90 (Siemens Systemhandbuch zur S7-400 und Bücher von Hans Berger) richtig sind heißt das, dass das Prozessabbild der Ausgänge erst am Ende der Mindestzykluszeit, bzw. nach der Bearbeitung des OB90 stattfinden würde. Das würde ich eher unschön finden...

Dem entgegen steht folgende Grafik:

Welche ich in diesem FAQ fand.


Was ist jetzt wohl richtig? Kennt sich jemand mit der Materie aus?



2. Abbruch des OB90 verhindern/hinauszögern

Einige der Funktionen die ich verlagern will, sollten bis zu einem bestimmten Punkt bearbeitet werden bevor der OB1 wieder anläuft.

Beispiel Datenbankoptimierung:
zur Optimierung unserer internen Datenbanken werden Einträge in dieser verschoben bzw. umkopiert.
Wenn ich alles richtig verstanden habe wird zumindest ein gerade laufender SCF20 nicht unterbrochen, das ist schon mal viel wert...

Allerdings sehe ich derzeit keine Möglichkeit zu verhindern, das genau zwischen dem Kopieren und "Löschen" des alten Eintrags der OB1 wieder startet. Was im Zweifel dazu führen würde, das Einträge doppelt vorhanden sind.

OB90
...
[I]<<OB1 unterbrechung möglich aber egal>>
[/I]...
FCxyz
...

[I]<<OB1 unterbrechung möglich aber egal>>
[/I]
// Eintrag kopieren
  Call sfc20
    srcblk=#temp_anyQuelle
    ret_val=#temp_iReturnValue
    dstblk=#temp_anyZiel

[I]<<OB1 unterbrechung möglich und unerwünscht>>
[/I]
// Index Quelle löschen
  L L#0
[I]<<OB1 unterbrechung möglich und unerwünscht>>
[/I]  T dbd[ar1, p#0.0]

[I]<<OB1 unterbrechung möglich aber egal>>
[/I]...

Die einzige Möglichkeit die mir einfällt um diesen Sonderfall nicht weiter beachten zu müssen wäre vor dem Kopieren eine Art "DB-Daten-inkonsistent" zu setzen und dieses nach dem Löschen wieder zurückzusetzen. Heißt allerdings ich kann einen OB1 Zyklus lang nicht an die DB und im Worstcaste im nächsten schon wieder nicht... usw. usf.


Hat jemand ne Lösung für diese Problematik oder wenigstens eine Idee?


Danke schon mal!



MfG Semo

PS: Werde wohl erst wieder Morgen Abend im Forum sein, also nicht wundern ^^ (Unterwegs)

 

[SoftMachine]

.

zu 1.

Deine Grafik gilt für CPU´s bis 10/1998, danach gilt folgendes
wie hier im HANDBUCH beschrieben.

zu 2.

Im OB 90 aufgerufene SFB´s/SFC´s werden komplett bearbeitet,
für deine weiteren Bearbeitungen musst du leider selbst für
die Datenkonsistenz sorgen. (Evtl. die Mindestzykluszeit erhöhen).

 

[Semo]

Zuviel Werbung?
-> Hier kostenlos registrieren

.

zu 1.

Deine Grafik gilt für CPU´s bis 10/1998, danach gilt folgendes
wie hier im HANDBUCH beschrieben.

Hab mir irgendwie schon gedacht, dass der Berger recht hat, allerdings bestätigt dies mal wieder meine Theorie zu der Qualität mancher Aussagen von Siemens (Man beachte das Datum des FAQ zu der Grafik)

.
zu 2.

Im OB 90 aufgerufene SFB´s/SFC´s werden komplett bearbeitet,
für deine weiteren Bearbeitungen musst du leider selbst für
die Datenkonsistenz sorgen. (Evtl. die Mindestzykluszeit erhöhen).

Hm... die Zykluszeit zu erhöhen, würde mir nicht wirklich was bringen, da die Prozesse welche ich eben im OB90 bearbeiten würde, permanent durchlaufen würden und immer zu tun hätten, aber nicht Zeitkritisch sind.

Ob es etwas bringen könnte regelmäßig die Restzeit der Mindestzykluszeit zu ermitteln (SFC1 oder SFC64) und in der letzten Milisekunde keine Bearbeitung mehr zu starten?!
Da wäre dann noch die Frage der Genauigkeit...

Jemand noch andere Ideen / Vorschläge?

 

[SoftMachine]

.
Bevor du jetzt die SFC "Read_Clk" oder die SFC "Time_Tck"
auch noch bemühen willst, da steht im OB1 bereits die letzte
aktuelle Zykluszeit in den TEMP-Variablen bereit.

Weiter denke ich mal, das du das Kopieren mit der SFC20
nicht unbedingt in den OB90 legen solltest, sondern das
an anderer Stelle durchführst. Das Kopieren kannst du
sperren, solange die Anweisungen im OB90 nicht voll-
ständig abgearbeitet sind.

Mit dem erfolgtem Kopieren kannst du dir dann ein Merkmal
setzen, das du dann im OB90 benutzt, um dort alle weiteren
Operationen durchzuführen.

Ist das Merkmal nicht gesetzt, dann keine Bearbeitung im
OB90 --> CPU wartet trotzdem bis zur Mindeszykluszeit.

Ist das Merkmal gesetzt, wird OB 90 bearbeitet.

Wird der OB90 von anderen OB´s unter- oder bei Erreichen
der Mindestzykluszeit abgebrochen, wird er an der Unter-
brechungsstelle beim nächsten Aufruf fortgesetzt, d.h. du
erzeugst keine doppelten oder inkonsistente Daten.

Zum Ende des OB90 erzeugst du ein weiteres Merkmal, um das
Kopieren mit der SFC20 wieder freizugeben.

 

[SoftMachine]

.
Falls du dennoch die verbleibende Restzeit für den OB 90
ermitteln willst, dann gibt es da schon kurz und knapp was
hier im Forum:
https://www.sps-forum.de/simatic/21678-laufzeitermittlung-ob1-main-programm-und-ob-90-a.html

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

.
Bevor du jetzt die SFC "Read_Clk" oder die SFC "Time_Tck"
auch noch bemühen willst, da steht im OB1 bereits die letzte
aktuelle Zykluszeit in den TEMP-Variablen bereit.

.
Falls du dennoch die verbleibende Restzeit für den OB 90
ermitteln willst, dann gibt es da schon kurz und knapp was
hier im Forum:
https://www.sps-forum.de/simatic/21678-laufzeitermittlung-ob1-main-programm-und-ob-90-a.html

Na, grade noch so die Kurve in die richtige Richtung gekriegt ...

Harald

 

[SoftMachine]

.
Scherzbold

Gruss

 

[Semo]

Danke für die Vorschläge Softmachine aber irgendwie reden wir aneinander vorbei.

Was vermutlich daran liegt, dass ich nicht ausgeführt habe, warum ich überhaupt irgendetwas in den OB90 verlagern will.

Also erstmal geht es um Fördertechnik und zwar viel davon und relativ schnell.
Nun haben wir diesmal ein paar mehr Prozesse drinn, welche nicht jeden Zyklus bearbeitet werden, im Worstcase aber alle in den selben Zyklus fallen.
Einige davon lassen sich zwar verteilen bzw. Zurückstellen, andere müssen allerdings Ereignisorientiert sofort bearbeitet werden.
(z.B. Wegeverfolgungen, Taktsynchronalarme, Regelungen und leider auch einige der Datenbankzugriffe)

Fallen nun viele der Ereignisse zusammen oder auch nicht schwankt die Zykluszeit eben mal mehr mal weniger, was im schlimmsten Fall dazu führen würde, das z.B. die Auflösung der Wegeverfolgung herabgesetzt wird.)
Eigendlich nichts womit wir grundsätzlich nicht Leben können, aber man weiß ja nie wo es zukünftig noch hingeht.

Also suche ich im Grunde aktuell nach Wegen, die Zykluszeit zu stabilisieren ohne sie gleichzeitig zu sehr zu erhöhen.

1. Schritt Mindeszykluszeit und verlagern von allen Kommunikationsprozessen die nicht in Echtzeit laufen müssen in WeckAlarm-OBs
   Durch das zusätzliche Staffeln der Verbindungsbearbeitung hab ich sogar eine wesentlich größere Glättung erreicht als erwartet
   (abgeschlossen)
2. Schritt Optimierung der Datenbankzugriffe, durch Optimierung der Datenbank
   Die Daten in 10 unterschiedlichen DBs zu lagern um den Zugriff auf die Daten zu beschleunigen war schonmal das naheliegenste und hat wie erwartet gut funktioniert. Weitere Ideen sind zwar da, erfordern allerdings größere Änderungen an unserer Struktur und sind vorerst nach hinten gestellt. (aufgeschoben)
3. Schritt Optimierung der Datenbankzugriffe, durch Optimierung der Daten selbst

• Warum wir als Index die PackID als AoC benutzTEN und nicht als DInt konnte mir Niemand beantworten, nun hats sich halt geändert (1 Vergleich ist nunmal schneller als 2-6... pro Datensatz)
• Als nächstes möchte ich die zumindest die Lücken füllen (bzw. die Datenbank reorganisieren) um nicht alle Leerzeilen in der DB auch prüfen zu müssen. Dies soll dann unter anderem im OB90 stattfinden, also wenn ZEIT über ist, die genutzt werden kann.
• Schritt Wenn dies soweit klappt (also die Bearbeitung im OB90) ,würde ich sogar noch versuchen einen Schritt weiterzugehen und die Daten sortieren, allerdings halte ich dies nicht für Realistisch, da der Sortieralgorythmus + das umkopieren vermutlich länger brauchen würde, als der großteil der Daten überhaupt noch da ist.
  [*4. Schritt ??? (Mir fällt bestimmt noch was ein und falls nicht, gibs ja noch diese ganz offensichtlich unterschätze, verkannte, immer hilfsbereite Spezies der "Anonymen Forenbesucher" )

PS: Danke Ralle, ich hab das gleiche gedacht
Die letzte Zykluszeit (OB1) wird so ziemlich in jeder meiner Berechnungen (Zeitüberwachungen, Weg, Impulsverarbeitung) benutzt, welche sich auf Ereignisse aus dem letzten Zyklus stützt.
Aber hier hilft mir wohl nur das Auslesen der Uhrzeit oder eben der Timetick (mit welchem ich noch nicht gearbeitet habe)
Ich könnte mir halt vorstellen, dass der Vergleich über den Timetick weniger Zeit als das Auslesen der Uhrzeit beansprucht, da ich ne 400er CPU habe, sollte aufgrund der Auflösung das selbe Ergenis bei rum kommen, wird sich zeigen...

Sobald ich hierzu was testen konnte berichte ich.

 

[Semo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Tja... Erstens kommt es anders... und Zweitens als man denkt.


Erstmal sei gesagt, dass die Idee hinter der Nutzung des OB90, nicht gänzlich falsch war und alle bisherigen Tests zeigten, dass alles funktioniert wie erwartet.
Im Grunde läuft nach jedem Abgeschlossenen Teilschritt im OB90 eine Prüfung auf Restzeit per TME_TCK(SFC64).
Unterschreitet die Restzeit ein bestimmtes Minimum wird die weitere Bearbeitung eingestellt, um die Datenkonsistenz zu gewährleisten.

Nun benötigen wir aber im aktuellen Projekt sehr viele Prozessalarme/Weckalarme/Synchronalarme, was im Endeffekt heißt, dass für den Fall der Fälle, wo alle diese OBs kurz vor dem erreichen der Mindestzykluszeit ablaufen, die maximale Restzeit für den OB90 so hoch eingestellt werden müsste, das quasi so gut wie keine Bearbeitung statt findet, wenn denn die Mindestzykluszeit nicht noch weiter erhöht werden würde.

Da die in Post#8 erwähnten Maßnahmen besser gegriffen als gedacht und wir die restlichen Probleme bzgl. der Zyklusschawankungen fast gänzlich ausmerzen konnten, wurde also sowohl auf eine Mindestzykluszeit, als auch auf den OB90 verzichtet.

Wir haben die Erkenntnisse zwar für spätere Aufgaben dokumentiert, aber ich glaube nicht das eine mit solchen Anforderungen alsbald zu uns findet.

Gruß Semo