Verknüpfungsergebnis über Zeit-OB-Aufruf retten

[Joline]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

der Titel klingt vielleicht etwas komisch.
Naja, ich versuche das mal zu erklären.

Wenn man Zeit-OBs verwendet, werden die ja genau nach einer bestimmten Zeit aufgerufen und abgearbeitet. Meist wird das Programm nun aber dann gerade mitten in einer anderen Funktion sein.

Ich stelle mir vor, meine Register (z. B. AKKU 1 und AKKU 2 und VKE) am Anfang des Zeit-OB zu retten und am Ende wieder herzustellen. Gibt es dafür fertige Funktionen?

Joline

 

[Automatisierungs-Rookie]

macht das Betriebssystem das nicht schon automatisch?

Das geht für mich aus dem Handbuch "Programmieren mit Step 7" hervor, ein Zitat von Seite 71:

Die zyklische Programmbearbeitung kann durch bestimmte Startereignisse
(Alarme) unterbrochen werden. Tritt ein solches Startereignis ein, wird der gerade
bearbeitete Baustein an einer Befehlsgrenze unterbrochen und ein anderer
Organisationsbaustein abgearbeitet, der dem Startereignis zugeordnet ist. Danach
wird die Bearbeitung des zyklischen Programms an der Unterbrechungsstelle
wieder fortgesetzt.

 

[Joline]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich bin mir da eben nicht so sicher. Es wäre allerdings schon logisch, dass das das Betriebssystem macht. Sonst müßte sich ja jeder, der Zeit-OBs vewendet, selbst darum kümmern.

Und was heisst "Befehlsgrenze"?
Ist das nach JEDEM Befehl, oder nur nach bestimmten, vorher festgelegten wie bspw. Zuweisungen?

 

[Automatisierungs-Rookie]

ich bin mir da eben nicht so sicher. Es wäre allerdings schon logisch, dass das das Betriebssystem macht. Sonst müßte sich ja jeder, der Zeit-OBs vewendet, selbst darum kümmern.

Es ist auch nichts in der Dokumentation zu finden, was auf zusätzliche Arbeit hindeutet (mittlerweile müsste ich in Punkto Dokumentation alles kennen).

Und was heisst "Befehlsgrenze"?
Ist das nach JEDEM Befehl, oder nur nach bestimmten, vorher festgelegten wie bspw. Zuweisungen?

Ein Befehl ist für mich eine Anweisung, z. B. U E 1.1 Kommt während der Bearbeitung des Befehls der Interrupt, wird dieser eine Befehl zuende bearbeitet und erst dann startet der Alarm-OB.

Edit: Nun bin ich Benutzer!

 

[holland]

Na Ihr
Da brauchst Du dich nicht drum kümmern.
Befehlsgrenzen werden in jeder Programmstruktur abgewahrtet um Interrupts zu starten.Auch nicht anders bei Siemens MC7.d.h Befehlsfolgen werden bis zu Zuweisungen oder Transferoperationen abgearbeitet bevor ein Interrupt oder eine subroutine gestartet wird.

Also ist die projektierte Alarmzeit um diese Anweisungslängen die nach Eingang des Alarms bis zur Befehlsgrenze bearbeitet werden länger.

 

[mitchih]

Zuviel Werbung?
-> Hier kostenlos registrieren

Unterscheidung zwischen Befehls und Bausteingrenzen

Hallo, bin relativ unerfahren in der Weckalarmgeschichte bei S7.
Ich weiß aber aus der S5 Zeit das Prozessalarme nach möglichkeit immer an Bausteingrenzen aufgerufen werden sollten, um Probleme z.B. mit dem VKE und dem AKKu zu vermeiden. Nur wenn es absolut unumgänglich war wurden Bausteine an Befehlsgrenzen unterbrochen.

An Befehlsgrenzen das heißt: Der Baustein kann nach jedem Befehl (Zeile) Unterbrochen werden.

Weiß jemand ob man da was einstellen kann bzgl. Befehls- Bausteingrenzen?? Bei der 135/155U war das im DX0

 

