# Timer in Multiinstanz



## Beren (6 Juni 2008)

*gelöscht*


----------



## IBFS (6 Juni 2008)

Beren schrieb:


> Moin
> 
> Wenn ich in einem Multiinstanz FB einen Timer zur Laufzeitüberwachung definiere, beispielsweise T100, was passiert dann, wenn ich den FB mehrfach instanziiere? T100 kann doch nur einmal exisitieren. Funktioniert das überhaupt?
> 
> ...


 

Nein - wie du schon vermutest geht das nicht.

Es geht nur mit den IEC-Timer...


----------



## vierlagig (6 Juni 2008)

IBFS schrieb:


> Es geht nur mit den IEC-Timer...



oder mit übergabe der timer-nummer an der schnittstelle des bausteins


----------



## Beren (6 Juni 2008)

*gelöscht*


----------



## vierlagig (6 Juni 2008)

Beren schrieb:


> Wie funktioniert das mit dem f_ton? Muss ich den in einen eigenen DB stecken? Oder kann ich den SFB direkt in meinem Netwerk einsetzen? Welche Bezeichnung bekommt der Baustein?



du kannst es als multiinstanz einbinden


----------



## Beren (6 Juni 2008)

*gelöscht*


----------



## vierlagig (6 Juni 2008)

Beren schrieb:


> Habe gerade dem SFB einen Instanz DB zugeteilt. Jetzt gebe ich über F_Ton den Instanz DB an und der Editor nimmt es an. Ist das so richtig?



wenn du einen festen instanz-DB benutzt kommt es aufs selbe raus, als wenn du einen s7-timer einsetzen würdest


----------



## Beren (6 Juni 2008)

*gelöscht*


----------



## OHGN (6 Juni 2008)

Als Multiinstanz aufrufen!!!

siehe hier...


----------



## Beren (6 Juni 2008)

*gelöscht*


----------



## IBFS (6 Juni 2008)

vierlagig schrieb:


> oder mit übergabe der timer-nummer an der schnittstelle des bausteins


 

ich vermeide "tausendfache" Verwendung von S5-Timern.
Ich habe pro Projekt - pro Seq.-ablauf max. einen, d.h.
im gesamten Projekt 15-20.

Wenn ich bei jedem einzelnen Antrieb - oder was auch immer 
ein bis zwei S5-Timer verbrate wird das sehr fehleranfällig.
Und auch das hin- und her-kopieren zwischen Projekten wird
aufwändiger. 
Es bischen "Codesys-Totalinstanziierung" innerhalb von STEP7
ist schon von Vorteil.   


Gruß


----------



## vierlagig (6 Juni 2008)

@IBFS: ich wollte nur auf eine andere möglichkeit hinweisen, bei dir klang das so absolut  ... und es gibt auch noch eine dritte möglichkeit: cpu-takt an baustein übergeben und damit inkrementieren oder dekrementieren, ist eine wirklich praktikable, speichersparende lösung für zeitunkritische anwendungen. wobei: wo fängt zeitkritisch an? und benutzt man dafür dann nicht einen interrupt?


----------



## IBFS (6 Juni 2008)

vierlagig schrieb:
			
		

> es gibt auch noch eine dritte möglichkeit: cpu-takt an baustein übergeben und damit inkrementieren oder dekrementieren, ist eine wirklich praktikable, speichersparende lösung für zeitunkritische anwendungen.


 
genau!

OB1

```
L     #OB1_PREV_CYCLE
   T     MDxxx
```
 
FCxx

```
L     MDxxx                           
      L     Ablaufzeit_Station_01        
      +D    
      T     Ablaufzeit_Station_01         
      T     #Zeit
```
 
(alles Variablen vom Typ TIME)

...und bei jedem Verlassen des "SPL-Schrittes" wird 

Ablaufzeit_Station_01 

mit T#0MS überschieben.

So hat man die Abgelaufene Zeit im jeweiligen Schritt (vgl.: Schritt.U bei GRAPH)
und damit Vergleichen.

Gruß


----------



## m_matrix (6 Juni 2008)

Danke die Idee find ich Klasse, ich hab das bisher so gelöst, dass ich
über eine aus dem Taktmerkerbyte erzeugte Flanke an den entsprechenden
Stellen Zeitwerte bedingt inkrementiert habe.  (Is sicher nicht schlecht
wenn man ne geringe auflösung braucht)


Gruß
Michi


Den Tipp werd ich gleich mal wo umsetzen


----------



## Kai (6 Juni 2008)

Beren schrieb:


> Wenn ich in einem Multiinstanz FB einen Timer zur Laufzeitüberwachung definiere, beispielsweise T100, was passiert dann, wenn ich den FB mehrfach instanziiere? T100 kann doch nur einmal exisitieren.


 
Hier noch mal ein Beispiel für die Verwendung des IEC-Timers SFB4 TON als Störmeldeverzögerung in einem Multiinstanz-FB:

http://www.sps-forum.de/showpost.php?p=122573&postcount=31

Gruß Kai


----------



## HeizDuese (6 Juni 2008)

Fertiges Beispiel zum gucken: http://www.automatisierungsprofi.de/TON/index.htm


----------



## bike (6 Juni 2008)

Bei den IEC Timern stört mich, dass pro Timer 20 DW notwendig sind, der Timer nur lokal geprüft werden kann. 
Es nicht möglich ist mal eben in eine VAT t1 schreiben und sehen was los ist.
Ausserdem gehen die IEC Timer saumässig auf die Zykluszeit der PLC


bike


----------



## HeizDuese (7 Juni 2008)

bike schrieb:


> Bei den IEC Timern stört mich, dass pro Timer 20 DW notwendig sind, der Timer nur lokal geprüft werden kann.
> Es nicht möglich ist mal eben in eine VAT t1 schreiben und sehen was los ist.
> Ausserdem gehen die IEC Timer saumässig auf die Zykluszeit der PLC
> 
> ...





Gott sei Dank sind die Zeiten vorbei, wo man die NOP's weggekratzt hat, um weiteren kostenbaren Speicher für noch benötigte Erweiterungen zu erhalten. Vorbei auch die Zeiten, wo man mit 256 Timern und 'ner Menge Trickschaltungen sich selber Verzögerungen gebaut hat und bei großen Projekten Zykluszeiten gegen 1/2 Sekunde erreichen konnte - selbst bei einigen hundert Aufrufen von TON's ist das auf einer S7 kein Thema mehr.

MIt der Argumentation sollte man von großen Projekten und PCS7 die Finger lassen  

Bei Kleinsteuerungen reichen dann wohl auch die vorhandenen S5-Timer.


----------



## bike (7 Juni 2008)

Also da muss ich dir leider widersprechen.
Wenn mal Software für grosse CNC Bearbeitungszeiten, bei denen z.B. Werkzeugwechsler  zeitkritisch sind, entwickelst, dann ist jede Millisekunde wichtig. 
Und wenn man nur kleine Steuerungen hat, die wenig Speicher haben, auch dann erinnert man sich gern an die S5 Timer.
Und wenn bei komplexen Abläufen Fehler gesucht werden, freut man sich wenn man in einer VAT einen Timer auf die Schnelle anschauen kann.

Ausserdem braucht und brauchte ein Nop so weit ich weiss keinen Speicher.

Zum Glück sind Entwickler Künstler und haben die künstlerische Freiheiten.


bike


----------



## zotos (7 Juni 2008)

bike schrieb:


> Also da muss ich dir leider widersprechen.
> Wenn mal Software für grosse CNC Bearbeitungszeiten, bei denen z.B. Werkzeugwechsler  zeitkritisch sind, entwickelst, dann ist jede Millisekunde wichtig.
> Und wenn man nur kleine Steuerungen hat, die wenig Speicher haben, auch dann erinnert man sich gern an die S5 Timer.
> Und wenn bei komplexen Abläufen Fehler gesucht werden, freut man sich wenn man in einer VAT einen Timer auf die Schnelle anschauen kann.
> ...



Eine Millisekunde ist ja auch ein riesige Zeit. Es gibt SPSen die in einer Millisekunde recht große Programme mit vielen IEC Timern abarbeiten können.

Und zu dem Thema Timer (in Sepp7) selber bauen... wenn dann mit dem OB1_PREV_CYCLE (siehe z.B. das Beispiel von IBFS). Wobei ich die IEC Timer als Standardlösung besser finde.


----------



## bike (7 Juni 2008)

zotos schrieb:


> Eine Millisekunde ist ja auch ein riesige Zeit. Es gibt SPSen die in einer Millisekunde recht große Programme mit vielen IEC Timern abarbeiten können.


  Stimmt, doch mache das einmal Siemens klar, dass die 840d so schnelle Cpu braucht und unseren Kunden, dass sie eine schneller und leider teuere Hardware  brauchen.

bike


----------



## kermit (8 Juni 2008)

ich hab für mich entschieden, resourcenschonend die Millisekunden von OB1_prev_cycle zu zählen. Gut, mal geschwind so ein S5-Timer, das ist auch recht nett, wenn es mal schnell und unkompliziert gehen darf. IEC-Timer: im Prinzip besser, aber eben leider teurer in der Verwendung und auch unflexibler


----------



## IBFS (8 Juni 2008)

