# maximal zulässige Zykluszeit?



## Nichtskönner (26 Januar 2010)

hallo


Gibt es in der Automatisierungstechnik eine maximal zulässige Zykluszeit?

Wenn ja, wie ist diese und wo steht das geschrieben?


danke und gruß


----------



## Waelder (26 Januar 2010)

Was meinst du mit Zykluszeit ?
Die in der CPU oder die eines Arbeitstaktes (einer Maschine) oder so á la Echtzeitverarbeitung ?
Meine Lösung wäre :
CPU = keine maximale Zykluszeit, so lang dein Prozess vernünftig läuft. Aber die Begrenzung der Zykluszeit in den Eigenschaften des Projekts ist standart glaub ich 150ms. Also über 150ms wird´s die CPU stoppen
aus der Hilfe S7 :

```
Mindestzykluszeit
Nicht relevant für S7-300.
Bei S7-400: Mit der Mindestzykluszeit bestimmen Sie, in welchem Zeitabstand das CPU-Programm aufgerufen wird.
Ist die Zykluszeit kürzer als die eingegebene Mindestzykluszeit, dann wartet die CPU so lange, bis die Mindestzykluszeit erreicht ist. In dieser zusätzlichen Programmbearbeitungszeit bearbeitet die CPU den OB 90 (Hintergrund-OB), falls er geladen ist.
```
Arbeitstakt = gibt der Kunde vor (hoffentlich reelle zeiten und nicht utopische) da kann deine Zykluszeit in der CPU eine grosse rolle spielen. Bei positionieraufgaben oder schnellen abfolgen kann das schon beeinträchtigen.
Echtzeit ? = schau mal unter http://de.wikipedia.org/wiki/Echtzeit

Gruss Wälder


----------



## knarf (27 Januar 2010)

Hallo,
bei fehlersicheren Steuerungen gibt es eine maximal mögliche Zykluszeit. Die zweifache Zykluszeit darf nicht größer als die Prozeßsicherheitszeit sein. Die Prozeßsicherheitszeit ist die Zeit in der die Anlage sicher in den sicheren Zustand gebracht werden muß und wird bei einer Hazop-Studie oder vom TÜV festgelegt.

Gruß Frank


----------



## Nichtskönner (27 Januar 2010)

es geht mir darum, ob es irgendwie eine vorschrift gibt, in der festgelegt ist, wie hoch die maximale zykluszeit ist.

zykluszeit ist doch die zeit, in der das programm einmal abgearbeitet wird.
die frage ist wie gesagt, ob diese zeit einen bestimmten wert nicht überschreiten darf.


----------



## Approx (27 Januar 2010)

Nichtskönner schrieb:


> es geht mir darum, ob es irgendwie eine vorschrift gibt, in der festgelegt ist, wie hoch die maximale zykluszeit ist.


Ins Blaue geschossene Antwort: NEIN! Bin fast 20 Jahre dabei und habe noch nichts dergleichen gehört. 
Das macht ja auch keinen Sinn, weil:
Die Zykluszeit richtet sich nach dem in der CPU enthaltenen Code. Dieser ist je nach Anwendungsfall unterschiedlich lang. Es kann zwar passieren, dass die Abarbeitung des Code zu lange für den Prozess dauert, dann liegts aber entweder am Programmierstil - oder an einer zu schwach ausgelegten Hardware.
Die "Zykluszeitüberwachung" (Objekteigenschaften CPU) ist eher als Schwellwert zu sehen, um fehlerhafte Schleifenprogrammierung oder zeitkritische Anwendungen Grenzen zu setzen..

Meine Meinung.
Gruß Approx


----------



## Larry Laffer (27 Januar 2010)

... ich sehe das so wie Approx. Deine Grenzwerte für eine "vernünftige" Zykluszeit kann hier nur das Reaktions-Verhalten deines Programms definieren. Irgend wann kommt man mit der Zykluszeit in einen Bereich, wo Anhaltevorgänge nicht mehr sauber funktionieren oder der Anlagentakt selbst nicht mehr deinen Anforderungen genügt.

Ich versuche bei meinen Anlagen gerne die (normale) Zykluszeit deutlich unter 20ms zu halten - das heißt aber nicht, dass es nicht Berechnungs- oder Auswerte-Zyklen gibt in denen die Zykluszeit nicht weit über 500ms geht. Das ist dann aber berücksichtigt ...

Gruß
LL


----------



## Nichtskönner (27 Januar 2010)