[Unregistrierter gast]

Na Ihr
Da brauchst Du dich nicht drum kümmern.

Also ist die projektierte Alarmzeit um diese Anweisungslängen die nach Eingang des Alarms bis zur Befehlsgrenze bearbeitet werden länger.

Das ist vollkommen richtig.

Befehlsgrenzen werden in jeder Programmstruktur abgewahrtet um Interrupts zu starten.Auch nicht anders bei Siemens MC7.d.h Befehlsfolgen werden bis zu Zuweisungen oder Transferoperationen abgearbeitet bevor ein Interrupt oder eine subroutine gestartet wird.
[/FONT][/B]

Das wiederrum ist, mit verlaub, völliger Blödsinn.

An Baustein- oder Befehlsgrenzen, abhängig von der CPU, nicht einstellbar ist richtig.

Gewartet bis eine "Zuweisungen oder Transferoperationen abgearbeitet" ist, wie soll das gehen ?

 

[Automatisierungs-Rookie]

Ich habe mal geschaut, was S7-Steuerungen so machen:

S7-300:

Reproduzierbarkeit
Für die CPUs dieses Handbuches, außer der CPU 319, gelten folgende Zeiten:
• Verzögerungsalarm: +/- 200 μs
• Weckalarm: +/- 200 μs
Für die CPU 319 gelten folgende Zeiten:
• Verzögerungsalarm: +/- 140 μs
• Weckalarm: +/- 88 μs
Diese Zeiten gelten nur, wenn der Alarm zu diesem Zeitpunkt auch ausgeführt werden kann
und nicht z. B. durch höherpriore Alarme oder noch nicht ausgeführte gleichpriore Alarme
verzögert wird.

Bei S7-400-CPUs liegt die Reproduzierbarkeit für Verzögerungsalarme in einem ähnlichen Bereich, bei den Weckalarmen sind es +/- 20 - 35 µs.

Dies deutet darauf hin, dass es sich nur um die Befehlsgrenze handeln kann, einen Baustein kann man recht einfach mit Code füllen, der deutlich länger in der Ausführung dauert.

Interessant ist noch, dass die Gleitpunktarithmetik (SQR, SQRT, LN, EXP, trigonometrische Funktionen) durch Alarme unterbrechbar sind, sonst hätte man z. B. auf der CPU 312 1,762 ms zusätzliche Verzögerung wenn noch die ganze Acos-Operation ausgeführt werden muss.

Was ich mich noch frage ist welchen Sinn der OB-Aufruf am BE macht? Würde dies bei einer CPU 312 gehen, die mit einem komplexen Gleitpunktarithmetik-Baustein gequält wird (sagen wir mal 20 ms Ausführungszeit) würde diese bedeuten, dass der 100 ms-Weckalarm zwischen 100 ms und 120 ms liegen kann?

 

[Longbow]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was ich mich noch frage ist welchen Sinn der OB-Aufruf am BE macht? Würde dies bei einer CPU 312 gehen, die mit einem komplexen Gleitpunktarithmetik-Baustein gequält wird (sagen wir mal 20 ms Ausführungszeit) würde diese bedeuten, dass der 100 ms-Weckalarm zwischen 100 ms und 120 ms liegen kann?

Hallo

Weckalarme können bei Bedarf (je nach Last der CPU) auswandern (Jittern), rasten aber danach wieder ein.
z.B. Bei einem 100ms Weckalarm könnte es zwischen zwei Alarmen schon mal 120ms Pause geben aber der nächste würde dann nach 80ms kommen (wenn er nicht aufgehalten wird).

Ansonsten sollte man bei kritischen Anwendungen lieber mal selber den Jitter messen, die Handbücher von Siemens waren früher zwar sehr gut was das Timing angeht, aber es gibt in diesem Feld so viele Kombination dass es extrem schwer ist den korrekten Worst-Case Jitter für eine spezielle Applikation im voraus nur mit dem Handbuch zu berechen!! (vor allem wenn man sich im µs-Bereich bewegt)

Also Handbuch weg und ran an das Scope!

Gruß