Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 9 von 9

Thema: Fragen zum OB90 "Hintergrundbearbeitung"

  1. #1
    Registriert seit
    22.07.2007
    Beiträge
    86
    Danke
    16
    Erhielt 25 Danke für 19 Beiträge

    Standard


    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:
    cycle_d.gif
    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.

    Code:
    OB90
    ...
    <<OB1 unterbrechung möglich aber egal>>
    ...
    FCxyz
    ...
    
    <<OB1 unterbrechung möglich aber egal>>
    
    // Eintrag kopieren
      Call sfc20
        srcblk=#temp_anyQuelle
        ret_val=#temp_iReturnValue
        dstblk=#temp_anyZiel
    
    <<OB1 unterbrechung möglich und unerwünscht>>
    
    // Index Quelle löschen
      L L#0
    <<OB1 unterbrechung möglich und unerwünscht>>
      T dbd[ar1, p#0.0]
    
    <<OB1 unterbrechung möglich aber egal>>
    ...
    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)
    Zitieren Zitieren Fragen zum OB90 "Hintergrundbearbeitung"  

  2. #2
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    .

    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).
    kind regards
    SoftMachine

  3. #3
    Semo ist offline Benutzer
    Themenstarter
    Registriert seit
    22.07.2007
    Beiträge
    86
    Danke
    16
    Erhielt 25 Danke für 19 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen
    .

    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)



    Zitat Zitat von SoftMachine Beitrag anzeigen
    .
    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?

  4. #4
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    .
    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.
    kind regards
    SoftMachine

  5. #5
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    .
    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:
    Laufzeitermittlung OB1 Main Programm und OB 90
    kind regards
    SoftMachine

  6. #6
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.184
    Danke
    923
    Erhielt 3.290 Danke für 2.659 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen
    .
    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.
    Zitat Zitat von SoftMachine Beitrag anzeigen
    .
    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:
    Laufzeitermittlung OB1 Main Programm und OB 90
    Na, grade noch so die Kurve in die richtige Richtung gekriegt ...

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  7. #7
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    .
    Scherzbold

    Gruss
    kind regards
    SoftMachine

  8. #8
    Semo ist offline Benutzer
    Themenstarter
    Registriert seit
    22.07.2007
    Beiträge
    86
    Danke
    16
    Erhielt 25 Danke für 19 Beiträge

    Standard

    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.
    Geändert von Semo (08.10.2013 um 21:22 Uhr) Grund: PS

  9. #9
    Semo ist offline Benutzer
    Themenstarter
    Registriert seit
    22.07.2007
    Beiträge
    86
    Danke
    16
    Erhielt 25 Danke für 19 Beiträge

    Standard


    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

Ähnliche Themen

  1. Fragen zu "Alarm_S" Meldungen
    Von buck412 im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 17.10.2011, 14:21
  2. "Index Pulse", "Home Switch" und "Position Limit Switch"
    Von senmeis im Forum Antriebstechnik
    Antworten: 3
    Letzter Beitrag: 07.03.2011, 11:21
  3. Antworten: 6
    Letzter Beitrag: 23.02.2011, 09:16
  4. Antworten: 1
    Letzter Beitrag: 15.08.2007, 09:06

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •