Timerproblem...

Zuviel Werbung?
-> Hier kostenlos registrieren
Habe ich das so richtig verstanden, dass man einem Timerausgang immer einen Merker zuweisen sollte, der dann z.B. einen Ausgang setzt?
Wie du aus den verschiedenen Beiträgen ersehen kannst geht es ggf. auch immer irgendwie anders - wenn du es dir aber so merkst dnn machst du NIE etwas falsch ...

Warum nun die umgedrehte Variante funktioniert und die andere nicht, ist mir noch immer nicht klar. :confused:
Mir auch nicht ... Manches muß man halt irgendwann mal einfach so hinnehmen (nicht nur bei Siemens - aber insbesondere dort). :cool:


Wenn die Zeit abgelaufen ist, so wird doch der Timerausgang Q (so wie alle Zustandsänderungen an Ein- u. Ausgängen) in das Prozessabbild der Ausgänge geschrieben. Und dann kann doch im Grunde "Q" (auch ohne einen Hilfsmerker) etwas im Programm setzen oder rücksetzen.
Wie du aus meinem und Peters Beitrag ersehen konntest sind nicht immer alle Dinge sinnvoll logisch zu erklären ...

Gruß
Larry
 
Danke LL,

also verwendet ihr echt am Timerausgang immer einen Merker, der dann andere Ein- u. Ausgänge im Programm steuert?

Stimmt meine Annahme...

... wenn die Zeit abgelaufen ist, so wird der Timerausgang Q (so wie alle Zustandsänderungen an Ein- u. Ausgängen) in das Prozessabbild der Ausgänge geschrieben?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Peter,

ich hatte deinen Beitrag in dem anderen Thread (auf den du dich hier beziehst) auch gelesen.
Zur Vervollständigung :
Code:
un T1
l s5t#2s
se t1

un t1
spb n1
l mw2
l 1
+i
t mw2
n1: nop 0
der dargestellte Code tut nicht was er soll - aber wenn man die Sequenz umdreht ...
Code:
un t1
spb n1
l mw2
l 1
+i
t mw2
n1: nop 0

un T1
l s5t#2s
se t1
... dann geht es auf einmal doch ...
Im gewissen Sinne ist das schon logisch.
Ausgangssituation: Der Timer schaltet vor bearbeiten des Codes.
Beim 1. Code löscht der Timer durch eine negative Flanke am S-Eingangs (UN T1) sich selber.
Dementsprechend ist der Timer beim Bearbeiten des nächsten UN T1 auf 0, somit überspringt er den nächsten Programmabschnitt.

Beim 2. Code wird erst der Programmcode bearbeitet und dann der Timer durch sich selber gelöscht.

Beim 2. Code kann es auch Probleme geben. Wenn der Timer zwischen dem addieren und dem Starten des Timers auf 1 geschaltet wird, dann könnte es auch sein, dass das Addieren nicht durchgeführt wird. Soviel ich weiß, wird der Timer nicht unbedingt am Zyklusanfang geschaltet.

Bitte korriegiert mich, wenn ich falsch liege.

Gruß wolder
 
... das läßt sich nicht pauschalisieren ...
In einem mit deinem Fall vergleichbaren Beispiel würde ich es möglicherweise so machen. Nur habe ich solche Fälle eigentlich nicht.
Bei mir würde ein Timer vielleicht ein Signal verzögern. Das könnte dan z.B. so aussehen :
Code:
u e 0.0
L s5t#1s
SE t 100

U T100
= M 123.4   // Verzögerung des E0.0
... oder das Weiterschalten einer Schrittkette :
Code:
U M10.1
L s5t#1s
SE t 101
NOP 0
NOP 0
NOP 0
U T101
S M 10.2
R M 10.1
... oder was auch immer.

Gruß
Larry
 
@Larry
Irgendwie enttäuscht du mich gerade, das dir der Unterschied zwischen Auswertung Timer vor bzw. nach dessen Aufruf nicht klar ist ...

Wenn du den Timer startest, so wird dieser "irgendwann" sprich in dem Fall genau 3s nach der Startflanke High, und das asynchron zum Zyklus,
aus dem Grund weiter oben der Hinweis "Interrupt", weil das ganze eben nicht am Zykluskontrollpunkt passiert sondern "irgendwann" im Zyklus.
Es könnte theoretisch nun also durchaus sein, das der Timer einen halben Zyklus noch nicht abgelaufen ist, und für den nächsten halben Zyklus ist er dann abgelaufen.

