TIA IEC Timer, wesentliche Unterschied zwischen S7-300 und S7-1500 !?

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe ein grossen Unterschied gefunden bei die IEC Timer in S7-300 und S7-1500.

In Classic/S7-300 wird den Timer Sollwert PT ständig gelesen.
D.h., wenn der Timer schon gestartet ist mit ein Sollwert z.B. 100 Sekunden, aber bevor das den Sollwert erreicht ist wird PT auf 20 Sekunden geändert, dann läuft der Timer bis 20 Sekunden erreicht ist und der Ausgang Q wird aktiviert.

In TIA/S7-1500 wird den Timer Sollwert PT nur beim Timer-Start gelesen.
D.h., wenn der Timer schon gestartet ist mit ein Sollwert z.B. 100 Sekunden, aber bevor das den Sollwert erreicht ist wird PT auf 20 Sekunden geändert, dann läuft der Timer bis 100 Sekunden erreicht ist und der Ausgang Q wird aktiviert.

Für Classic habe ich dies getestet mit PLCSIM und ein IM151-8 Program.
Für TIA habe ich dies getestet mit PLCSIM-1500 und ein S7-1512SP Program, und auch in ein realen S7-1515SP Open Controller.

Das hat schon ein Auswirkung von den Funktionalität von ein migrierte Program bedeutet.
Muss ich wirklich mein eigene Timer erstellen ?
Oder gibt es ein Funktion womit man in S7-1500 den PT Sollwert nach Timer start aktualisieren kann ?

 

[RONIN]

Tatsache, hab's auch grad noch einmal zwischen ner 315-2DP und Et200SP-CPU in Hardware verglichen.

Da wird wirklich nichts anderes überbleiben als eigene Timer zu schreiben.
Mit den ganzen Verhaltensunterschieden...

• Aktualisierungsverhalten
• Resetverhalten
• Zeit-Vorgabe-Verhalten

...will ich keine Anlage migrieren.

Bei mir steht auch gerade die erste 300er-Migration an. Danke Jesper, damit werde ich wohl auch die Siemens-IEC-Timer rausschmeißen müssen.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke, dann ist es bestätigt dass diese Verhalten auch für ein Hardware S7-1500 gelt.
Ich habe as ja "nur" mit PLCSIM-1500 und ein Open Controller getestet. beide sind ja Software S7-1500.

 

[Zombie]

Ich verstehe das Problem gerade irgendwie nicht. Wenn ich Timer verwende, dann stelle ich die Laufzeit doch einmalig während der IBN ein und lass den Timer dann Jahre lang mit der Zeit laufen, weil ich an dieser Stelle immer diese Verzögerungszeit brauche (Stillstandserkennung, etc.). Deshalb frage ich mich nach dem Anwendungsfall bei dem man zur Laufzeit eine neue Zeit vorgeben muss.
Das kam mir bisher noch nicht unter und ich kann mir auch gerade keinen Fall ausdenken wo das der Fall sein sollte.
Es wäre nett, wenn ihr mir da vielleicht den ein oder anderen Fall mal darlegen könntet, wo ihr dieses Vorgehen anwendet?
Vielen Dank

Gruß

 

[DeltaMikeAir]

Hallo,

es gibt ja Anlage, an denen Timer per Panel eingestellt werden können. Oder automatisiert per Programm.
Wird am Panel nun eine Zeit umgestellt und genau dieser Timer läuft bereits, reagiert der Timer erst einmal
nicht auf den neuen Zeitwert. Erst beim nächsten antriggern.

Das ist schon ein Nachteil.

 

[DOD666]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also bei mir sind einige Zeiten aus der Visualisierung heraus konfigurierbar.

z.B. Klappenbewegung zeit bis die Endlage erreicht sein muss.
Das will ich bei 100 Stück doch nicht alles einzeln im Programm 100 mal fest einstellen.
Dann geht nach einiger Zeit die Klappe etwas schwerer wegen Verschmutzung und dann müsste ich einen Techniker zum kunden Schicken der das Programm ändert nur weil ein Timerwert nicht passt. Das ist mir zu Teuer.

Gruß

