TIA IEC Timer, PT-Änderung ohne Flanke am IN

Zuviel Werbung?
-> Hier kostenlos registrieren
SHo schrieb:
Wäre es nicht einfacher den Timer.Q mit nem ODER mit "Timer.ET >= Timer.PT" zu verschalten?

Anhang anzeigen 95409
Zum Vergrößern anklicken....
Aber wie magst Du es anders herum lösen wenn die neue Zeit größer wird, der Timer aber bereits bei seinem vorgesehenen Zeitpunkt Q auf TRUE schaltet? Glaub da wird Dein Aufbau noch größer werden müssen.
Wenn Du es unbedingt ohne vorgesehene Bausteine wie PT machen magst, dann musst Du einen Vergleicher vom Zeitwert der aussen am PT anliegt sowie dem PT im Speicher des Timers machen und wenn diese ungleich sind, dann per MOVE den neuen Zeitwert vom PT in den Speicher kopieren:
1775647661781.png
Allerdings macht genau das auch der Aufruf von -PT:
1775647688373.png

IEC-Timer kopieren bei Flankenwechsel von FALSE auf TRUE am IN den Zeitwert einmalig in den Speicher und arbeiten mit diesem Wert.
Daher muss von Aussen entsprechend der Wert verändert werden damit dies übernommen wird.


ducati schrieb:
ja, wie gesagt, hab schon immer meine eigenen Timer mit Visu-Anbindung
Zum Vergrößern anklicken....
Habe ich auch, also FBs erstellt welche mir entsprechende HMI-Variablen ausgeben können, wie z.B. die Ausgabe der Restzeit und seit Unified auch Farbwerte bei einigen Timern., allerdings nutze ich trotzdem die IEC-Timer.
Was machen Deine mehr als die können?
 
Das mit der Flanke ist so eine Sache die ich nicht verstehe. Wenn der Timer am IN false ist weil er nicht laufen soll, nun auf true geschaltet wird dann läuft er.
Ich kann mir den Unterschied nicht vorstellen zu Deiner Variante, es sei denn dein Timer wird bei Q=TRUE irgendwann alleine neu loslaufen solange IN anliegt oder der Zeitwert geändert wird.

Das mit dem Q und beschalten habe ich nicht als Problem. In Fup ist da immer was dran weil es irgendeine Kette ist, in SCL wird der Ausgang mit Timer.Q irgendwo abgefragt was keine Probleme macht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube dass einen Timer der 'tut wie ich es will' ist sehr individuell.
Ich verwende einen eigenen Timer und IEC Timer.
Am mindestens hat man mit die --(PT) den Möglichkeit die IEC Timer zu zwingen von 'lauf bis urspünglich gegebene Sollwert' auf 'lauf bis neu gegebene Sollwert', oder 'lauf immer auf die aktuell gegebene Sollwert', wie man es will.
 
Ich hab mal einen Baustein geschrieben:
Code: 
FUNCTION_BLOCK "VariableTimer"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT
      IN : Bool;
      PT : Time;
   END_VAR

   VAR_OUTPUT
      Q : Bool;
   END_VAR

   VAR
      ET : Time;
      last {InstructionName := 'DTL'; LibVersion := '1.0'} : DTL;
   END_VAR

   VAR_TEMP
      now {InstructionName := 'DTL'; LibVersion := '1.0'} : DTL;
      ret : Int;
      delta : Time;
   END_VAR


BEGIN
    #ret := RD_SYS_T(#now);
    
    IF #last <> DTL#1970-01-01-00:00:00 THEN
        #delta := T_DIFF(IN1 := #now, IN2 := #last);
    END_IF;
    
    IF #IN THEN
        #ET += #delta;
    ELSE
        #ET := T#0s;
    END_IF;
    
    #Q := #ET >= #PT;
    #last := #now;
    
END_FUNCTION_BLOCK
 
DeaD_EyE schrieb:
Ich hab mal einen Baustein geschrieben:
Zum Vergrößern anklicken....
Warum?

Meine Bedenken und Überlegungen, vielleicht nicht alles zutreffend aber mal darüber nachdenken:
- Zykluszeit stark beeinträchtigt (RD_SYS_T, T-DIFF)
- ET läuft auch nachdem Zeit abgelaufen ist weiter > Überlauf
- nur TON, nix anderes
- erster Zyklus ignoriert
- Zweiter Timerstart: last ist bereits auf 14 Uhr gesetzt am 4.Mai 2025, da lief er zuletzt. Er ist also ungleich des "Hacks" zum Initialisieren. Delta wird also berechnet mit Stand heute, da now nicht bekannt ist im ersten Zyklus, also auf 1970 steht. Delta ist also >55 Jahre, Timer ist dann wohl damit abgelaufen, also Q sofort an. Allerdings ist ET ja Datentyp Time, das sind etwas über 24 Tage, also ist vielleicht die Berechnung schon ein CPU-Stop, bin mir da nicht sicher.
- Verstellen der Uhrzeit hat zur Folge das sofort alle Timer triggern können -> RD_SYS_T ist ungeeignet, wenn schon, dann Runtime nutzen. Koppel niemals Anlagenfunktionen mit Bedeutung an die Uhrzeit der PLC.

