maximal zulässige Zykluszeit?

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 :
Code:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... 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
 
@Larry: Dann sind wir ja schon zwei! ;)
@Nichtskönner:
Zum Thema ein einfaches Beispiel...
Code:
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! :rolleyes:

Gruß Approx
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mahlzeit,

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! :rolleyes:

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?
 
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ß
 
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 ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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
 
... 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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 

Anhänge

  • konfi.jpg
    konfi.jpg
    21 KB · Aufrufe: 34
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ß
 
Das war nur um sofort festzustellen ob die MPs nicht am bus sind. Ansonsten machen die dinger nichts.

:rolleyes: ... 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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
@Larry: Dann sind wir ja schon zwei! ;)
@Nichtskönner:
Zum Thema ein einfaches Beispiel...
Code:
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! :rolleyes:

Gruß Approx

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
 
Zurück
Oben