Step 7 Simatic S7 Timer in (Hardware-) Interrupt

Hallo zusammen,

ich möchte in einem Hardware Interrupt einen Timer laufen lassen.

Laut Zyklusablauf einer SPS würde man ja bei Flankendetektion ins

z.B. OB40 wechseln
dort alles abarbeiten
zurück ins OB1

Ich konnte leider nichts finden im Internet, aber nach meinen ganzen Versuchen, vermute ich, dass wenn man einen IEC-Timer (TON) nimmt, dieser
bei jedem neuen Zyklus aktualisiert wird oder hardwaretechnisch parallel läuft. Da aber der OB40 nach einem Zyklus wieder deaktiviert ist, ist der Timer im OB40
unsinnig

Jetzt habe ich verschiedene Sachen ausprobiert. Unter anderem habe ich die Idee verfolgt, ein Bit im OB40 zu setzen, welcher im OB1 dann abgefragt wird und ein entsprechenden FB startet.
Hat aber leider auch nicht funktioniert, da es da an der Rücksetzbedingung des Bits Schwierigkeiten gab.

Habe ich etwas übersehen? Gibt es noch eine Einstellung, die ich machen muss? Oder vllt. ist dies ein allgemeines Problem mit einem entsprechenden Lösungspattern?

Mein Ziel ist es per Flanke (Flanke => vermutlich Fehler) und einer entsprechenden Entprellzeit (oben genannter Timer) verschiedene Aktionen (Einschaltsperre, Fehlermeldung,...) durchzuführen.

Einfachste Idee wäre alle min. 40 Eingänge bei jedem Zyklus abzufragen, also ohne Flankendetektion, sondern einfach if-else. Ist derzeit auch so realisiert und funktioniert auch.

"Never touch a running system" ist zwar schön, ich würde aber trotzdem den Gedanken noch etwas weiterverfolgen, dass über ein Interrupt zu lösen.

Beste Grüße,
DrTurkelten

Was soll an den Rücksetzbedingungen nicht funktionieren?
Du kannst natürlich im OB40 einen Merker setzen. Mit diesem Merker startest du im Normalzyklus eine Zeit, ist diese Zeit abgelaufen, dann führst du eine Aktion aus (z.Bsp. Fehlermerker setzen) und setzt den Merker, der im OB40 gesetzt wurde zurück.

@TE:
ich bin mir nicht sicher, ob der Weg, den du da verfolgen willst so überhaupt sinnvoll ist.
Vielleicht schreibst du mal etwas mehr zu dem, was du machen möchtest. Es gibt meißtens eine Lösung - Vorschläge kann man aber besser machen wenn man die Problematik kennt ...

Gruß
Larry

DrTurkelten schrieb:

Mein Ziel ist es per Flanke (Flanke => vermutlich Fehler) und einer entsprechenden Entprellzeit (oben genannter Timer) verschiedene Aktionen (Einschaltsperre, Fehlermeldung,...) durchzuführen.

Einfachste Idee wäre alle min. 40 Eingänge bei jedem Zyklus abzufragen, also ohne Flankendetektion, sondern einfach if-else. Ist derzeit auch so realisiert und funktioniert auch.

Zum Vergrößern anklicken....

Ich weiß jetzt auch nicht so wirklich, was Dir der Hardwareinterrupt bringen soll, wenn die Abarbeitung der ausgelösten Befehle zum Einen timerverzögert und zum Anderen dann eh' vom OB1-Programm durchgeführt wird.
Das Einzige, was Du Dir da sparst, ist die Flankendetektion und die macht den Kohl nun wirklich nicht fett. Schon gar nicht, wenn man mehrere Bits in einem Abwasch kontrolliert.

.

@TE

Prozessalarme werden im allgemeinen eingesetzt, um schneller auf ein Ereignis zu reagieren als es im normalen Programmzyklus
möglich ist. Auch kann es sein, dass das Ereignis nicht lange genug ansteht, um es im laufenden Zyklus zu erkennen und darauf
zu reagieren.

Trotzdem willst du das Interupt-Signal möglichst schnell erkennen, aber dann doch wieder verzögern ?
Ich denke, dein Ansatz ist falsch.

Darüber hinaus benötigst du alarmfähige Baugruppen in der Hardware, wirst also an deiner Anlage etwas mehr als
nur ein paar Code-Zeilen ändern müssen.

Schönen Guten Morgen,

erstmal danke für die Antworten. Ihr habt natürlich recht, dass ich trotz Prozessalarm verzögert auf die Flanke
reagieren würde. Ich möchte mir eigentlich nur ersparen, dass ich in jedem Zyklus 40 und mehr Fehler abfrage,
bzw. noch viel mehr Bedingungen habe zur Fehlerbehandlung. Deshalb kam mir die Idee, die Fehlerbehandlung nur
dann zu starten, wenn auch eine Flanke und somit ein möglicher Fehler anliegt.

Vllt spare ich nur 2ms aber ich möchte es trotzdem gerne ausprobieren.

Schönen Gruß,
DrTurkelten

Hallo
Ich weiß jetzt nicht welche CPU Du verwendest
aber die erhofften 2ms erscheinen mir bei 40 Meldungen fraglich.

Wenn Du bei einer aktuellen 315er 400 Meldungen aus dem zyklischen Programm rausnimmst,
sparst Du vielleicht 1ms

(Ist aber nur eine Schätzung von mir, nicht getestet)

DrTurkelten schrieb:

Vllt spare ich nur 2ms aber ich möchte es trotzdem gerne ausprobieren.

Zum Vergrößern anklicken....

Es ist fraglich dass du mit dem Wegfall dieser 40 Meldungen wirklich 2ms gewinnst. Da müsstest du pro Abfrage schon sehr komplexe Sachen machen, sonst reden wir hier von Microsekunden.

Außerdem schlagen diese Ersparnisse unter Umständen in den blödesten Momenten zu. Und wenn du viele solche Zeitsparenden Interrupte hast summieren die sich vielleicht genau hintereinander und werfen dich in die Zykluszeitüberschreitung und STOP.

Eigentlich also die gleiche Gefahr die man auch hat wenn man komplette Programmteile im Normalfall überspringt und nur bei Ereignissen abarbeitet. Kann zu schwer diagnostizierenden Stopübergängen führen.

mfG René

ich nehme an, die 40 Meldungen sind hintereinander angeordnet?
also 5x8bit? 48 Meldungen ist besser! 3x16bit ...

Zeiten für 315

DrTurkelten schrieb:

aber ich möchte es trotzdem gerne ausprobieren.

Zum Vergrößern anklicken....

Ja naja, mal abundzu neue Dinge auszuprobieren ist natürlich nicht verkehrt. Aber wie Dir hier von mehreren erklärt wurde, macht das in Deinem Fall wenig Sinn. Ich denke, deshalb hast Du uns ja gefragt. Also nehm auch die Ratschläge an

Und denke auch an die Instandhalter bzw. Deine Nachfolger. Von denen wird erstmal niemand in nem Prozessalarm nach der Fehlerauswertung suchen.

Gruß.

ducati schrieb:

Ich denke, deshalb hast Du uns ja gefragt.

Zum Vergrößern anklicken....

Japp, da hast du natürlich Recht. Ich wollte jetzt auch nicht Tage damit verbringen, gibt ja auch Anderes zu tun Wollte die Idee nur nicht gleich verwerfen. Auf jeden Fall Danke für
die Erläuterungen!

Grüße,
DrTurkelten