Schönen Sonntag euch allen :) Ich bin mir nicht ganz sicher ob ich hier wohl im Richtigen Forum unterwegs bin, aber versuchen kann man es ja mal. 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. Die herangehensweise ist eher einfach gehalten: 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. Nun zu meiner eigneltichen Frage :D Um einen vergleichbaren wert zu bekommen, möchte ich ein "Groß-Programm" entwickeln und die SPS mal ganz schön überfordern was die Zykluszeit betrifft. Hat jemand von euch vllt eine Idee, oder schon einen vergleichbaren versuch gestartet um sowas zu realisieren? Soll ich einfach x-beliebig viele WHILE und IF Schleifen reinschreiben bis der Baustein "voll" ist? LG Paul
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.
Die Zykluszeit kannst du dir einfach im Task im TwinCAT PLC Control einstellen. Die aktuelle Auslastung siehst du im Systemmanager. Wird die Zykluszeit überschritte, werden meines Wissens einfach Zyklen ausgelassen und wenn es zu viel ist, dann kannst du ins Stop jagen. Falls du Freerunning Tasks verwendest siehst du die Zeit auch im Systemmanager und du kannst sie auch mit einem Baustein (ich Glaube aus der System.lib) abfragen. Alles weitere an Verhalten, findet man in der Hilfe und somit kannst du dir den Versuch sparen. Christian_RX7
Paul G. schrieb: > die SPS mal ganz schön überfordern was die Zykluszeit betrifft. Lass die SPS einfach ein 100kHz Signal abtasten, die Flanken erkennen und zählen. Du wirst dann sehen, dass die ohne besondere Funktionsblöcke recht schnell überfordert ist..
:
Bearbeitet durch Moderator
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.
Nur so als Idee, Du kannst einen Baustein erstellen, der eine Anzahl von 100ns-Ticks abwartet. Mit GETCPUCOUNTER kannst du beim Aufruf des Bausteins die aktuelle Anzahl (64 Bit) auslesen, als Startwert festhalten und in einer REPEAT Schleife GETCPUCOUNTER aufrufen bis die gewünschte 64 Bit Differenz zum Startwert erreicht ist. So hättest du eine zeitgesteuerte CPU-Last. Bei mehreren PLC-Tasken musst du überlegen in welcher Task und wie oft der Baustein aufgerufen werden soll, je nachdem, was du untersuchen willst.
:
Bearbeitet durch User
Punkt schrieb: > 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. Ich kenne das anders: es wird am Anfang ein Prozessabbild der Eingänge eingeslesen, dann wird damit gearbeitet und anschließend das Prozessabbild der Ausgänge ausgegeben. Nach so einem Durchlauf geht es wieder von vorne los. Die Dauer eines Durchlauf ist variabel, sie nennt sich Zykluszeit und sie darf nicht zu lang werden, um eine Reaktion in "Echtzeit" zu gewährleisten. Ob dabei die Eingänge direkt von den EA-Klemmen oder nur von im Speicher gepufferten Eingangssignalen kommen, ist für die Zykluszeit irreleant. Das selbe gilt für die Ausgänge: wie die ausgangssignale letztlich auf Klemmen kommen, das steht auf einem anderen Blatt. Diese zusätzlichen Zeiten bringen einfach mehr Latency, dann man muss schlimmstenfalls noch zwie komplette IO-Zyklen zusätzlich rechnen, um eine Auswirkung von einem Eingang auf einen Ausgang zu sehen. Beim Messen von Reaktionszeiten äussert sich das in zusätzlichem Jitter...
Lothar Miller schrieb: > Ich kenne das anders: es wird am Anfang ein Prozessabbild der Eingänge > eingeslesen, dann wird damit gearbeitet und anschließend das > Prozessabbild der Ausgänge ausgegeben. Nach so einem Durchlauf geht es > wieder von vorne los. > Die Dauer eines Durchlauf ist variabel, sie nennt sich Zykluszeit so kenne ich das auch...für meine S7 lässt sich die Zykluszeit in Step7 ja auch direkt anzeigen, da gibt man nur eine erlaubte Höchstdauer an...
Keine Ahnung wie das bei Siemens ist, bei Beckhoff wird die Cycle-time fest eingestellt. Und auch die Kommunikation über den Bus läuft immer gleich, egal ob man weitere 20 Teilnehmer eingefügt hat oder nicht. Das kann man alles schön in der System-Doku nachlesen: http://infosys.beckhoff.com/content/1031/ethercatsystem/html/bt_ethercatsystem_title.htm?id=6857 Mit freundlichen Grüßen Thorsten Ostermann
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.
Eine fachfremde Arbeit ... zb bei den Forstwarten, Medizinern, Philosophen, .. kann man damit immer brillieren. Auch wenn's fuer die Tonne ist. Ich seh's auch so : ein Troll.
:
Bearbeitet durch User
Thorsten Ostermann schrieb: > Das kann man alles schön in der System-Doku nachlesen: Der Link taugt dafür aber nichts, denn der führt ja nur zu irgenwelchen EtherCAT Klemmen. Und die haben an sich keine Zeit, ein EA-Zyklus wird dort ja vom EtherCAT Master ausgelöst. Dort findet sich dann schon mehr: http://infosys.beckhoff.com/index.php?content=../content/1031/bc9xx0/html/bt_bc9xx0_techndataplc.htm&id= Dort steht: SPS-Zykluszeit ca. 0,85 ms für 1000 AWL-Befehle (ohne E/A-Zyklus) Also gibt es eine Zykluszeit für xxx Befehle und dazu kommt die EA-Zeit. Also alles alter Kaffee...
Die ganze Fragestellung ist schon idiotisch. Wie kann man eine SPS ausserhalb der Spezifikationen betreiben. Aehnlich wie : -Wie lange kann ich einen Verbrenner an der maximalen Drehzahl laufen lassen? -Wie lange kann ich aus einem Netzteil die maximale Leistung ziehen? Wenn die SPS zu langsam ist nimmt man eben die naechst Groessere. Tsss..
Hallo Lothar, > Dort findet sich dann schon mehr: > http://infosys.beckhoff.com/index.php?content=../content/1031/bc9xx0/html/bt_bc9xx0_techndataplc.htm&id= > Dort steht: > SPS-Zykluszeit ca. 0,85 ms für 1000 AWL-Befehle (ohne E/A-Zyklus) > > Also gibt es eine Zykluszeit für xxx Befehle und dazu kommt die EA-Zeit. > Also alles alter Kaffee... Jain. E/A ist eben ein eigener Zyklus mit festgelegtem Timing. Egal wie lange in der PLC-Task gerechnet wird. Mit freundlichen Grüßen Thorsten Ostermann
Thorsten Ostermann schrieb: > Jain. E/A ist eben ein eigener Zyklus mit festgelegtem Timing. Egal wie > lange in der PLC-Task gerechnet wird. Klar, genau das meine ich ja: wenn die SPS z.B. 15ms für einen Zyklus braucht, dann bringt es vordergründig nichts, wenn ich den EA-Zyklus auf 1ms setze. Tatsächlich bringt es aber schon was, weil dann das Ergebnis mit möglichst aktuellen Eingangsdaten berechnet und schnellstmöglich an die ausgänge gegeben wird. Am schnellsten wäre es aber immer noch, wenn nach dem SPS Durchlauf die Ausgänge direkt auf die EA geschrieben und gleichzeitig die Eingänge eingelesen würden...
Bei der SPS geht es aber nicht darum, was am schnellsten wäre, sondern darum, dass das Ergebnis zeitlich vorhersagbar (deterministisch) ist. Also nicht von der CPU-Last abhängt. Mit freundlichen Grüßen Thorsten Ostermann
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.