gut gut, dann danke ich mal für die interessanten antworten


gruß


----------



## Approx (27 Januar 2010)

@Larry: Dann sind wir ja schon zwei! 
@Nichtskönner:
Zum Thema ein einfaches Beispiel...
	
	



```
UN E 1.0 "MOTOR AUS" // Öffnerkontakt Motor ausschalten
R A 10.0 "SCHÜTZ M1" // Ausgang für Schützansteuerung
```
Wenn der Taster zufällig gerade dann betätigt wird, wenn der aktuelle Zyklus gerade an diesen Zeilen "vorbeigegangen ist", dann bekommt die CPU dies in diesem Zyklus nicht mehr mit. Meistens dann im nächsten Zyklus, weil man ja nicht nur den Taster im Millisekundenbereich betätigt. Wenn die Zykluszeit nun soooo lang ist, dass man schon wieder den Taster losgelassen hat - tja dann ist Essig! 

Gruß Approx


----------



## Amson (27 Januar 2010)

Mahlzeit,



Approx schrieb:


> Wenn der Taster zufällig gerade dann betätigt wird, wenn der aktuelle Zyklus gerade an diesen Zeilen "vorbeigegangen ist", dann bekommt die CPU dies in diesem Zyklus nicht mehr mit. Meistens dann im nächsten Zyklus, weil man ja nicht nur den Taster im Millisekundenbereich betätigt. Wenn die Zykluszeit nun soooo lang ist, dass man schon wieder den Taster losgelassen hat - tja dann ist Essig!
> 
> Gruß Approx


 

und was könnte ich machen, wenn in meiner Anlage so etwas ab und an vorkommt? Handelt sich in meinem Fall um einen Starttaster.... gibt es die Möglichkeit die Zykluszeit neu zu starten?


----------



## Approx (27 Januar 2010)

Amson schrieb:


> Mahlzeit,
> und was könnte ich machen, wenn in meiner Anlage so etwas ab und an vorkommt? Handelt sich in meinem Fall um einen Starttaster.... gibt es die Möglichkeit die Zykluszeit neu zu starten?


Naja, also erst einmal glaube ich, daß ein Tasterbefehl nicht unbedingt <100ms ansteht. Wenn die Zykluszeit in deiner Anlage aber schon in der Größenordnung >500ms liegt - dann kann sowas durchaus schon mal passieren. Also erstmal nachschauen, ob die Zykluszeit überhaupt solche Größenordnungen erreicht. Manchmal hängen die Taster auch an einer ET200M und diese wiederum am Profibus. Da spielen dann die Bus-Zyklen wieder eine Rolle (abpollen der DP-Teilnehmer...).
Eine Möglichkeit, den OB1-Zyklus neu zu starten gibt es nicht.

Gruß


----------



## Waelder (27 Januar 2010)

ahh Buszyklus da steig ich mal ein. Da hats mich neulich erwischt, an einem ewig langen Profibus mit vielen Busteilnehmern (ET200s). 
Da waren einige Laufmeldungen von Bändern. Eben wie gesagt die SPS hats erst später erfasst. Der doofe INI hat immer genau von auf 1 oder 0 und wieder auf 1 geschaltet usw. wenn der Teilnehmer grad nicht abgefragt wurde, so dass die SPS das über einige zeit immer als stetiges 0 oder 1 signal annahm. Fakto Fehler
Wie bekomm ich denn die Buszykluszeit hoch ? Ohne die Busfreq. grösser 1,5mbt zu setzen ?


----------



## Larry Laffer (27 Januar 2010)

@Waelder:
wieviele Teilnehmer welcher Art hast du denn so an deinem PB ?
Hängen da auch Bediengeräte dran ?

@Amson:
du könntest z.B. im OB35 mit einem schnelleren Takt das Prozess-Abbild zwischen-aktualisieren und so einen Eingang dann auf einen Merker leiten (S), damit das Rest-Programm ihn mitbekommt.

Gruß
LL


----------



## Waelder (27 Januar 2010)

Ja 3 MPs

6xET200S
3xMP277
3xWaage
1xLaserdistanzmessung
1xDP/DP Koppler
einige repeater....


----------



## Larry Laffer (27 Januar 2010)

... dann mach doch mal für die Bediengeräte einen Extra Strang auf. Die sind (nach meiner Meinung bei der beschriebenen Konstellation) die Haupt-Spitzbuben ...

Gruß
LL


----------



## Waelder (27 Januar 2010)