Mit der Merkerzuweisung des Timers schafft man sich nun also händisch einen definierten Punkt, der dann fürs gesamte Programm für wenigstens einen ganzen Zyklus definiert ist.

Der Obige Code mit
UN T1
L S5t#3s
SE T1

U T1
S A3.0

würde also nur funktionieren, wenn die 3 Sekunden "zufällig" zwischen dem SE T1 bzw. den U T1 abgelaufen wären,
die Wahrscheinlichkeit hierfür dürfte aber sehr nahe bei null sein.

Die gedrehte Variante:
U T1
S A3.0

UN T1
L S5T#3s
SE T1

hingegen funktioniert, weil das S A3.0 so die überwiegende Zeit den Timer-Ablauf mitbekommt,
bevor der Timer-Ablauf den Timer quasi wieder zurücksetzt "neu" startet.
Außer im Äußerst unwahrscheinlichen Fall, das der Timer zwischen S A3.0 und UN T1 abläuft.

Mfg
Manuel
 
Sorry, wenn ich hier nochmals nachfrage… ich kapiere es leider nicht.

Warum wird der Timer asynchron zum Zyklus High? Und was ist ein Zykluskontrollpunkt? Oder ist das bei allen Timern so?
 
Warum wird der Timer asynchron zum Zyklus High? Und was ist ein Zykluskontrollpunkt? Oder ist das bei allen Timern so?

Warum, gute Frage, ist halt so.
Zykluskontrollpunkt: Ist wo das PAE bzw. PAA gelesen bzw. geschrieben wird.
Ja das ist bei allen S5Timern (in der S7) so.

P.S. Die Tatsache das der Timer asynchron abläuft ist in deinem geschilderten Fall allerdings eher unerheblich.

Mfg
Manuel
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
soviele Gedanken hatte ich mir bisher über die S5-Timer nicht gemacht, da ich damit noch keine Probleme hatte. Aber
die Probleme, die mit der Interruptsteuerung der Timer auftreten können haben mich dazu veranlasst, dieses mit einem Test zu überprüfen. Dazu habe ich den OB1 auf unserer Testanlage erweitert, siehe OB1.PDF.
- CPU 414-2DP
- Zykluszeit ca. 3 - 4 ms, also ein kurzes Anwenderprogramm.
Ergebnis:
Auch bei einem einschaltverzögerten Timer tritt dieser Effekt auf.
Im 1. u. 2. NW wird der "SE T11" und nach dem Anwenderprogramm im NW 4 abgefragt und die Merker mit Hilfe von XOR verglichen
und bei Auftreten einer Differenz in M14.0 .. M14.2 eingespeichert.
Ergebnis:
M14.0 u. M14.2 werden sehr schnell gesetzt, M14.1 dauert länger, wird aber auch irgendwann gesetzt ( abhängig von der SE-Zeit );
die ersten beiden T11 Abfragen liegen ja auch unmittelbar hintereinander.

Das werde ich mit Sicherheit zukünftig beachten, auch wenn ich meistens SFB4 u. SFB5 benutze. Die sind ja als Multiinstanz in FB sehr praktisch.

Besten Dank für Eure Hinweise.

Anhang anzeigen OB1.pdf
 
Zuletzt bearbeitet:
Warum, gute Frage, ist halt so.
Mfg
Manuel

Danke Manuel,

hängt die Tatsache, dass alle S5-Timer asynchron zum Zyklus HIGH werden, damit zusammen, dass die gewählte Zeit halt irgendwann abgelaufen ist und sich der SPS-Zyklus dabei auch gerade in einem ganz anderen Baustein (als der Timer) befinden kann?
 
hängt die Tatsache, dass alle S5-Timer asynchron zum Zyklus HIGH werden, damit zusammen, dass die gewählte Zeit halt irgendwann abgelaufen ist und sich der SPS-Zyklus dabei auch gerade in einem ganz anderen Baustein (als der Timer) befinden kann?
Ja, auch wenn hier manche etwas anders behaupten.
Hatte ich dieses Problem nicht schon ganz am Anfang beschrieben? :rolleyes:
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, auch wenn hier manche etwas anders behaupten.
Hatte ich dieses Problem nicht schon ganz am Anfang beschrieben? :rolleyes:

Ähm, ja glaube schon Paule... nur hatte ich es da irgendwie noch nicht richtig verstanden... sorry... lag aber nicht an dir!

Achja, und diese S5-Timer sind aber schon mit den IEC-Zeiten wie z.B. TON, TOF oder TP vergleichbar?

Lieben Dank!
 
