Beckhoff SPS "überlasten"

Programmier doch eine 'Forkbomb', also einen Funktionsbaustein der sich 
selbst zweimal aufruft. Mit wenig Code bringst Du den Rechner ziemlich 
schnell an seine Grenze.

Prinzipiell wäre das ja genau das gewünschte Ziel...nur ist doch dan das 
Problem, dass es kein Ende gibt und ich keinen Ausgang mehr setzten kann 
da der Rechner schlicht weg abstürtzt.
Oder kann ich sowas wie einen Überlastungsbaustein kreieren der mir bei 
Absturz einen Ausgang setzten kann?

LG und danke für die schnelle Antwort

Wenn die Steuerung mit CoDeSys (TwinCat) programmiert wird, sollte es in 
der Taskkonfiguration auch eine direkte Anzeige der Taskauslastung 
geben.

Um die Tasks auszulasten reicht auch eine einfache For - Schleife die 
einfach nichts tut

1

for counter := 0 to counterMax by 1 do

2

    ;

3

end_for

Außerdem sollte die Antwortzeit sich auch mit erhöhter Auslastung nicht 
veränndern. - Zumindest mit halbwegs funktionierendem terministischem 
Betriebssystem.

Blub schrieb:
> Zumindest mit halbwegs funktionierendem terministischem

ich kenne zwar das Beckhoff-System nicht. Aber für Deine Forderung 
sollte man eine Warteschleife anhängen, die die Zykluszeit auf x erhöht, 
wobei x so groß sein muß, das es niemals überschritten wird. Von sich 
aus hat eine SPS eine Überwachung, die bei viel zu langer Zykluszeit die 
Ausgänge in fail-safe schaltet. Eine exakte Antwortzeit des Systems ist 
nicht möglich, da nach Betätigen des Eingangs mindestens auf die 
System-Abfrage des Einganges (Prozeßabbild) gewartet werden muß, und das 
bei nichtsynchronem Zyklus. Antwortzeit ist also > 1* und < 2* 
Zykluszeit und muß schneller sein als worst-case des Prozesses.

Danke schonmal für die ganzen "kreativen" Einfälle!
Das mit den Flanken Zählen ist doch ein schönes Beispiel :D
Aber die ganzen Ideen führen doch etwas an mein eingentliches Ziel 
vorbei -.-

Ziel ist es durch ein Aufwendiges Programm mithilfe eines Tastendruckes 
am Eingang X einen Ausgang Y rauszuschreiben.
Überlegung dabei ist, das ein längeres Programm die Zykluszeit 
verlängert und der Ausgang später gesetzt wird.
Als Referenz soll eine 4 Zeilige IF-Anweisung generiert werden.
Es soll allerdings NICHT die SPS bzw. das System zum Abschturz gebracht 
werden.
Was wäre die einfachste und eleganteste Methode dies zu realisieren, in 
form einer geketteten IF, CASE, WHILE oder einer UND Anweisung?
Der Hintergrundgedanke ist ja, dass mit jeder weiteren Programmzeile die 
Zykluszeit beeinflusst wird. Genau dieser Vorgang soll mit einen 
Osziloskop aufgezeichnet und protokolliert werden!

LG Paul

Die Laufzeit eines SPS-Programms ist proportional zur Menge des 
ausgeführten Programmcodes, d. h. du musst ein sehr langes Programm 
schreiben.
Achtung: In der Regel gibt es eine "schnelle" Task und eine "normale" 
Task. Das Handbuch gibt dazu die notwendigen Auskünfte.

Christian Kreuzer schrieb:
> werden meines Wissens einfach Zyklen
> ausgelassen

Exakt.

> und wenn es zu viel ist, dann kannst du ins Stop jagen.

Ja, das dauert aber ganz schön.


> Alles weitere an Verhalten, findet man in der Hilfe und somit kannst du
> dir den Versuch sparen.

Richtig. Der Versuch ist total für den Popes. Offensichtlich ist dem 
Ursprungsposter die Funktion einer SPS völlig unbekannt.