kermit schrieb:


> ich hab für mich entschieden, resourcenschonend die Millisekunden von OB1_prev_cycle zu zählen. Gut, mal geschwind so ein S5-Timer, das ist auch recht nett, wenn es mal schnell und unkompliziert gehen darf. IEC-Timer: im Prinzip besser, aber eben leider teurer in der Verwendung und auch unflexibler


 

wie ich schon sagte, aber man sollte die OB1_prev_cycle nicht für
zu lange Prozesszeiten verwenden - für die Störüberwachung spielt die
Zeitgenauigkeit ja keine Rolle.

Bespiel:

gewünschte Zeit: 30 Sekunden ==> 

bei CPU317 OB1_prev_cycle wird immer aufgerundet auf 3 Millisekunden

weil ECHTE Zykluszeit 2,55 msec 

das sind 10000 Durchläufe ==> dann hat man gemittelt 25,5 Sekunden und nicht 30 Sekunden.

Dann vielleicht besser alles auf UTC beziehen:

http://www.sps-foren.de/showpost.php?p=124788&postcount=7

Gruß


----------



## Stollentroll (8 Juni 2008)

*Pro s5timer*

S5Timer kennt jeder, kann jeder! 

Was braucht man mehr?


----------



## vierlagig (9 Juni 2008)

Stollentroll schrieb:


> S5Timer kennt jeder, kann jeder!
> 
> Was braucht man mehr?



zeiten die man in bibliotheksfähigen bausteinen verwenden kann! also z.b. die iec-timer als multiinstanz in FBs, OB_PREV_CYCLE addierer in FBs und FCs und evtl. die taktmerkerbyte addierer die auch in FCs UND FBs funktionieren... das sind alles bessere lösungen als die übergabe der Timer-Nr. ...


----------



## bike (9 Juni 2008)

vierlagig schrieb:


> das sind alles bessere lösungen als die übergabe der Timer-Nr. ...


 
Ja?

Da sind denke ich erhebliche Zweifel angesagt.
Warum die Übergabe eines Timers nicht gut und zuverlässig sein soll erschliesst sich mir nicht ganz.
Ein IEC timer, den kann ich doch direkt garnicht in anderen Funktionen verwenden, S5 Timer schon.
Und wegen Bibliotek: Es ist doch einfach symbolisch zu programmieren und dann dem Nutzer die Adresse des Timers zu überlassen.



bike


----------



## vierlagig (9 Juni 2008)

bike schrieb:


> Ja?



JA!



bike schrieb:


> Da sind denke ich erhebliche Zweifel angesagt.
> Warum die Übergabe eines Timers nicht gut und zuverlässig sein soll erschliesst sich mir nicht ganz.



weil man immer wieder eine rückversicherung ala referenzdaten/"gehe zu verwendungsstelle" braucht um timer nicht doppelt zu belegen.



bike schrieb:


> Ein IEC timer, den kann ich doch direkt garnicht in anderen Funktionen verwenden, S5 Timer schon.



in funktionen nicht - siehe meine ausführungen oben - in funktionsbausteinen kannst du weiter oben erwähnte multiinstanz verwenden



bike schrieb:


> Und wegen Bibliotek: Es ist doch einfach symbolisch zu programmieren und dann dem Nutzer die Adresse des Timers zu überlassen.


 
warum auf halben weg stehen bleiben, warum dem nutzer oder sich selber noch auferlegen den aufgerufenen baustein noch mal zu bearbeiten. darüber hinaus kannst du mit globaler adressierung den baustein eben nicht mehrfach aufrufen. und wenn du jetzt wieder sagst: schnittstelle - nr. übergeben, dann schau oben ...


----------



## Perfektionist (9 Juni 2008)

IBFS schrieb:


> ...bei CPU317 OB1_prev_cycle wird immer aufgerundet auf 3 Millisekunden
> weil ECHTE Zykluszeit 2,55 msec
> ...


diese Erfahrung hab ich bis jetzt nur mit der CPU 318 machen müssen.

da mir noch nie eine "echte" 400er begegnet ist: machen die Dinger alle diesen Fehler?


----------



## IBFS (9 Juni 2008)

Perfektionist schrieb:


> diese Erfahrung hab ich bis jetzt nur mit der CPU 318 machen müssen.
> 
> da mir noch nie eine "echte" 400er begegnet ist: machen die Dinger alle diesen Fehler?


 


das ist doch kein Fehler  es gibt nunmal keine Nachkommastelle!!!
Das sind ganz normal "Auf" oder ggf. auch "Ab"-Rundungsfehler - also
völlig normal.

Gruß


P.S. Für einen "Kleinmaschinenprogrammierer" ist der S5-Timer ggf. ausreichend 