Jens

 

[DeltaMikeAir]

Hallo,

also mit "das ist schon ein Nachteil" meinte ich nicht, dass Timer am Panel eingestellt werden können. Das
ist schon eine gute Sache. Aber das ein geänderter Zeitwert nicht sofort akzeptiert wird, könnte in vielen
Konstellationen ein Problem sein. Gerade bei längeren Zeitwerten.

Mit Grüßen

 

[Zombie]

Oh ja, da habt ihr recht. An längere Zeitwerte, z.B. bei Backzeiten, hatte ich nicht gedacht.
Timer sind bei uns selten länger als ein paar Sekunden und wenn ich ihn ändere stelle ich ihn dann um ne Sekunde hoch oder runter. Das variable eingeben der Laufzeit setzen wir aber aus gutem Grund nicht ein, da wir unsere Anlagen häufiger in einer Umgebung aufbauen bei denen die MA des Kunden ihre Finger selten bei sich lassen können. Und nein, Passwortschutz hat nicht geholfen. Wenn dann der Kunde anruft weil die Positionierwartezeit auf 1,5 St hochgestellt wurde und das Dinge deshalb nichts mehr macht, lernt man daraus.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

es gibt ja Anlage, an denen Timer per Panel eingestellt werden können. Oder automatisiert per Programm.

Haben wir beide.
Für die Timer die automatisch durch das Program eingestellt werden kann es passieren dass die Werte die für den Berechnung von den Timersollwert verwendet werden innerhalb von den Timerdurchlauf sich ändert. In den Fall muss der Timer sich ungehend an die neue Werte anpassen.

 

[RONIN]

Hab ich beides, ob im ms-Bereich oder rauf bis 600min oder selten mehr...
Das Time-Format geht ja bis 24Tage. Beim LTIME sogar noch ewig länger.
Grad beim LTIME ist toll, wenn die Uhr mal läuft, dann läuft sie erst mal 300 Jahre.

Wenn dann der Kunde anruft weil die Positionierwartezeit auf 1,5 St hochgestellt wurde und das Dinge deshalb nichts mehr macht, lernt man daraus.

Ist aber ein genauso gutes Beispiel.
Früher konnte dein Kunde einfach den Timer selbst wieder runter auf den richtigen Wert stellen und deine Anlage macht sofort weiter.
Nach der 1500er-Migration geht das nicht mehr, in dem Fall muss der Kunde auch einen Weg finden den ganzen Timer neu zu starten, sei es durch stoppen des Gesamtvorgangs, abbrechen einer Schrittkette oder sonst wie...

Also für mich ist das ein wesentlicher Unterschied.

 

[vollmi]

Die S7-1500 Timer unterscheiden sich sowieso massiv von den 300er Timern. Nicht nur das Verhalten bei neuen Zeiten sondern auch die Abfragefunktion. Die Starts die Resetfunktionen etc. Also da muss man sich entweder darauf einstellen oder wirklich eigene Timer bauen.

mfG René

 

