TIA V17: Muss bei Timern der Eingang IN immer beim Aufruf gesetzt werden?

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
bei Timern im Codesys Universum können Timer ohne Parameter oder auch mit nicht allen Parametern aufgerufen werden. Ich nutze dies zum Beispiel um in einer CASE-Anweisung durch direktes setzen des Einganges IN den Timer zu starten, dessen Aufruf erfolgt aber außerhalb der CASE-Anweisung.
Ich habe das nun auch in TIA versucht und da meckert TIA.
Meine Frage wäre nun, ist dies grundsätzlich nicht möglich, sprich, muss man "IN" und "PT" immer direkt beim Aufruf angeben?

 

[de vliegende hollander]

Wenn der Timer ausserhalb aufgerufen wird, gibt es da eine Instanz.
Dies
, ohne es ausprobiert zu haben muss in eine Case verwendet werden können.

Es gibt ein Aber;
Im 1500er wird bei jede Aufruf oder Zugriff auf der Instanz der Timer aktualisiert.
Das kann für dich ein ungewünschtes Effekt haben.

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube meine Informationen waren zu sparsam. Hier mal ein Codeausschnitt:

// Ausführung der Hilfsfunktionen.
#fbTON_ContinueDelay01(PT := T#2S);
#fbTON_ContinueDelay02(PT := T#2S);

// Beispiele für CASE-Anweisungen.
CASE #iStep01 OF    // Wenn Sie hier einen Breakpoint setzen können Sie die CASE-Anweisungen beobachten.
        // Sie können dann auch erkennen, dass in jedem Zyklus bei jeder CASE-Anweisung immer nur ein Schritt abgearbeitet wird.
    0:
        #xStep00Active := TRUE; // Schritt als aktiv kennzeichnen.
        #fbTON_ContinueDelay01.IN := TRUE; // Timer für Weiterschaltung in den nächsten Schritt starten.
        IF #fbTON_ContinueDelay01.Q THEN // Wenn die Zeit am Timer abgelaufen ist
            #fbTON_ContinueDelay01.IN := FALSE; // Timer stoppen.
            #xStep00Active := FALSE; // Schritt als nicht aktiv kennzeichnen.
            #iStep01 := 1; // Schrittnummer setzen.
        END_IF;

TIA meckert nun an, dass beim Aufruf der beiden TON auch IN angegeben werden muss.
Hier mal der selbe Code in TwinCAT (CODESYS):