Paul G. schrieb:
> Überlegung dabei ist, das ein längeres Programm die Zykluszeit
> verlängert und der Ausgang später gesetzt wird.

Erstmal Grundlagen lernen und Dokumentation des Systems lesen. Eine SPS 
macht in jedem Zyklus in etwa:

  1.) Alle Eingänge lesen und ins Prozessabbild übernehmen
  2.) Benutzer-Programm ausführen
  3.) Aus dem Prozessabbild alle Ausgänge schreiben.

Und diese drei Dinge werden ständig wiederholt, in einem festen 
Raster, dass Du definierst. Und dieses Raster heißt, oh Wunder, 
Zykluszeit.

D.h. solange das Benutzer-Programm die konfigurierte Zykluszeit nicht 
überschreitet, hast Du exakt eine Zykluszeit Verzögerung zwischen Input 
und Output.

Typische, "klassische" Zykluszeiten sind z.B. 20ms oder 10ms. Mit einer 
Beckhoff und EtherCat kannst Du aber auch ganz entspannt 1ms machen.

Alles total simpel, und darüber hinaus in der System-Dokumentation 
beschrieben.

Danke mr. spsler für deine oberschlauen zurechtweisungen o.O
Scheinbar hast du den Sinn und Zweck nicht verstanden!
Wenn Das Anwender Programm schneller Ist, wird die SPS logischer weise 
auch schneller Fertig!
Wenn man die SPS allerdings überfordert dan dauert die ganze Baustelle 
eben länger.
Und irgendwelche hirnrissigen zahlen ins System Reindrümmern wie ein 
Idiot kann jeder hirni nur das ganze mal auszumessen und mal nachzusehen 
ob das auch wirklich stimmt haste wohl nicht bedenkt bzw. mal gedanken 
gemacht!
Und genau das möchte ich mal nachsehen und mal aufzeichnen.
Wie dem auch sei, danke für eure Informationen und eure Vorschläge.
LG

Paul G. schrieb:
> Wenn Das Anwender Programm schneller Ist, wird die SPS logischer weise
> auch schneller Fertig!
> Wenn man die SPS allerdings überfordert dan dauert die ganze Baustelle
> eben länger.
Nein.
Auf einer SPS sind die Timeslots terministisch. Die Timeslots für 
lesen der Eingänge und das schreiben der Ausgänge passiert zu genau 
deffinierten Zeitpunkten.
Wie lange dabei der einzelne Task benötigt ist egal, solange die max. 
Zykluszeit nicht überschritten wird.

Paul G. schrieb:
> Am Eingang X, wird ein Taster angebaut und mit dem Oszi verkabelt.
> In der SPS soll nachdem am Eingang X ein Signal angekommen ist, der
> Ausgang Y den Wert 1 bekommen, welcher ebenfalls mit dem Oszi verbunden
> ist!
>
> Das kann ich dann so 5-10x wiederholen und ich habe mal einen ungefähren
> Mittel-Richtwert von der gesammten Zykluszeit T.

Paul G. schrieb:
> Was wäre die einfachste und eleganteste Methode dies zu realisieren, in
> form einer geketteten IF, CASE, WHILE oder einer UND Anweisung?
> Der Hintergrundgedanke ist ja, dass mit jeder weiteren Programmzeile die
> Zykluszeit beeinflusst wird. Genau dieser Vorgang soll mit einen
> Osziloskop aufgezeichnet und protokolliert werden!

Paul G. schrieb:
> Scheinbar hast du den Sinn und Zweck nicht verstanden!
> Wenn Das Anwender Programm schneller Ist, wird die SPS logischer weise
> auch schneller Fertig!


Dein Problem ist, Dein mentales Modell einer SPS, speziell Beckhoff, ist 
komplett falsch.

Es fängt schon mit dem Taster am Eingang an, der asynchron zur 
Zykluszeit arbeitet. Es geht weiter mit der Vorstellung einer "variablen 
Zykluszeit". Zusätzlich scheinst Du zu glauben, wenn eine Änderung am 
Eingang auftritt, das Anwendungsprogramm angeschmissen wird und sofort 
nach Beendigung dessen der Ausgang aktualisiert wird.