Schwierig.... weil die Verkabelung es wahrscheinlich nicht möglich macht. Einfach nur "rausnehmen" aus der HW Konfi wird wohl nicht genügen :-(
Die sind da nämlich verankert. Prinzipiell brauch eich die da nicht eingefügt. Das war nur um sofort festzustellen ob die MPs nicht am bus sind. Ansonsten machen die dinger nichts.


----------



## Approx (27 Januar 2010)

Vielleicht lohnt sich der bei entsprechender Topologie mit langen Leitungen auch der Einsatz von Diagnose-Repeatern (einer je 100m Cu-Länge). Mit den Dingern kommt man auch ewaigen Fehlern auf die Spur und man kann den Bus schön segmentieren. Sind aber preislich nicht gerade ein Schnapp!
Gruß


----------



## Larry Laffer (27 Januar 2010)

Waelder schrieb:


> Das war nur um sofort festzustellen ob die MPs nicht am bus sind. *Ansonsten machen die dinger nichts*.


 
 ... der letzte Satz ist genau der Punkt ...
Die Bediengeräte sind erstmal PB-Master - das ist der erste Knaxus.
Des weiteren bomben die dir deinen PB mit ihrer B&B-Kommunikation (Bedienen und Beobachten) ganz schön zu.
Wenn du also Schwierigkeiten hast dann solltest du den Punkt mal überlegen oder vielleicht die Dinger einfach mal abhängen vom Bus um dann zu sehen, wie es mit deiner Bus-Performance dann bestellt ist ...

Gruß
LL


----------



## Waelder (27 Januar 2010)

grinss . . . abhängen würd ich gern aber dann bekomm ich mächtig ärger mit den LKW fahrern die die Panels Bedienen. Ich werd vorerst mal die Panels via HW Konfi vom Bus nehmen. z.Thema Panel Bus Master. Das ist explizit abgehakt. Weil da hatten wir mal probleme mit.
Demnächst muss ich mal auf die Anlage, ich werd dann mal berichten.


----------



## Amson (27 Januar 2010)

Larry Laffer schrieb:


> @Amson:
> du könntest z.B. im OB35 mit einem schnelleren Takt das Prozess-Abbild zwischen-aktualisieren und so einen Eingang dann auf einen Merker leiten (S), damit das Rest-Programm ihn mitbekommt.


 
Ich werde das mal mit dem "Setzen" probieren.

Danke fürs erste.

der Amson


----------



## Woldo (27 Januar 2010)

Approx schrieb:


> @Larry: Dann sind wir ja schon zwei!
> @Nichtskönner:
> Zum Thema ein einfaches Beispiel...
> 
> ...


 
Approx,

Da im Simatic-Forum gefragt wurde ist die Erklärung nach meiner Meinung falsch. Die S5 und die S7 arbeiten mit PAE, die Eingänge werden immer am Beginn eines Zyklus eingelesen. Wenn der Zustand der Eingänge nicht durch das Programm manipuliert wird, bleiben diese für den gesamten Zyklus gleich. Der Effekt, dass kurze Signale eventuell "verloren" gehen ist zwar der gleiche, jedoch hat dies nichts damit zu tun, an welcher Stelle das Programm beim Eingangssignalwechsel bearbeitet wurde.

Gruß
Woldo


----------



## Heinz (27 Januar 2010)

Vorschlag um die Buslaufzeiten zu verringern 

Lade die Eingänge im Zeit OB mit dem SFC14/15 und kopiere die Daten.

Überprüfe ob die Aktualisierungszyklen des OP's vergrößert werden können.



@Approx

Wenn der Taster zufällig gerade dann betätigt wird, wenn der aktuelle Zyklus gerade an diesen Zeilen "vorbeigegangen ist", dann bekommt die CPU dies in diesem Zyklus nicht mehr mit. Meistens dann im nächsten Zyklus, weil man ja nicht nur den Taster im Millisekundenbereich betätigt. Wenn die Zykluszeit nun soooo lang ist, dass man schon wieder den Taster losgelassen hat - tja dann ist Essig! 

Gruß Approx

Das PAE wird am Anfang des SPS Zyklus aktualisiert, Daher muss im OP die aktualisierung mit dem PEW erfolgen.....


----------



## Paule (27 Januar 2010)

Woldo schrieb:


> Die S5 und die S7 arbeiten mit PAE, die Eingänge werden immer am Beginn eines Zyklus eingelesen. Wenn der Zustand der Eingänge nicht durch das Programm manipuliert wird, bleiben diese für den gesamten Zyklus gleich. Der Effekt, dass kurze Signale eventuell "verloren" gehen ist zwar der gleiche, jedoch hat dies nichts damit zu tun, an welcher Stelle das Programm beim Eingangssignalwechsel bearbeitet wurde.


Hi Woldo und Heinz,
ich bin mir absolut sicher, Approx weiß dass das PAE am Zyklusanfang eingelesen wird.
Und genau so habe ich Ihn auch verstanden. PAE wird eingelesen und jetzt wird der Taster betätigt.


Approx schrieb:


> Wenn der Taster zufällig gerade dann betätigt wird, wenn der aktuelle Zyklus gerade an diesen Zeilen "vorbeigegangen ist", dann bekommt die CPU dies in diesem Zyklus nicht mehr mit.


Und auch wenn es den Perfekten wieder aufregt wenn ich jetzt gleich wieder fett schreibe. 
Darum hat Approx das *"vorbeigegangen"* ja auch in Hochkommas gestellt. 
Aber das wäre mal was wenn der Zyklus durchs Programm schlendert und schaut was er jetzt machen soll.


----------



## rostiger Nagel (27 Januar 2010)

*Dieser Zyklus fliegt bald!*



Paule schrieb:


> Aber das wäre mal was wenn der Zyklus durchs Programm schlendert und schaut was er jetzt machen soll.



wenn dieser Zyklus nicht langsam in die Pötte kommt, würde
ich den abmahnen und eine fette CPU zum antreiben auf den
Hals hetzen...wo sind wir den hier kann ja nich jeder machen
was er will.


----------



## Paule (27 Januar 2010)

Helmut_von_der_Reparatur schrieb:


> wenn dieser Zyklus nicht langsam in die Pötte kommt, würde
> ich den abmahnen und eine fette CPU zum antreiben auf den
> Hals hetzen...wo sind wir den hier kann ja nich jeder machen
> was er will.


*ROFL* Absolut Helmut *ACK*


----------



## Approx (28 Januar 2010)

Woldo schrieb:


> Approx,
> 
> Da im Simatic-Forum gefragt wurde ist die Erklärung nach meiner Meinung falsch. Die S5 und die S7 arbeiten mit PAE, die Eingänge werden immer am Beginn eines Zyklus eingelesen. Wenn der Zustand der Eingänge nicht durch das Programm manipuliert wird, bleiben diese für den gesamten Zyklus gleich. Der Effekt, dass kurze Signale eventuell "verloren" gehen ist zwar der gleiche, jedoch hat dies nichts damit zu tun, an welcher Stelle das Programm beim Eingangssignalwechsel bearbeitet wurde.
> 
> ...


Philosophisch betrachtet:
Nehmen wir doch mal an, so ein Zyklus dauert 1 Jahr!
Dann wird am 1. Januar die Peripherie eingelesen, und am 31.12. ausgegeben. Wenn die betreffenden Codezeilen nun am 17.März abgefragt werden - das Tastersignal aber nur vom 4.September bis 19. November ansteht -dann ist nix mit Funktion...

Jetzt Klick? 

Gruß Approx


----------



## rostiger Nagel (28 Januar 2010)

Approx schrieb:


> Nehmen wir doch mal an, so ein Zyklus dauert 1 Jahr!


 
dann hast du aber als CPU einen kleinen Chinesen mit Abakus


----------



## Approx (28 Januar 2010)

Wäre dem so, dann müsste die Peripherie ja beim chinesischen Jeujahrsfest eingelesen werden! Dieses wiederum fällt ja variabel - was das Programmieren wieder schwieriger macht... 
loool


----------



## rostiger Nagel (28 Januar 2010)

Approx schrieb:


> Wäre dem so, dann müsste die Peripherie ja beim chinesischen Jeujahrsfest eingelesen werden! Dieses wiederum fällt ja variabel - was das Programmieren wieder schwieriger macht...
> loool


 
den unterschiedlichen Zeitpunkt des Festes würde mann ja schon
hinbekommen, schlimmer ist es, das die CPU besoffen ist


----------



## crash (28 Januar 2010)

Approx schrieb:


> Philosophisch betrachtet:
> Nehmen wir doch mal an, so ein Zyklus dauert 1 Jahr!
> Dann wird am 1. Januar die Peripherie eingelesen, und am 31.12. ausgegeben. .......





Helmut_von_der_Reparatur schrieb:


> ...... schlimmer ist es, das die CPU besoffen ist



*Das* würde ja bedeuten dass die CPU bei *jeder *
Prozessabbildaktualisierung *besoffen* *ist*.*ROFL*

*jetzt* wird mir einiges *klar*...


----------



## Approx (28 Januar 2010)

crash schrieb:


> *Das* würde ja bedeuten dass die CPU bei *jeder *
> Prozessabbildaktualisierung *besoffen* *ist*.*ROFL*
> 
> *jetzt* wird mir einiges *klar*...


Da dieser Thread nun völlig zum Witze-Possenreißer-Feierabend-Thread verblendet wurde:
Bereits Charles Darwin wusste, was zyklisches Erbrechen war. Ob der werte Herr schon besoffene CPU's mit kleinen, chinesischen Männchen und Abakus kannte? Man weiß es nicht!


----------



## Bernard (28 Januar 2010)

*schlimmer ist es, das die CPU besoffen ist*

Also diese besoffenen CPU`s finde ich interessant.
Die würden sehr gut zu einer Anlage passen die ich programmieren soll.
Deshalb ein paar Fragen:
1) Welche Bestellnummer
2)Wieviel saufen die am Tag
3)was saufen die (Spiritus ,Cognac,Korn etc..?)
4) wo füllt man den Stoff ein
5)muß man selbst besoffen sein um sie zu proggen

Für Informationen währe ich sehr dankbar.


Viele Grüße Bernard


----------



## Approx (28 Januar 2010)

Zu 1.) Alle CPU's mit einem *'F' *hintendran, also 416*-F*, 317*-F *sind sogenannte 'FUSEL'-CPU's!! Diese laufen mit Hochprozentigem aller Art.
Zu 2. u. 3.) das musst Du den kleinen Chinesen auf der Platine fragen...
Zu 5.) jepp!


----------



## Woldo (28 Januar 2010)

Approx schrieb:


> Philosophisch betrachtet:
> Nehmen wir doch mal an, so ein Zyklus dauert 1 Jahr!
> Dann wird am 1. Januar die Peripherie eingelesen, und am 31.12. ausgegeben. Wenn die betreffenden Codezeilen nun am 17.März abgefragt werden - das Tastersignal aber nur vom 4.September bis 19. November ansteht -dann ist nix mit Funktion...
> 
> ...


 
Hallo Approx,

volle Zustimmung. Deshalb war ja deine Erklärung in #8 eigentlich Käse, da es eben egal ist ob der Taster vor oder nach deinen Codezeilen betätigt wurde. Interessant ist der Signalzustand des Eingangs am "1.Januar".

Gruß

Woldo


----------



## Approx (28 Januar 2010)

@Woldo:
Janee, is klar! :s17:
Es geht doch um Signallaufzeiten innerhalb des Zyklus. Wenn die Zykluszeit der CPU nun beispielsweise 400 Millisekunden beträgt und das Tastersignal nur für 40 Millisekunden an beliebiger Stelle (aber nach dem in #8 geposteten Code) im Zyklus ansteht - wann wird nun Deiner Meinung nach das Peripherieabbild dieses Signal erfassen? Mein Beispiel mit dem Jahr kam nicht von ungefähr. 

 Appro


----------



## crash (28 Januar 2010)

Immer wieder herrlich diese Grundsatzdiskussionen.


----------



## crash (28 Januar 2010)

*Übrigends*

...und lasst das hier bitte nicht ausarten wie in gewissen anderen Threads.
Ich zähl auf Euch.


----------



## Woldo (28 Januar 2010)

Approx schrieb:


> @Woldo:
> Janee, is klar! :s17:
> Es geht doch um Signallaufzeiten innerhalb des Zyklus. Wenn die Zykluszeit der CPU nun beispielsweise 400 Millisekunden beträgt und das Tastersignal nur für 40 Millisekunden an beliebiger Stelle (aber nach dem in #8 geposteten Code) im Zyklus ansteht - wann wird nun Deiner Meinung nach das Peripherieabbild dieses Signal erfassen? Mein Beispiel mit dem Jahr kam nicht von ungefähr.
> 
> Appro


 
Hallo Approx,

dass das Eingangssignal nicht zuverlässig ausgewertet werden kann, wenn bei einer Zykluszeit von 400ms das Signal nur 40ms ansteht, ist klar. Es ist aber egal ob das Signal vor oder nach dem in #8 geposteten Code für 40 ms ansteht. Das PAE wird am Anfang des Zyklus eingelesen und bleibt für diesen gesamten Zyklus gleich, ausser man überschreibt einen Eingang an irgend einer Stelle im Programm (z.B. mit SET S E24.5). Dass das manipulieren von Eingängen im SPS-Programm möglich ist, ist aber eine andere Baustelle.

Gruß Woldo


----------



## Question_mark (28 Januar 2010)

*Über was wird denn hier diskutiert ??*

Hallo,



			
				woldo schrieb:
			
		

> dass das Eingangssignal nicht zuverlässig ausgewertet werden kann, wenn bei einer Zykluszeit von 400ms das Signal nur 40ms ansteht, ist klar.



Gut, dem kann ich ohne weiteres zustimmen. Wenn allerdings eine SPS eine Zykluszeit wie die von Dir zitierten 400ms hat, ist doch wohl schon irgendwas im Vorfeld bei der Projektierung schiefgelaufen.



			
				woldo schrieb:
			
		

> Das PAE wird am Anfang des Zyklus eingelesen und bleibt für diesen gesamten Zyklus gleich



Ja, ist richtig. Du musst jetzt nur dafür sorgen, dass der Taster beim Einlesen des PAE auch betätigt ist. Vielleicht versteht Du jetzt, was Approx mit seinem Beitrag #8 richtig festgestellt hat 



			
				woldo schrieb:
			
		

> ist aber eine andere Baustelle.



Auch richtig. Aber warum hast Du dann überhaupt diese Option erwähnt ?

Und dann ganz nebenbei meine persönliche Definition von *maximal zulässiger Zykluszeit* : Das ist die Zykluszeit, mit der meine SPS immer und jederzeit unter Berücksichtigung aller Aspekte und Anforderungen an den Prozeß, Funktion und *Sicherheit* zuverlässig funktioniert. Da können schon 10ms zu viel sein, aber manchmal auch 200ms durchaus ausreichen. 

Also was bitte soll eine Diskussion über eine max. zulässige Zykluszeit, das muss doch immer individuell bewertet werden 

Gruß

Question_mark
Gruß


----------



## Approx (29 Januar 2010)

@QM: *ACK*
Ich glaube, woldo hat einfach nur nicht ganz verstanden, was ich Eingangs meinte... War wohl eher ein didaktischer Mangel meinerseits.
Eigentlich sind wir hier alle einer Meinung, was die *maximale Zykluszeit* anbelangt.  
QM hat es ja gut auf den *Punkt* gebracht.
Gruß


----------



## Larry Laffer (29 Januar 2010)

@Approx:
... sein nicht traurig - auch für dich wird die Sonne eines Tages wieder scheinen ... 
Ich fand deine Erklärung übrigens gut und schlüssig ...


----------



## Approx (29 Januar 2010)

> @Approx:
> ... sein nicht traurig - auch für dich wird die Sonne eines Tages wieder scheinen ... :wink:
> Ich fand deine Erklärung übrigens gut und schlüssig ... :smile:


@LL: Dann lies mal meine Postings quer - ich bin ein witzesprühendes Ungeheuer! Mir scheint die Sonne aus dem Arsch! ROFLMAO

Hehe.
Gruß Approx


----------



## AliBaba (29 Januar 2010)

*max Zykluszeit*

Eigentlich war die Frage doch nach einer max Zykluszeit :



Nichtskönner schrieb:


> es geht mir darum, ob es irgendwie eine vorschrift gibt, in der festgelegt ist, wie hoch die maximale zykluszeit ist.
> 
> zykluszeit ist doch die zeit, in der das programm einmal abgearbeitet wird.
> die frage ist wie gesagt, ob diese zeit einen bestimmten wert nicht überschreiten darf.


 

Zumindest in der S7-400 wird in der HW-Konfig eine max Zykluszeit angegeben, nach der die SPS in Stop geht.


----------



## Woldo (29 Januar 2010)

Approx schrieb:


> @QM: *ACK*
> Ich glaube, woldo hat einfach nur nicht ganz verstanden, was ich Eingangs meinte... War wohl eher ein didaktischer Mangel meinerseits.
> Eigentlich sind wir hier alle einer Meinung, was die *maximale Zykluszeit* anbelangt.
> QM hat es ja gut auf den *Punkt* gebracht.
> Gruß


 
Hallo Approx,

ich habe aus deinen Posts immer herausgelesen, dass du glaubst es macht einen Unterschied, ob der Eingangssignalwischer vor oder nach deinen Zeilen aus #8 ansteht. Ich wollte dich nur darauf hinweisen, dass dies definitiv nicht so ist. Damit sollte das Thema durch sein.

Gruß Woldo


----------



## vierlagig (29 Januar 2010)

Woldo schrieb:


> Hallo Approx,
> 
> ich habe aus deinen Posts immer herausgelesen, dass du glaubst es macht einen Unterschied, ob der Eingangssignalwischer vor oder nach deinen Zeilen aus #8 ansteht. Ich wollte dich nur darauf hinweisen dass dies definitiv nicht so ist. Damit sollte das Thema durch sein.
> 
> Gruß Woldo



wenn direkt auf peripheriewerte zugegriffen wird, dann ja, dann ist sogar das so ... also nicht so wirklich "definitiv"


----------



## Woldo (29 Januar 2010)

vierlagig schrieb:


> wenn direkt auf peripheriewerte zugegriffen wird, dann ja, dann ist sogar das so ... also nicht so wirklich "definitiv"


 
schau dir #8 an, es wird nicht auf PEW zugegriffen.


----------



## Approx (29 Januar 2010)

AliBaba schrieb:


> Zumindest in der S7-400 wird in der HW-Konfig eine max Zykluszeit angegeben, nach der die SPS in Stop geht.


Dies ist in den meisten Fällen der Siemens-Default-Wert von 150ms. Den kann man beliebig rauf-, oder runtersetzen (wenn es Sinn macht). Die Frage des Threadstarters diesbezüglich ging ja in die Richtung "gesetzliche Vorschriften".

Gruß


----------



## Fragnurmal (29 Januar 2010)

*Nich direkt*



Nichtskönner schrieb:


> hallo
> 
> 
> Gibt es in der Automatisierungstechnik eine maximal zulässige Zykluszeit?
> ...


 
Die Maximale Zykluszeit ist nur durch die Einstellmöglichkeiten in der Hardwareconfig und durch die in dem Programm gestellten Anforderungen (z.B. TÜV-Vorgaben) begrenzt.

Alleine durch das verwenden von Fehler-OB´s kann es unter Umständen zu längeren Zykluszeiten kommen. Die Frage wie lange ein Zyklus dann dauern darf (Abgesehen von zwingenden vorgaben, siehe oben) legt der Programmierer fest.


----------



## Fragnurmal (29 Januar 2010)

Amson schrieb:


> Mahlzeit,
> 
> 
> 
> ...


 
Also das höre ich zum ersten mal ^^
Stell dier vor du läufst.
Immer ein Fuß (zyklus) vor den anderen.
Die einzige Möglichkeit das neu zu starten wäre also dir ein Bein zustellen.
Das hätte zur folge das du hinfällst und dich ärgerst (CPU-STOP). ^^
Nachdem du wieder loßläufts (Neustart) fängt ein neuer zyklus an.

Würd ich nicht machen.


----------



## crash (29 Januar 2010)

Amson schrieb:


> Mahlzeit,
> 
> 
> 
> ...





Fragnurmal schrieb:


> Also das höre ich zum ersten mal ^^
> Stell dier vor du läufst.
> Immer ein Fuß (zyklus) vor den anderen.
> Die einzige Möglichkeit das neu zu starten wäre also dir ein Bein zustellen.
> ...



Dann schau dir doch bitte mal den SFC 43 "RE_TRIGR" an.


> Mit der SFC 43 "RE_TRIGR" (retrigger watchdog) starten Sie die
> Zykluszeitüberwachung der CPU neu.


----------



## Fragnurmal (29 Januar 2010)

*Hallo*



crash schrieb:


> Dann schau dir doch bitte mal den SFC 43 "RE_TRIGR" an.


 
Hmm... Ist das auch sinnvoll ? Immerhin ist das ne Überwachungszeit. 
Angenommen ich hab da ein paar fehler OB´s laufen ... in diesen läuft ein code der mir zb. die ursache zwischenspeichert .
Aus irgendeinem grund wird so´n OB jetzt so oft aufgerufen das die Zykluszeit überschritten wird. Sollte ich die dann neu starten ? ... oder lieber nach dem Problem suchen ?


----------



## crash (29 Januar 2010)

Fragnurmal schrieb:


> Hmm... Ist das auch sinnvoll ? Immerhin ist das ne Überwachungszeit.
> Angenommen ich hab da ein paar fehler OB´s laufen ... in diesen läuft ein code der mir zb. die ursache zwischenspeichert .
> Aus irgendeinem grund wird so´n OB jetzt so oft aufgerufen das die Zykluszeit überschritten wird. Sollte ich die dann neu starten ? ... oder lieber nach dem Problem suchen ?



Die Funktion ist sicherlich nicht dazu gedacht ständig die Überwachungszeit
neu zu starten um irgendwelche Probleme zu kaschieren.


----------



## Fragnurmal (29 Januar 2010)

crash schrieb:


> Die Funktion ist sicherlich nicht dazu gedacht ständig die Überwachungszeit
> neu zu starten um irgendwelche Probleme zu kaschieren.


 
Wozu dann ? Hast du ein Beispiel wo man das braucht ?


----------



## MSB (29 Januar 2010)

Fragnurmal schrieb:


> Wozu dann ? Hast du ein Beispiel wo man das braucht ?



Brauchen könnte man das bei allem was nur ab und zu mal passieren soll,
z.B. 1x pro Tag eine aufwändige Schleife um Messwerte auszuwerten.

Keine Ahnung, aber sicherlich ist eine derartige Funktion nich für ständige Verwendung gedacht,
dann könnte man auch einfach die Zeit in der HW-Konfig ändern.


Lezten Endes ist das aber auch alles egal, denn wenn eine Zykluszeit mal so lang ist, das noch
nicht mal mehr ein normaler Tastendruck erkannt wird, dann ist da sowieso ne ganze Menge schiefgelaufen.
Und selbst das RE-Trigger würde das PAE nicht neu einlesen ...

Ich habe bisher eigentlich nur Bekanntschaft mit der Zykluszeitüberwachung gemacht,
wenn mal wieder ein Tippfehler bei einer Sprungmarke war.

Mfg
Manuel


----------



## Fragnurmal (29 Januar 2010)

MSB schrieb:


> ...
> 
> Ich habe bisher eigentlich nur Bekanntschaft mit der Zykluszeitüberwachung gemacht,
> wenn mal wieder ein Tippfehler bei einer Sprungmarke war.
> ...


 
Geht mir auch so ^^
Und Kritische Taster kann man auch noch über ein zb OB35 auslesen. Hab aber auch das noch nie gebraucht. Zeitaufwändige Berechnungen oder sonst etwas was länger als ne secunde dauert sollte man eh nur in der sps machen wenn der PC-Programmierer zu faul ist ^^


----------



## crash (29 Januar 2010)

MSB schrieb:


> Brauchen könnte man das bei allem was nur ab und zu mal passieren soll,
> z.B. 1x pro Tag eine aufwändige Schleife um Messwerte auszuwerten.
> 
> Keine Ahnung, aber sicherlich ist eine derartige Funktion nich für ständige Verwendung gedacht,
> dann könnte man auch einfach die Zeit in der HW-Konfig ändern.



*ACK*
Füllzeichen


----------



## Fragnurmal (29 Januar 2010)

*Garanteirte überschreitung der ZYKLUSZEIT*

http://www.spsforum.de/showpost.php?p=240601&postcount=11


----------



## Paule (30 Januar 2010)

crash schrieb:


> Die Funktion ist sicherlich nicht dazu gedacht ständig die Überwachungszeit
> neu zu starten um irgendwelche Probleme zu kaschieren.


 


Fragnurmal schrieb:


> Also das höre ich zum ersten mal ^^
> Stell dier vor du läufst.
> Immer ein Fuß (zyklus) vor den anderen.
> Die einzige Möglichkeit das neu zu starten wäre also dir ein Bein zustellen.
> ...


 


Fragnurmal schrieb:


> Wozu dann ? Hast du ein Beispiel wo man das braucht ?


 
Stell Dir vor Du läufst zur Kneipe, wie sagst Du? Ein Fuß vor den anderen. 
Jetzt ruft Dir die Frau hinterher, dass Du den Haustürschlüssel vergessen hast, da Sie ja weiß, es wird wieder mal später.
Jetzt gibt es zwei Möglichkeiten: 
Du gehst zurück und holst den Schlüssel, sprich Endlosschleife, Deine Kuppel sind sauer weil Du so spät kommst, also kompletter Absturz.
Besser Du bleibst stehen, triggerst die Zykluszeit neu und wartest bis die Frau Dir den Schlüssel gebracht hat. 
Sparst einen Weg, bist nicht so kaputt und Deine Kuppel müssen nicht so lange warten.


----------



## rostiger Nagel (30 Januar 2010)

Also Paule wenn du erklärst ist das spitze, so langsam
verstehe ich wie ein kleiner Chinese mit Abakus taktet


----------