Achja, und diese S5-Timer sind aber schon mit den IEC-Zeiten wie z.B. TON, TOF oder TP vergleichbar?
Vergleichbar: Ja
Identisch: Nein
Haben beide so ihre Vor- und Nachteile.
Ich bevorzuge lieber die dritte Variante nämlich einen selber gemachten Zeitbaustein, was hier übrigens sehr viele User verwenden.
Aber wenn ich mal eben schnell eine Zeit reindrücken muss, gleitet mir so ein S5 Timer auch mal schnell von der Tastatur. ;)
 
Definiere "Vergleichbar"!

Die S5-Timer gibt es so seit Jahrzehnten bei der gleichnamigen Siemens S5, diese laufen mit Harter Echtzeit im System.
Die IEC-Timer sind lediglich ein Stück Software, welches eben aufgrund der IEC 1131 von Siemens nachträglich implementiert wurde als SFB, diese können ihren Zustand natürlich nur ändern (wie jeder beliebige Baustein auch) zum Zeitpunkt des Aufrufs mittels CALL.

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, auch wenn hier manche etwas anders behaupten.
Hatte ich dieses Problem nicht schon ganz am Anfang beschrieben? :rolleyes:

Kein Widerspruch dazu (ich fühle mich da mal angesprochen). Dennoch ist es so, dass das geschilderte Problem bei den SE- und SA-Timern bei korrekter Verwendung derselben normalerweise nicht zu Tage tritt (sie laufen ab und halten dann ihren Zustand).
Wie ich schon geschrieben habe habe ich das UN T1 - SE T1 noch nie gemacht - hätte aber angenommen, dass es auch funktioniert. C'est la vie ...
 
Die IEC-Timer sind lediglich ein Stück Software, welches eben aufgrund der IEC 1131 von Siemens nachträglich implementiert wurde als SFB, diese können ihren Zustand natürlich nur ändern (wie jeder beliebige Baustein auch) zum Zeitpunkt des Aufrufs mittels CALL.

Mfg

Manuel

Oje, das nächste Problem für mich...

Die IEC-Timer werden doch (so wie die S5-Timer) auch nur dann gestartet, wenn das entspr. NW des Bausteins, in dem sie progr. sind, bearbeitet wird. Oder verstehe ich hier jetzt etwas völlig falsch?
 
Das kannst du relativ leicht selbst testen!

OB35 mit 10 Sekunden Aufrufintervall

U M1.0
L S5t#5s
SE T1

CALL SFB4, DB1
IN := M1.0
PT := T#5s
Q := M2.0

Nun schaust du dir das in der VAR-Tabelle an ...

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für deine Erklärungen Manuel.

Hm, glaube jetzt schreiben wir grad aneinander vorbei.... Im TIA-Portal heißen die Timer nämlich IEC-Zeiten (TON, TOF) usw. Und das ist doch wieder etwas anderes als der von dir aufgeführte SFB4-Timer, oder?
 
Danke für deine Erklärungen Manuel.

Hm, glaube jetzt schreiben wir grad aneinander vorbei.... Im TIA-Portal heißen die Timer nämlich IEC-Zeiten (TON, TOF) usw. Und das ist doch wieder etwas anderes als der von dir aufgeführte SFB4-Timer, oder?

TIA kaschiert das nur besser, aber TON = SFB4, und selbst wenn nicht, dann wärs immer noch ein ordinärer FB ... spielt also für den von mir gemeinten Effekt keine Rolle,
dann ersetzt du SFB4 halt durch TON und Var-Tabelle durch Beobachtungstabelle ...
 
Hi Zusammen, ;)

nun habe ich auch noch mal ein paar Fragen zu diesen Timern. Komme da irgendwie auf keinen grünen Zweig.

1) Wenn man (zur Sicherheit) am Timerausgang so einen Merker benutzt, der dann im Programm beispielsweise einen Ausgang setzt - muss dieser Merker dann zwingend durch den Timer gesetzt werden, oder genügt hier auch eine Zuweisung?

2) Angenommen der Timer T1 soll einen Ausgang A0.0 im FC1 setzen. Nun wird aber, während die Zeit von T1 im FC1 abgelaufen ist, gerade der Baustein FC7 bearbeitet - was passiert nun?

Wird jetzt sofort der Ausgang A0.0 gesetzt, oder wird der Ausgang A0.0 im FC1 erst dann gesetzt, wenn alle Zustandsänderungen am Ende vom OB1 ins PAW geschrieben wurden?

Lieben Dank für Aufklärung.
 
Zurück
Oben