Die Flanke zur Programmlaufzeit soll einiges verhindern. Im ersten Zyklus der CPU ist ein IN mit TRUE keine Flanke, damit nicht ungewollt irgendwelche Timer oder Teile von Programmen sofort losdaddeln. Arbeitet man nicht konsequent mit seinen eigenen Timern sondern gemischt mit IEC, dann sind IEC bei Null und die eigenen abgelaufen.

Ich denke das ist ein schneller Schuss, aber keine Lösung.
 
escride1 schrieb:
Das mit der Flanke ist so eine Sache die ich nicht verstehe. Wenn der Timer am IN false ist weil er nicht laufen soll, nun auf true geschaltet wird dann läuft er.
Zum Vergrößern anklicken....
Hab nicht die Zeit das nachzustellen, aber so wie ich das verstanden hatte, wenn bei CPU Neustart, bzw. nach CPU-Gesamtladen der IN im ersten Zyklus schon TRUE ist, läuft der TON nicht los und bleibt für immer aus...
Bei TOF wars glaub auch so, wenn im ersten Zyklus der IN schon TRUE ist, bleibt der Q aus...
 
escride1 schrieb:
Die Flanke zur Programmlaufzeit soll einiges verhindern. Im ersten Zyklus der CPU ist ein IN mit TRUE keine Flanke, damit nicht ungewollt irgendwelche Timer oder Teile von Programmen sofort losdaddeln.
Zum Vergrößern anklicken....
kleines Beispiel, ne Störmeldung soll mit nem TON verzögert werden. Wenn die Störmeldung bei CPU Start aber schon ansteht, wird die durch das TON nie durchgereicht...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ducati schrieb:
kleines Beispiel, ne Störmeldung soll mit nem TON verzögert werden. Wenn die Störmeldung bei CPU Start aber schon ansteht, wird die durch das TON nie durchgereicht...
Zum Vergrößern anklicken....
Das Thema hatten wir doch schon öfters. FirstScan ( Anlaufmerker ) am IN verknüpfen, dann hat man dieses Problem weg.
 
DeltaMikeAir schrieb:
FirstScan ( Anlaufmerker ) am IN verknüpfen, dann hat man dieses Problem weg.
Zum Vergrößern anklicken....
Ich habe die Verknüfung, Steuerspannung plus eine Verzögerung.
Einzigste Ausnahme ist die Überwachung von die 24V für die Steuerspannung. Für die habe ich FirstScan und eine Verzögerung.
Dies um die Alarmflut beim Steuerung Ein zu vermeiden.

(Entschuldigung, wenn wir hiermit vom Thema abgeleitet werden).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
escride1 schrieb:
Das mit der Flanke ist so eine Sache die ich nicht verstehe. Wenn der Timer am IN false ist weil er nicht laufen soll, nun auf true geschaltet wird dann läuft er.
Zum Vergrößern anklicken....
Das große Problem bei der Frage hier im Thema ist, an einem Timer, der bereits gestartet ist, den PT zu ändern. Der neue PT kann schon überschritten sein oder noch in der Zukunft liegen.


DeaD_EyE schrieb:
Ich hab mal einen Baustein geschrieben:
Zum Vergrößern anklicken....
Es war noch nie eine gute Idee, für Zeitmessungen die Uhrzeit eines Gerätes zu nehmen. Das kann bei Uhrzeit-Sync oder unbedarftem Uhr stellen schlimmstenfalls zum Stop der CPU führen. Für sowas nimmt man üblicherweise den Systemzeitgeber (RUNTIME oder TIME_TCK).
 
Ja ich kenne die Thematik das beim ersten Zyklus die Eingänge keine Flanke verursachen, weil der erste Programmzyklus eigentlich der zweite ist. (weshalb Siemens wohl den Anlaufmerker generiert hat und dies als Feature verkauft)
Bei dem Thema vor ein paar Jahren war ich auch mal dabei.

Ich dachte nun nur nicht an genau diese Thematik.
Aber ist ja nun klargestellt.
 

Similar threads

T
Step 7 Das Verhalten der Simatic Timer in verschiedenen Systemen
Antworten
16
Aufrufe
13K
DeltaMikeAir
DeltaMikeAir
DeltaMikeAir
TIA Neue Firmware 1500ér ( V2.6.1 )
2
Antworten
28
Aufrufe
18K
Timo3210
T
vollmi
TIA s7-1500 Timer resetieren
Antworten
5
Aufrufe
4K
vollmi
vollmi
E
TIA Anfängerfragen über Timer, Fehlerauswertung, Code mehrfach verwenden
Antworten
15
Aufrufe
3K
Ralle
Ralle
D
Programmierung einer zyklischen Beckhoff SPS mit ST
Antworten
19
Aufrufe
10K
DerBenutzer
D
Zurück
Oben