Du bist ziemlich auf dem Holzweg und dazu absolut Beratungsresistent. 
Aber mach mal. Bitte Deine Ergebnisse inkl. Versuchsaufbau hier posten.

Der Versuch wird nur bedingt funktionieren, weil die Aktualisierung der 
Ein- und Ausgänge auch im konstanten Raster passiert. Wenn deine 
Zykluszeit auf 1 ms steht, werden die I/Os auch nur im 1 ms Raster 
aktualisiert, egal ob das Programm 0,1 ms oder 0,5 ms braucht.
Beim Aktualisieren werden die Eingänge ins neue Prozessabbild kopiert 
und die Ausgangszustände aus dem Prozessabbild vom letzten Zyklus in die 
Hardware geschrieben, gleichzeitig.
Das ist zumindest per default so.
Ob man das umstellen kann, dass die Ausgänge sofort nach Ende des 
Programms geschrieben werden, weiß ich allerdings nicht.
Dazu müsstest du dir die Hilfe durchlesen.
Bei einem älteren BC ist das anders, der macht sein K-Bus Update wenn 
die SPS fertig ist. Die Zeit ist dann wirklich abhängig  von der 
Zykluszeit der SPS. Bei neueren BCs wird aber wieder mit konstanter 
Zykluszeit gearbeitet. Näheren dazu auch in der Hilfe.

Paul G. schrieb:
> Für eine Wissenschaftliche Arbeit welche sich hauptsächlich mit
> SPS-System befasst möchte ich die Zykluszeit einer Beckhoff-SPS bzw.
> eines Industrie-PC's der FA. Beckhoff messen.

Ist das jetzt ein Trollversuch? Wer nicht mal die Grundlagen einer 
deterministischen Steuerung kennt will eine wissenschaftliche Arbeit 
verfassen?

Das die Zykluszeit festgelegt wird wurde dir ja schon erklärt. Das die 
SPS bei Überlastung auf Störung geht (wenn Sie was taugt) ist wohl auch 
einem "Wissenschaftler" einsichtig.

Nun, ok habe jetzt diese Woche mal die Messungen vollbracht und habe 
dabei ein Interessantes Ergebniss festgestellt:
Bei der Taskkonfiguration wurd die Zykluszeit auf 1ms runterreduziert 
und dann am Eingang sowie am Ausgang das Signal abgegriffen mit dem Oszi 
und die Zeit gemessen.
Nach mehreren Messungen und notierungen wurde immer eine zeit gemessen 
die deutlich über den 1ms war. Im durchschnitt war es 4ms.

Bei einer Einstellung von 200ms Zykluszeit, war das Ergebnis doch 
deutlciher und bin dabei auch im durchschnitt so auf die 200ms 
gekommen....

LG Paul

Nein.. Doch!.. Ohh!

Warum das so ist, kannst du alles in den Handbüchern nachlesen, dort 
gibt es genug technische Daten welche Verzögerungszeiten auf den E/A 
Modulen zu erwarten sind.

Ein wirklich interessantes Thema wäre eher: wie aktualisiert das 
Betriebssystem die E/As, welchen Einfluss hat hier das Zyklische 
Programm und die Interrupts.

Aber kannst du sicherlich nicht analysieren.. vor allem weil ein Anruf 
beim Hersteller die wahrscheinlich das Ergebnis vorwegnehmen wird.


Ohne wissenschaftlichen Hintergrund das ganze..

Paul G. schrieb:
> Nun, ok habe jetzt diese Woche mal die Messungen vollbracht und habe
> dabei ein Interessantes Ergebniss festgestellt:

   [...]

> Nach mehreren Messungen und notierungen wurde immer eine zeit gemessen
> die deutlich über den 1ms war. Im durchschnitt war es 4ms.

Und was ist da jetzt Interessant?

Schon mal an die Filterzeit der Eingangs-Karten gedacht? Die ist bei den 
Feld-Wald-Wiesen-Karten (EL1008 etc.) 3ms typisch...