// Ausführung der Hilfsfunktionen.
fbTON_ContinueDelay01(PT := T#2S);
fbTON_ContinueDelay02(PT := T#2S);

// Beispiele für CASE-Anweisungen.
CASE iStep01 OF    // Wenn Sie hier einen Breakpoint setzen können Sie die CASE-Anweisungen beobachten.
                // Sie können dann auch erkennen, dass in jedem Zyklus bei jeder CASE-Anweisung immer nur ein Schritt abgearbeitet wird.
    0:
        xStep00Active                := TRUE; // Schritt als aktiv kennzeichnen.
        fbTON_ContinueDelay01.IN    := TRUE; // Timer für Weiterschaltung in den nächsten Schritt starten.
        IF fbTON_ContinueDelay01.Q THEN // Wenn die Zeit am Timer abgelaufen ist
            fbTON_ContinueDelay01.IN    := FALSE; // Timer stoppen.
            xStep00Active                := FALSE; // Schritt als nicht aktiv kennzeichnen.
            iStep01    := 1; // Schrittnummer setzen.
        END_IF

In TwinCAT läuft das fehlerfrei.

 

[de vliegende hollander]

TIA meckert nun an, dass beim Aufruf der beiden TON auch IN angegeben werden muss.
Hier mal der selbe Code in TwinCAT (CODESYS):

Vielleicht funktioniert wass du willst, wenn dun den Timer separat in eine neue FB packst.
Den FB hat als Multiinstanz den Timer.

 

[Ludewig]

Anders als andere Software, kann Siemens nicht beschaltete Parameter in der Regel nicht anzeigen. In AWL hagelt es bei unseren alten Programmen auch immer Warnmeldungen. Du kannst nach meiner Erinnerung zur Abhilfe
Timer( IN:=Timer.IN, PT:= T#2S)
schreiben, also ohne zusätzliche Hilfsvariable einfach den Ausdruck von vorher wiederholen. Dann war, meine ich, Ruhe. Und Du siehst den aktuellen Zustand am Ort des Aufrufs.
Bei Dir also
fbTON_ContinueDelay01(IN:= fbTON_ContinueDelay01.IN , PT := T#2S);

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anders als andere Software, kann Siemens nicht beschaltete Parameter in der Regel nicht anzeigen. In AWL hagelt es bei unseren alten Programmen auch immer Warnmeldungen. Du kannst nach meiner Erinnerung zur Abhilfe
Timer( IN:=Timer.IN, PT:= T#2S)
schreiben, also ohne zusätzliche Hilfsvariable einfach den Ausdruck von vorher wiederholen. Dann war, meine ich, Ruhe. Und Du siehst den aktuellen Zustand am Ort des Aufrufs.
Bei Dir also
fbTON_ContinueDelay01(IN:= fbTON_ContinueDelay01.IN , PT := T#2S);

Mit einer Warnmeldung könnte ich ja leben, aber es kommt eine Fehlermeldung, dss IN beschaltet werden nuss.

 

[Larry Laffer]

Dies sollte auch bei TIA funktionieren - würde ich aber nicht so machen :

fbTON_ContinueDelay01.IN := TRUE; // Timer für Weiterschaltung in den nächsten Schritt starten.
IF fbTON_ContinueDelay01.Q THEN // Wenn die Zeit am Timer abgelaufen ist
fbTON_ContinueDelay01.IN := FALSE; // Timer stoppen.
-----

Dies wird in TIA nicht funktionieren :

fbTON_ContinueDelay01(PT := T#2S);

Ganz generell würde ich (einfach um Fehlern vozubeugen) die Timer immer ausserhalb einer indirekten Bearbeitung aufrufen.
Im Falle eines CASE könnte man ja auch genauso gut die Schrittnummer als Startbedingung für den Timer nehmen ...

 

[PN/DP]

TIA meckert nun an, dass beim Aufruf der beiden TON auch IN angegeben werden muss.

Gibt TIA auch eine Erklärung warum?

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gibt TIA auch eine Erklärung warum?

Die steckt implizit in der Hilfe drinnen wo es den Hinweis gibt, dass .Q und .ET neu berechnet werden, wenn sie abgesetzt vom eigentlichen Aufruf verwendet werden.

Bei TIA sind Timer keine echten FBs mit statischen Variablen sondern es sind Hilfskonstrukte, aus denen der Compiler dann Maschinencode baut und zwar in einer Weise dass sich zB TON so verhält wie SE in S7-Classic.

Wenn du das Verhalten von Codesys oder anderen Systemen haben willst muss du einen FB herum bauen. Für TON, TOF und TP gilt: nur 1 mal aufrufen, alle benötigten Parameter hier direkt beschalten und dann nur mit den angeschaltet Variablen weiterarbeiten.

 

[oliver.tonn]

Die steckt implizit in der Hilfe drinnen wo es den Hinweis gibt, dass .Q und .ET neu berechnet werden, wenn sie abgesetzt vom eigentlichen Aufruf verwendet werden.

Bei TIA sind Timer keine echten FBs mit statischen Variablen sondern es sind Hilfskonstrukte, aus denen der Compiler dann Maschinencode baut und zwar in einer Weise dass sich zB TON so verhält wie SE in S7-Classic.

Wenn du das Verhalten von Codesys oder anderen Systemen haben willst muss du einen FB herum bauen. Für TON, TOF und TP gilt: nur 1 mal aufrufen, alle benötigten Parameter hier direkt beschalten und dann nur mit den angeschaltet Variablen weiterarbeiten.

Hm, ich dachte dieses, für nicht Siemens kundige, seltsam anmutende Verhalten gäbe es nur bei den S5 Timern und bei den neuen IEC-Timern wäre das nicht mehr so.

 

[UDP]

Aus eigener Erfahrung mit Siemens-Timern und versuchter Mehrfachverwendung in verschiedensten Formen durch externe Programmierer: Timer an einer Stelle jeden Zyklus aufrufen und mit Globalen Variablen versorgen, die dann im weiteren Programm weiter verwendet werden. Nur so kann man für konsistentes Verhalten während eines Zyklus mit Timern sorgen. Alles andere führt in unglücklichen Konstellationen immer zu ungewünschten Nebeneffekten.

Ganz schlimm sind bedingte Timeraufrufe an mehreren Stellen im Programm...

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aus eigener Erfahrung mit Siemens-Timern und versuchter Mehrfachverwendung in verschiedensten Formen durch externe Programmierer: Timer an einer Stelle jeden Zyklus aufrufen und mit Globalen Variablen versorgen, die dann im weiteren Programm weiter verwendet werden. Nur so kann man für konsistentes Verhalten während eines Zyklus mit Timern sorgen. Alles andere führt in unglücklichen Konstellationen immer zu ungewünschten Nebeneffekten.

Ganz schlimm sind bedingte Timeraufrufe an mehreren Stellen im Programm...

Den Timer nur an einer Stelle aufrufen mache ich ja schon, ich wollte nur vermeiden weitere Variablen zu verwenden und den Eingang IN in der CASE Anweisung direkt setzen und beim Aufruf weglassen. Da das ja nicht geht werde ich jetzt noch Variablen für IN und Q hinzufügen um ein Verhalten des Timers wie im CODESYS Universum zu erreichen.

 

[Ludewig]

Nach meiner Wahrnehmung werden jetzt hier zwei Themen vermischt:

1. Ich möchte entsprechend den IEC-Möglichkeiten die Eingänge eines Timers an anderer Stelle im Programm beschalten (wie in Codesys, Sucosft). Allerdings verweigert der SCL-Compiler die Mitwirkung. Meine in #5 gezeigte Lösung behebt dieses Mecker-Problem. Einen realen Funktionstest bei einer 1500er muss ich mangels aktuell installierter Hardware auf später verschieben. In der Kombi TIA 16 + S7-300 in AWL funktioniert das auf jeden Fall. Dort wird aber nur gewarnt, nicht "gefehlert".

2. Ist es möglich, sinnvoll, etc. einen Timer innerhalb von Bedingungen zu beschalten oder gar aufzurufen. Hier verhalten sich die Siemeens IEC-Bausteine aus meiner Sicht nicht normgerecht, da sie nicht zyklussynchron arbeiten. Andere hier im Forum haben da aber mehr Erfahrung, so dass ich hierzu keine Aussagen machen will.

 

[ducati]

hier gabs doch schon gefühlt 100 Beträge zu diesen TIA-Timern... Das ist halt Raketentechnologie...

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

hier gabs doch schon gefühlt 100 Beträge zu diesen TIA-Timern... Das ist halt Raketentechnologie...

Da muss ich mich schuldig bekennen, da habe ich diesmal nicht wirklich gesucht.

 

[ducati]

Da muss ich mich schuldig bekennen, da habe ich diesmal nicht wirklich gesucht.

nee, das ist ja nicht Dein Problem. Frag mich nur was den Siemens geritten hat, ne simple Ein-/Ausschaltverzögerung so kompliziert zu machen, dass hier überhaupt jemand dazu ne Frage stellen muss...