[miasma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du die Zeit über die Anweisung PRESET_TIMER lädst kannst Du auch zur Laufzeit des Timers ändern. Das kann man schön im IDB beobachten.

 

[JesperMP]

Wenn du die Zeit über die Anweisung PRESET_TIMER lädst kannst Du auch zur Laufzeit des Timers ändern. Das kann man schön im IDB beobachten.

Aha !
Gibts leider nur unter AWL oder SCL. Kein FUP oder LAD. Man kann aber ein AWL Netzwerk in FUP und LAD einfügen. So weit so gut (obwohl umständlich).
Und jetzt werde ich WAHNSINNIG !!!
Es scheint das PRESET_TIME verlangt das der Type ist ein TIME. Dies obwohl das der IEC Timer gerne entweder TIME, DINT oder DWORD akseptiert. Und ja, ich brauche das es ein DINT ist weil ich Berechnungen mache mit diese Variabel.
Und dies obwohl in AWL in normalen Fall kein Typechecking gemacht wird.
Ich finde ein Weg, aber es wird sehr umständlich.

Es scheint das Siemens weis es ist ein Problem, und hat dafür eine halbe Lösung gemacht.

 

[miasma]

Doch gibt es auch für FUP und KOP heißt da nur PT.
Also bei mir geht DINT an der Anweisung PT allerdings dann halt nur in ms.



Ich habe bei solchen Verhalten eher den Eindruck das Siemens so langsam alle seine Funktionen auf Event getriggert umbaut. So wie es auch schon bei den Technologie Objekten der Fall ist.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aha.
Das scheint als eine fast akseptable Lösung zu sein. Habe es getestet und es funktioniert. edit: NEIN, da war ich zu schnell. Siehe unten.
Nur muss man sämtliche Verwendungen von die IEC Timer checken und wenn benötigt mit diese PRESET_TIMER/PT ergänzen.
(Und Siemens, warum unterschiedliche Namen für dieselbe Anweisungen in AWL/SCL und FUP/LAD ? :sb7: )

 

[RONIN]

Das mit dem PT war mir schon klar.
Bei Migration willst ich aber keinen Zusatzcode einbauen,.
Da wechselt man (auch wegen der anderen Probleme) lieber gleich auf einen Timer der sich in Schnittstelle und Aufbau gleicht wie der S7-300-TON verhält.

Aber gut, für neue 1500er-Projekte ist es nicht so schlimm, solange man das Verhalten kennt.

@Jesper: Das mit dem "PRESET_TIMER" und der Abkürzung "PT" ist schon Ok. In FUP will ich für die Funktion keinen Giganto-Block haben.

 

[JesperMP]

Nein, es ist noch nicht OK.

PRESET_TIMER übernimmt den neuen Wert nur einmal (!?).
Laut der Hilfetext für PRESET_TIMER/PT:

Use the "Load time duration" instruction to set the time duration of an IEC Timer. The instruction is executed in every cycle when the result of logic operation (RLO) at the input of the instruction has the signal state "1". The instruction writes the specified time duration to the structure of the specified IEC Timer.

Das lautet ja gut, aber nein:

Note
The "Tag_Input_2" is executed as pulse flag in order that the time duration is loaded only throughout one program cycle.

"Tag_Input_2" ist in das Beispiel in der Online Hilfe auf das IN von der PT Anweisung belegt.
Also, PT wird NICHT zyklisch aktualisiert sondern mann muss umständlich irgendwie dafür sorgen das PT mit ein Flanke aufgerufen wird.
* Stöhn *
Habe gerade getestet das genau so ist es.

 

[miasma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Migration bedeutet ja nur Wechsel der Plattform und nicht das die Systeme vollständig kompatibel sind.

Ich finde diesen Mechanismus bei der Timern eigentlich ganz gut. Ich kann nur ganz gezielt über eine Methode seine Instanzdaten manipulieren.
Das passt auch zur neuen Funktion in der V14 bei der ich Instanzen als Parameter übergeben kann, damit ich "sauber von außen" in Instanzdatenbausteinen manipulieren kann.

 

[JesperMP]

Dies hat nix mit manipulation von die Instanzdaten von die IEC Timer zu tun.
Es gibt ein Input PT um den Sollwert auf den IEC Timer zu übertragen.

Ich will nur ein Timer der "normal" funktioniert. Ohne das ich aufwendige Umwege machen soll um den Sollwert zu aktualisieren.

 

[RONIN]

Migration bedeutet ja nur Wechsel der Plattform und nicht das die Systeme vollständig kompatibel sind.

Da bin ich bei dir.

Mann sollte nur die Sache nicht als 1:1 migrierbar kommunizieren bzw. so Themen "Zykluskontrollpunkt" oder "Komplett geändertes Timerverhalten" zumindest in seinem "Migrationsleitfaden: SIMATIC S7-300/S7-400 nach SIMATIC S7-1500" zumindest erwähnen.

Bei der Anzahl an Unterschieden ist es schon mutig das der Siemens-Migrationsprozess automatisch die neuen TONs einbaut und damit das Programm in seiner Integrität vermutlich zerstört...
Im Prinzip ist Migration aktuell ein Haufen Arbeit und durchaus riskant. Aber all das ist ein anderes Thema.