Step 7 Zusammenspiel Weckalarm-OB und Ablauf(OB1)?

[Geisterkarle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich gebe zu, weil ich die noch nie benutzt habe, bin ich uninformiert, aber wie genau funktioniert denn ein Weckalarm-OB im Zusammenhang mit meinem normalen OB1 Ablauf?
Also angenommen wenn ich einen OB35 hab, der alle 100ms aufgerufen wird und ich dort einen Merker auf TRUE setze. Mein OB1 Ablauf benötigt 15ms. Was passiert nach 100ms? Der OB35 läuft und setzt das Bit. Bekommt das mein Ablauf "mittendrin" mit? Oder erst mit dem nächsten Zyklus?

Worum es prinzipiell geht:
Habe hier eine alte Anlage übernommen und deutlich erweitert. Es wurde jetzt bemerkt, dass mehrere Zeitangaben deutlich länger dauern, als angegeben. (also ich möchte 30min warten, aber 40min sind in der "Wirklichkeit" vergangen) Das alte Programm benutzt so ziemlich überall für Zeitüberwachungen eben genau mein Beispiel, also OB35 setzt ein Bit auf TRUE, das normales Programm bildet eine Flanke und das ist der Zähler "100ms sind vergangen" und über die Flanke zählen etwaige Zählvariablen hoch. Und ich vermute mit der Erweiterung ist meine Taktzeit hochgegangen - muss mir das nächste Woche mal angucken, hoffe die Fernwartung wird bald eingerichtet - und zählt jetzt irgendwie falsch...
Daher würde ich mal verstehen wollen, wie das Zusammenspiel hier ist! Gibts da ne gute Erklärung irgendwo?
Und vielleicht hat jemand ne Idee wie ich das vielleicht besser löse? Da ich keine Lust habe gefühlt 7000 Stellen, wo Zeiten "gerechnet" werden, anzupassen müsste ich diesen 100ms Taktmerker irgendwie "besser" beschalten! Ich persönlich benutze für irgendwelche Timer eigentlich die OB1 Zykluszeit, vielleicht kann ich da was basteln... "ungenau" wird es aber vielleicht trotzdem...

Für Tipps und Informationen Dankbar!
Und falls es noch relevant ist: CPU 414-3 PN/DP

grüße

 

[JSEngineering]

Moin,

der OB1 wird unterbrochen, Abarbeitung stoppt. OB35 wird geladen und abgearbeitet. Danach wird OB1 fortgesetzt, wo er unterbrochen war.
Das gleiche passiert bei allen anderen OBs auch (Fehler-OBs z.B.).
Der Zyklus von OB1 wird dadurch länger.

Sonst einfach auch mal in die Hilfe gucken, bei den OBs, da gibt es auch nette Schaubilder.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es wurde jetzt bemerkt, dass mehrere Zeitangaben deutlich länger dauern, als angegeben. (also ich möchte 30min warten, aber 40min sind in der "Wirklichkeit" vergangen) Das alte Programm benutzt so ziemlich überall für Zeitüberwachungen eben genau mein Beispiel, also OB35 setzt ein Bit auf TRUE, das normales Programm bildet eine Flanke und das ist der Zähler "100ms sind vergangen" und über die Flanke zählen etwaige Zählvariablen hoch.

Das Bit was im OB35 gesetzt wird, darf im OB1 nur ein einziges Mal gelesen und rückgesetzt werden, weil der OB1 nicht weiß, wann er vom OB35 unterbrochen wird. Wird das Bit mehrmals gelesen, dann kann es beim späteren Lesen einen anderen Zustand haben als beim früheren Lesen.

U "meinBitAusOB35"
= "Impuls_100ms" //alle 100ms für genau einen Zyklus lang true
R "meinBitAusOB35"

Alle Zeitzähler dürfen nur das Bit "Impuls_100ms" zählen, dann verzählen sie sich nicht.
(Weil das Bit nur 1 Zyklus lang true ist (solange OB1 kürzer als 100ms ist), brauchen die Zähler keine Flankenerkennung)

Harald

 

[Geisterkarle]

Moin,

der OB1 wird unterbrochen, Abarbeitung stoppt. OB35 wird geladen und abgearbeitet. Danach wird OB1 fortgesetzt, wo er unterbrochen war.
Das gleiche passiert bei allen anderen OBs auch (Fehler-OBs z.B.).
Der Zyklus von OB1 wird dadurch länger.

Sonst einfach auch mal in die Hilfe gucken, bei den OBs, da gibt es auch nette Schaubilder.

Ah, ok!
Danke! Dann klärt das das

@PN/DP:
Hm, genau so sieht der Code für das Zählen aus.

 U     "HelpFlag"
 =     "Ticker0_1s"
 R     "HelpFlag"

Wenn das eine etablierte Methode ist, dann muss es wohl an was anderes liegen bzw. an der eigentlichen Auswertung... da seh ich schon verkomplizierende Dinge bei einem Beispiel... mal schauen ob das besser oder schlechter ist! Ekeliger AWL-Code von anderen Leuten auditieren!
Danke soweit mal an euch!

grüße

 

[Geisterkarle]

Ok, bin ... "schlauer" ... Meine CPU ist tatsächlich etwas Überlastet und habe eine durchschnittliche Zykluszeit von 130ms! Da hilft der 100ms Weckalarm natürlich nicht.
Allerdings habe ich ein Problem mit denen...
Denn ich dachte ich kann mir mit einem Weckalarm von 200ms oder so behelfen ... aber irgendwie funktioniert das nicht! Zu Testzwecken hab ich mal den OB32 - 1000ms für meinen 100ms Taktmerker eingesetzt ... und in absolut jedem Zyklus meiner CPU war der Merker auf 1 gesetzt! das kann/darf doch gar nicht sein? Und bei der "lahmen" Zeit muss man ja mal ne 0 sehen, aber bekomm ich nie!
Muss man die Weckalarme irgendwie speziell aktivieren? Oder reicht es den OB einzuspielen? bzw. der OB wird ja ausgeführt, er setzt ja mein Bit. Allerdings halt nicht in der Eingestellten Zeit...
Ich frage mich wie das vor der Erweiterung war... vermutlich war da die Zykluszeit unter 100ms, aber falsche Zeitrechnung müsste trotzdem gewesen sein...
Ich glaub ich beisse in den Sauren Apfel der Zykluszeit und Hunderten Änderungen!

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

schau halt mal, was in der HW-Konfig eingestellt ist:

das mit dem Beobachten ist immer so ne Sache...

 

[JSEngineering]

Muss man die Weckalarme irgendwie speziell aktivieren? Oder reicht es den OB einzuspielen? bzw. der OB wird ja ausgeführt, er setzt ja mein Bit. Allerdings halt nicht in der Eingestellten Zeit...

Der Weckalarm wird in der Hardwarekonfiguration eingestellt. Du mußt diese also ändern und übertragen!

Wenn Du aber intern Zeitmessungen damit machst, wäre ich damit sehr vorsichtig! Irgendwo basieren dann Faktoren darauf, die Du nicht findest oder berücksichtigst... Laufzeiten sind auf einmal nicht genau genug...

Wodurch haben sich denn die Zykluszeiten so erhöht? Kann man die zeitintensiven Aufgaben ggf. innerhalb mehrer Zyklen abarbeiten? In einem Zyklus Aufgabe A, im anderen Aufgabe B?

 

[PN/DP]

Was macht denn Deine 414-3 PN/DP so, daß die Zykluszeit > 100ms ist??

Deine CPU ist vermutlich eine ältere 414-3 PN/DP? Welche Bestellnummer genau?
Eine aktuelle 414-3 PN/DP 414-3EM07 ist mehr als doppelt so schnell wie die älteren 414-3EM05 oder 414-3EM06 (und bei Siemens sogar sofort lieferbar).

Harald

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine aktuelle 414-3 PN/DP 414-3EM07 ist mehr als doppelt so schnell wie die älteren 414-3EM05 oder 414-3EM06 (und bei Siemens sogar sofort lieferbar).

Sofort lieferbar ist aber weit mehr als doppelt so schnell im Vergleich zu manchen anderen.
So ändern sich die Zeiten und die Interpretationen von "schnelle CPU".

Zurück zum eigentlichen Thema.
Ich denke, die Lösung des Rätsels hattest Du schon geliefert, Harald!
Wurde anscheinend überlesen, darum wiederhole ich es hier:

(Weil das Bit nur 1 Zyklus lang true ist (solange OB1 kürzer als 100ms ist), brauchen die Zähler keine Flankenerkennung)

 

[Geisterkarle]

Hallo alle!
Also zuerst einmal meine Entschuldigung: Bin dumm! Anderer Weckalarm hat funktioniert...

CPU ist 3EM06. Ich weiß nicht, was die Zykluszeit vor der Erweiterung war! Aber ist ca. 40-50% mehr "Inhalte" zum Altstand dazu gekommen, also nicht gerade wenig. Ich weiß, meine CPU ist verdammt voll! Musste während Inbetriebnahme hin und wieder meine Daten komprimieren, damit ich noch Bausteine einspielen konnte... das Originalprogramm war mit einem proprietären HMI verbunden (kennt wer hier Iltis?) und sagen wir mal so: 1 Digitaler Eingang verbraucht über 20 Byte in Daten! Da wird also ordentlich herumgeschoben!
Glaube aber ein Hardwareaustausch ist aktuell nicht angesehen. Möchte ich auch gar nicht erwähnen Aber gebe zu, die 130ms sind echt nicht cool!

Ansonsten, wie erwähnt, hab ich meinen dummen Fehler gefunden und ich arbeite jetzt erstmal mit 200ms Weckalarm. Muss jetzt leider tatsächlich an alle Stellen, wo der benutzt wird, weil da immer 100ms hardcodiert aufgerechnet wurden. Hab es erstmal vor Ort für die wichtigen Funktionen reingehackt, jetzt noch Fleißarbeit.
Problem also erstmal unschön gelöst!

Danke für Input!

 

[ducati]

ich arbeite jetzt erstmal mit 200ms Weckalarm.

ich hätte vermutlich den 1000ms Weckalarm genommen... für Zeiten um die 30min reicht die Genauigkeit aus, du bist offen für weitere Zykluszeiterhöhungen, es ist leichter zu ändern und nachvollziehbarer...

Ansonsten kommts natürlich drauf an, was da alles "hochgezählt" wird und wie genau das im einzelnen sein MUSS.

Gruß.

 

[Geisterkarle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hm, also im Originalprogramm wird für etwaige Signal-Verzögerungen noch der 0.5s Takt (da aus dem Weckalarm gebildet jetzt 0,6s ) genutzt. Wobei glaube die Sekunde auch nix ausgemacht hätte. Aber ja, meistens geht es um mehrminütige Überwachungen. Genauigkeit ist jetzt nicht unglaublich wichtig. Aber 30min zu 45min ist halt schon viel. Bei 32min hätte wohl niemand was bemerkt und sich daran gestört!

Es kommt Anfang nächstes Jahr noch eine kleine Erweiterung dazu, aber die war schon als Option "vorhanden" und so mindestens 90% des Codes ist schon integriert, nur die Hardware fehlt. Zykluszeit sollte also nicht wirklich nochmal hochgehen. Und prinzipiell kann man ja auch mitteilen: "Soviel und nicht weiter!" bzw. "Dann brauchen wir neue CPU!" Können ja dem Kunde nen "schönes Angebot" machen

Frohes schaffen!

 

[Onkel Dagobert]

.. jetzt noch Fleißarbeit..

Ach was! Ich würde mit der negativen Flanke des "Ticker0_1s" noch einen weiteren Zyklus hinterher schieben. Bzw, falls die Zähler im Programm alle separat mit Flankenauswertung arbeiten, dann 1 Zyklus Pause und danach einen weiteren Impuls.

.. Aber das gibt ja auch gleich wieder Probleme .

 

[ducati]

Ach was! Ich würde mit der negativen Flanke des "Ticker0_1s" noch einen weiteren Zyklus hinterher schieben. Bzw, falls die Zähler im Programm alle separat mit Flankenauswertung arbeiten, dann 1 Zyklus Pause und danach einen weiteren Impuls.

.. Aber das gibt ja auch gleich wieder Probleme .

wie soll das gehn? Die ganzen 7000 Zähler addieren im OB1 0,1sek drauf, da der OB1 aber 120ms Zykluszeit hat, ist das halt zu wenig wenn in JEDEM OB1 Zyklus aufaddiert wird.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich vermute mal, die vorhandenen Zähler arbeiten alle ohne Flankenauswertung, weil die würde bei OB35 alle 100ms nur bei OB1-Zykluszeit < 50 ms sicher funktionieren. Die Zeitzählung hat aber anscheinend bis OB1-Zykluszeit (knapp) unter 100ms funktioniert.

Bei OB35 alle 200ms wird es passieren, daß zwei aufeinanderfolgende OB1-Zyklen unterbrochen werden und "Ticker0_1s" = 1 dann 2 Zyklen lang ist und eine negative und eine positive Flanke fehlt. Flanken auswerten hilft also nicht.

Harald

 

[Heinileini]

AndererAnsatz:
Keine Flanken auswerten.
Im WeckAlarm einen globalen "WeckAlarmZähler" um 1 erhöhen.
Am Anfang des zyklischen Programms ...
- den WeckAlarmZähler in eine Variable des OB1 namens "OB1-Add" kopieren und den WeckAlarmZähler löschen,
- an diversen(?) Stellen im OB1, aber pro "TimerZähler" nur 1-mal pro OB1-Zyklus, den Inhalt von "OB1-Add" auf den jeweiligen "TimerZähler" addieren (und den TimerZähler auswerten) und nicht daran stören, wenn mal nutzloserweise "nur" eine 0 addiert wird.

 

[ducati]

AndererAnsatz:
Keine Flanken auswerten.
Im WeckAlarm einen globalen "WeckAlarmZähler" um 1 erhöhen.
Am Anfang des zyklischen Programms ...
- den WeckAlarmZähler in eine Variable des OB1 namens "OB1-Add" kopieren und den WeckAlarmZähler löschen,
- an diversen(?) Stellen im OB1, aber pro "TimerZähler" nur 1-mal pro OB1-Zyklus, den Inhalt von "OB1-Add" auf den jeweiligen "TimerZähler" addieren (und den TimerZähler auswerten) und nicht daran stören, wenn mal nutzloserweise "nur" eine 0 addiert wird.

dann muss er aber auch 7000 Zähler anpassen. Gesucht war eine Lösung, die ohne 7000 Programmänderungen funktioniert, falls ich das richtig verstanden habe.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

dann muss er aber auch 7000 Zähler anpassen. Gesucht war eine Lösung, die ohne 7000 Programmänderungen funktioniert, falls ich das richtig verstanden habe.

Ja, wenn jeder der 7000 Zähler für sich ausprogrammiert ist, dann haut das rein.
Andererseits, wenn z.Z. bei jedem Zähler ein FlankenMerker und ein "bedingtes Zählen" am werkeln ist, dann hauen auch die erzielbaren Einsparungen 7000-fach rein.
Ich hatte mir eigentlich eher vorgestellt, dass es sich bei den DIY_Timern um Instanzen eines FB handelt.
Wenn dieser FB an der Oberfläche nur um den Parameter "OB1-Add" erweitert werden muss, könnte man dies umgehen, indem man für "OB1-Add" eine globale Variable spendiert, auf die man "im Untergrund" direkt zugreift. Nicht schön, aber wenn das Argument im Raume steht, alternativ 7000 FB-Aufrufe ändern zu müssen ...
Man müsste die bisherige Umsetzung der DIY-Timer kennen.
Vermutlich wird die Forderung, dass pro DIY-Timer und pro OB1-Zyklus nur ein einziges Mal aufgerufen und der "OB1-Add" auf den DIY-TimerZähler addiert werden soll/muss/darf, mehr Aufmerksamkeit erfordern.

Jedenfalls ist in der vorgeschlagenen Version ...
- ... der OB35 "schlank" gehalten (er inkrementiert lediglich eine globale Variable um die Konstante 1, ohne HandshakeSignale bedienen zu müssen),
- ... im OB1 die InformationsÜbergabe vom OB35 zum OB1 (globale Variable kopieren) und vom OB1 zum OB35 (globale Variable löschen) sehr simpel.
Man kann alternativ leicht eine Variante realisieren, die auf das Löschen der globalen Variable durch OB1 verzichtet. Dadurch ist diese Variante logisch noch "sauberer".
Die globale Variable wird dann als EndlosZähler betrieben. Der OB1 schreibt jeweils die Differenz zwischen dem aktuellen Stand des globalen Zählers und dem Stand desselben Zählers im vorausgegangenen OB1-Zyklus nach "OB1-Add". Dazu muss sich der OB1 zusätzlich lediglich den vorherigen Stand des globalen Zählers merken.
- ... die Zählerei in den DIY-Timer-FB-Instanzen simpel. Der DIY-TimerZähler wird bei seinem einzigen Aufruf pro OB1-Zyklus und pro Instanz um die Anzahl Inkremente laut "OB1-Add" erhöht.
- ... egal, ob mehrere OB35-Aufrufe pro OB1-Aufruf stattfinden oder mehrere OB1-Aufrufe pro OB35-Aufruf.

 

[Oberchefe]

Wenn die durchschnittliche Zykluszeit 130ms beträgt wird er nicht drumrum kommen, die "gefühlt" 7000 Stellen anzufassen.

 

[PN/DP]

ich arbeite jetzt erstmal mit 200ms Weckalarm. Muss jetzt leider tatsächlich an alle Stellen, wo der benutzt wird, weil da immer 100ms hardcodiert aufgerechnet wurden.

Was für ein Pech aber auch... Anstatt den Ticker vom OB35 zu zählen und/oder beim Ticker immer fest 100 (ms) zu addieren, hätte der ursprüngliche Programmierer auch die wirkliche OB35-Aufruffrequenz (#OB35_EXC_FREQ) oder ganz ohne OB35 die OB1-Zyklusdauer (#OB1_PREV_CYCLE) addieren können. Dann müsste man gar nichts anfassen, wenn man die OB35-Aufruffrequenz auf 200ms verstellt.

Da man nun aber alle Verwendungsstellen anfassen muß, dann würde ich nicht die feste 100 durch eine 200 ersetzen, sondern durch eine globale Variable "OB35_EXC_FREQ", und im OB35 hinzufügen:

L #OB35_EXC_FREQ
T "OB35_EXC_FREQ"

Wenn der OB35 auf 100ms bleiben soll, dann würde ich von dem "komplizierten" Multitasking mit dem OB35 ganz weggehen und bei den Zeitzählern in jedem Zyklus die Dauer des letzten OB1-Durchlaufs addieren: #OB1_PREV_CYCLE auf globale Variable "OB1_PREV_CYCLE" kopieren. Oder die Dauer mit SFC64 TIME_TCK ermitteln.

Harald