.


----------



## HeizDuese (9 Juni 2008)

Stollentroll schrieb:


> S5Timer kennt jeder, kann jeder!
> 
> Was braucht man mehr?



Das ist ja das Problem: *MEHR !!!   *


----------



## bike (10 Juni 2008)

IBFS schrieb:


> P.S. Für einen "Kleinmaschinenprogrammierer" ist der S5-Timer ggf. ausreichend
> 
> 
> .


 

Gut, dass wir dich haben, den Grossmaschinen Programmierer.

bike

P.S. Was sind denn Kleinmaschinen?


----------



## bike (10 Juni 2008)

HeizDuese schrieb:


> Das ist ja das Problem: *MEHR !!!   *


 

Stimmt*ACK*


----------



## Perfektionist (10 Juni 2008)

IBFS schrieb:


> ...
> das ist doch kein Fehler  es gibt nunmal keine Nachkommastelle!!!
> Das sind ganz normal "Auf" oder ggf. auch "Ab"-Rundungsfehler - also
> völlig normal.
> ...


 ach so, ich vergas: die 318 rundet grundsätzlich auf. Auch wenn nur der OB1 läuft, mit nichts als Inhalt, als dem Befehl "L #OB1_prev_cycle", so sieht man im Status den Wert 1 
bei den anderen "Klein"steuerungen kann ich den OB1_prev_cycle aufsummieren, solange ich will, da konnte ich zu einer Referenzuhr bislang keinen Unterschied feststellen (auch nicht zu SFC64). Jetzt wollte ich nur wissen, ob alle "Groß"steuerungen (deren kleinster Vertreter die 318 ist) diesen Fehler aufweisen.


----------



## IBFS (10 Juni 2008)

bike schrieb:


> Gut, dass wir dich haben, den Grossmaschinen Programmierer.
> 
> bike
> 
> P.S. Was sind denn Kleinmaschinen?


 


Erstens war das ein Witz .. da oben

Zweitens:

Wenn man größere Programmteile wiederverwenden und vor allem
in einem neuen Programm zusammenführen will, ist es total nervig 
ggf. 200-300 Timer umzusortieren. 

In eine "kleinen" Maschine mit vielleicht 20 -30 Timern ist aber
durchaus ok. 

Ich bin nun definitiv kein Codesys-Fan, aber bei Codesys muß
man eben ganichts umsortieren wegen der Instanziierung.
Es bisschen von diesen Vorteilen kann man sich durchaus
in die STEP7 - Welt "herüberholen".


Gruß


----------



## Perfektionist (10 Juni 2008)

IBFS schrieb:


> ...
> Bespiel:
> 
> gewünschte Zeit: 30 Sekunden ==>
> ...


 dann korrigiere ich halt mal diese Aussage. Während der dreissig Sekunden macht die 317 bei echter Zykluszeit 2,55ms insgesamt 11764 Zyklendurchläufe. Während dieser Zeit wechselt #OB1_PREV_CYCLE zwischen 2 und 3, und zwar zeigt diese Startinformation 5291mal zwei und 6473mal drei. was dann aufsummiert 30,001s gibt.


----------



## IBFS (10 Juni 2008)

Perfektionist schrieb:


> dann korrigiere ich halt mal diese Aussage. Während der dreissig Sekunden macht die 317 bei echter Zykluszeit 2,55ms insgesamt 11764 Zyklendurchläufe. Während dieser Zeit wechselt #OB1_PREV_CYCLE zwischen 2 und 3, und zwar zeigt diese Startinformation 5291mal zwei und 6473mal drei. was dann aufsummiert 30,001s gibt.


 

...wenn es so sein sollte gut, aber wenn die Zykluszeit in jedem Zyklus
aufgerundet wird (es sein den die "abschnittenen" Rest in der CPU werden
irdenwie "aufgehoben" und "nachgenutzt") summieren sich doch die Fehler
mehr und mehr, oder?!

Gruß


----------



## Perfektionist (10 Juni 2008)

Genau da liegt das Problem, das ich mit der 318er habe: die rundet grundsätzlich auf (auch 0,1ms ergibt dann 1ms). Die anderen Kleinsteuerungen der dreihunderter-Reihe tun genau das Richtige: nämlich den "abgeschnittenen Rest aufheben und nachnutzen".
In Wirklichkeit wird es sich wohl um einen Interrupt handeln, der alle ms statt findet und einen Zeitzähler weiter zählt. Und am Zykluskontrollpunkt vergleicht dann die CPU den aktuellen Zeitzählerstand mit dem Zeitzählerstand des letzten Zyklus und berechnet aus der Differenz die Dauer des letzten Zyklus.


----------

