TIA Zyklusüberwachungszeit wird überschritten

T

TIA_student

Level-1
Beiträge
2
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forengemeinschaft,
ich bearbeite derzeit mein Projekt für meine Bachelorarbeit in der es um die Thematik der prädikativen Regelung von Biogasanlagen geht. Es klappt zwar alles soweit jedoch finde ich zu einem Problem einfach keine Lösung. Mein Ablauf aller FB`s überschreitet die maximale Zyklusüberwachungszeit von 150ms. Das Arbeiten mit dem OB80 und RE_TRIGER() hat zwar den STOP der CPU (300er) verhindert, aber der Zyklus wird intern dennoch abgebrochen wodurch die internen Algorithmen nicht ordentlich rechnen. Leider wird das Einstellen der Zyklusüberwachungszeit im Gerätemanager der CPU nicht übernommen.

Hat jemand Ideen oder Tipps wie man RE_TRIGER() zu nutzten hat?
Woran es liegen kann das der Wert im Gerätemanager online nicht übernommen wird?
Sonstige Möglichkeiten das Problem zu lösen ohne das Programm zu "kürzen":??

(Verwende TIA V15)

Grüße Student:)
 
TIA_student schrieb:
Hat jemand Ideen oder Tipps wie man RE_TRIGER() zu nutzten hat?
Woran es liegen kann das der Wert im Gerätemanager online nicht übernommen wird?
Sonstige Möglichkeiten das Problem zu lösen ohne das Programm zu "kürzen":??
Zum Vergrößern anklicken....

Den SFC43 müsstest Du nicht im OB80 sondern sonst irgendwo im OB1 einbauen, dass wäre aber gaaanz schlechter Programmierstil, also vergiss erstmal den SFC43.

Wenn der OB 80 in demselben Zyklus zweimal aufgrund der Zykluszeitüberschreitung aufgerufen wird, geht die CPU in STOP. Sie können dies durch Aufruf der SFC 43 "RE_TRIGR" an geeigneter Stelle verhindern.
Zum Vergrößern anklicken....

Hast Du die HW-Konfig geladen? Also Hardware übersetzen und Hardware laden? grundsätzlich kannst Du die Zyklusüberwachungszeit schon hochsetzen (vieleicht auf 500ms), kommt drauf an, welche evtl. zeitkritischen Funktionen im OB1 bearbeitet werden...

Du könntest zeitkritische Funktionen in nen schnellen Weckalarm auslagern (OB35), und nichtzeitkritische Funktionen in nen langsamen Weckalarm (OB32)...

Ansonsten würd ich ne 300er SPS immer im Step 7 classic 5.x projektieren, niemals im TIA, wer weiss, ob da noch nen Bug schlummert...

Gruß.
 
Ich würde jetzt nicht rumdocktern und retriggern, um den CPU-Stop zu verhindern, sondern die Ursache der Zykluszeitüberschreitung suchen und beseitigen.

Warum wird die Zyklusüberwachungszeit überschritten? Ich vermute eine "ungünstige" Programmierung. Womit ist die CPU so lange beschäftigt? Kann/muß das nicht auf mehrere Zyklen verteilt werden? Wie lang ist die normale Zykluszeit?

Welche CPU genau verwendest Du? 6ES7 31.-..... Firmware V.....

Harald
 
TIA_student schrieb:
... aber der Zyklus wird intern dennoch abgebrochen wodurch die internen Algorithmen nicht ordentlich rechnen.
...
Sonstige Möglichkeiten das Problem zu lösen ohne das Programm zu "kürzen":??
Zum Vergrößern anklicken....
Wie lang (bzw. kurz) wird denn die ZyklusZeit, wenn Deine Algorithmen nicht berechhnet (bzw. "übersprungen") werden?
Ich fürchte, Du wirst Dir doch etwas überlegen müssen, wie Du die Rechnerei auf mehrere Zyklen verteilen kannst.
Hast Du vielleicht EndlosSchleifen programmiert?
Geht die SPS während Deiner Rechnerei in STOPP oder erst danach, sozusagen im "normalen" zyklischen Programm?

Edit:
Harald war wieder schneller ;)
Meine letzte Frage ziehe ich zurück - ist eigentlich schon beantwortet.

Könnte mir vorstellen, dass Teile der Berechnungen "alle JubelJahre" berechnet und andere häufig aktualisiert werden müssen.
Da würde sich eine Aufspaltung aufdrängen, so dass nicht in jedem Zyklus alles komplett neu gerechnet werden muss.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
ducati schrieb:
Den SFC43 müsstest Du nicht im OB80 sondern sonst irgendwo im OB1 einbauen, dass wäre aber gaaanz schlechter Programmierstil, also vergiss erstmal den SFC43.



Hast Du die HW-Konfig geladen? Also Hardware übersetzen und Hardware laden? grundsätzlich kannst Du die Zyklusüberwachungszeit schon hochsetzen (vieleicht auf 500ms), kommt drauf an, welche evtl. zeitkritischen Funktionen im OB1 bearbeitet werden...

Du könntest zeitkritische Funktionen in nen schnellen Weckalarm auslagern (OB35), und nichtzeitkritische Funktionen in nen langsamen Weckalarm (OB32)...

Ansonsten würd ich ne 300er SPS immer im Step 7 classic 5.x projektieren, niemals im TIA, wer weiss, ob da noch nen Bug schlummert...

Gruß.
Zum Vergrößern anklicken....

JA danke, das mit dem laden der HW-Konfig war tatsächlich das Problem:oops:. Läuft also nun ohne SFC30 und ohne Stopp:).

-Die Zykluszeit lag bei ca. 100ms wenn ich den Großeil der Rechnung auskommentiert habe, wird alles abgearbeitet liege ich bei ca. 1000ms und gehe in den STOPP.
-Zur CPU: cpu 317-2 pn/dp 6ES7317-2EK14-0AB0 V2.6
-Endlosschleifen scheinen keine drinne zu sein, schätze aber das der Programmierstil schon das generelle Problem ist.

Leider ist das Unternehmen in dem ich das Projekt mache nicht wirklich SPS und Siemens affin, weshalb ich nur mit den gestellten Sachen arbeiten kann. Aus dem Grund wird das arbeiten mit dem Code auch eher schwierig, da dieser von mir nur erweitert wurde und vieles was dort passiert eher wie eine Blackbox ist (Keine Kommentare etc...). In wiefern ich da dann noch eine Aufspaltung in Weckalarmen machen kann wird sich dann erst zeigen.

Zu den anderen Infos, wofür würde man denn den SFC43 nutzen bzw. kann man genau sagen an welcher Stelle im Code der Stopp kommt um dort die Zyklusüberwachungszeit neu zu triggern?

Aufjedenfall schonmal ein riesen Dank an alle für die vielen Ideen und Anregungen!
 
Um eine 317 EK14 auf 1000ms zu treiben, das scheint mir aber
schon etwas schleierhaft. Wir reden ja nicht von Berechnungen zur
Mondlandung sondern für eine Biogas-Anlage
 
DeltaMikeAir schrieb:
Um eine 317 EK14 auf 1000ms zu treiben, das scheint mir aber
schon etwas schleierhaft. Wir reden ja nicht von Berechnungen zur
Mondlandung sondern für eine Biogas-Anlage
Zum Vergrößern anklicken....

Das sehe ich auch so.
Hier liegt ein grundlegendes Problem im Code vor.
Wahrscheinlich irgendwelche Schleifen nicht "SPS-konform" programmiert.
For - Next oder DO -While ist halt bequemer als etwas auf mehrere Zyklen aufzuteilen.

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
nunja, solche prädiktiven Regel-Algorithmen sind meist schon etwas aufwändiger, ob man die jetzt für ne Biogasanlage braucht sei mal dahingestellt. Jedenfalls ist ne SPS kein PC, d.h. riesige Berechnungen dauern auf ner langsamen SPS schonmal.
Da muss man schon ordentlich Gehirnschmalz reinstecken, um sowas auf ner SPS ordentlich zum laufen zu bekommen.
Die Frage wäre, wo kommen die Algorithmen her? Glaub Siemens hat mal ne MPC-Bibliothek für S7 angeboten. Oder ist das S7-code von Matlab/Simulik erzeugt oder von Labview? Vielleicht hat das auch jemand selbst geschrieben, dann wärs aber vermutlich kommentiert. Oder ist das garnicht das Originalprojekt/Quellcode sondern wurde mal aus ner SPS ausgelesen? Fragen über Fragen... In welcher Programmiersprache ist der Code denn? Kannst Du mal nen kleines Beispielschnippsel hier reinstellen?
 
Zuletzt bearbeitet:
TIA_student schrieb:
Zu den anderen Infos, wofür würde man denn den SFC43 nutzen bzw. kann man genau sagen an welcher Stelle im Code der Stopp kommt um dort die Zyklusüberwachungszeit neu zu triggern?
Zum Vergrößern anklicken....

Vergiss den SFC43 das bringt Dir garnix... Wenn ne OB1 Zykluszeit bei Deiner Anlage nicht schlimm wäre, dann setz die Zyklusüberwachungszeit hoch. Der SFC43 verringert ja nicht die Zykluszeit...
Aber viele Aktionen in der SPS werden im Zykluskontrollpunkt, also zw. Ende OB1 und Anfang OB1 ausgeführt, z.B. Einlesen der Ein/Ausgänge, Kommunikation mit HMI...
D.H. mindestens die Bedienung der Anlage wird sehr lahm, jeden Taster musst Du mind. 1s drücken, auf dem Panel aktualisiert sich alles sehr langsam.
Also Du wirst nicht drumrum kommen, den Code auf mehrere Zyklen aufzuteilen oder abzuspecken...
Ansonsten gäbs noch eine Variante:
- den langen Code in den OB32 mit 2000ms
- den restlichen Code in den OB34 mit 200ms
- alle EAs die im OB34 benötigt werden in nen Teilprozessabbild TPA legen, sofern das bei ner 300er geht
- bei der CPU die "priorisierte BuB Kommunikation" aktivieren

Aber was das sonst für Sorgen macht bzw. obs überhaupt funktioniert, kann ich nicht sagen, kenn ja Deine Anlage und Software nicht...
 
Zuletzt bearbeitet:
ducati schrieb:
Aber was das sonst für Sorgen macht bzw. obs überhaupt funktioniert, kann ich nicht sagen, kenn ja Deine Anlage und Software nicht...
Zum Vergrößern anklicken....

Ach das ist ja bloß ne Biogas-Anlage ...
Und da es keine F-CPU ist, wird dann schon irgendeine Sicherheitsüberwachung bei AG-Stop ansprechen :ROFLMAO:
Also im schlimmsten Fall riecht es im 2km Umkreis, die Soße läuft über den Hof und der Betreiber darf leerräumen.

- den langen Code in den OB32 mit 2000ms
- den restlichen Code in den OB34 mit 200ms
Zum Vergrößern anklicken....

Sowas in der Art ist sicher ein gangbarer Weg. Interessant sind dann die Schnittstellen und die Kommunikation zwischen den "Tasks".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Blockmove schrieb:
Sowas in der Art ist sicher ein gangbarer Weg. Interessant sind dann die Schnittstellen und die Kommunikation zwischen den "Tasks".
Zum Vergrößern anklicken....

Ja, ich hab früher viel PCS7 gemacht, da lief alles über Weckalarme und durch die Monster-PCS7-Bausteine hat man da auch mal eher Zykluszeitprobleme. Nur hat man bei ner 400er ein par mehr Möglichkeiten...

Die Frage bei der 300er wäre, wie man das Prozessabbild im OB32 aktualisiert krigt... Vermutlich mit SFC26/27 oder SFC14/15 vielleicht auch mit PEW PAW Zugriffen...

Aber Konsistenzprobleme gibt es hier auch noch, wenn DBs z.B. dann vom HMI, OB34, OB32 gemeinsam verwendet werden und dort jeweils auch noch mehrfach geschrieben/gelesen wird...

Weiterhin vermute ich, das diese tollen prädiktiven Bausteine einen konstanten Zyklus benötigen, wie z.B. auch nen PID-Baustein...

Also das ganze ist nicht ganz ohne, wenns ordentlich werden soll. Ansonsten stinkts halt abundzu...

Auf ne 1518 umzusteigen wäre auch noch ne Idee, oder halt ne Soft-SPS ala 1515SP...

Oder halt schauen, ob man den prädiktiven Kram überhaupt braucht ;)

Gruß.
 
ducati schrieb:
Ja, ich hab früher viel PCS7 gemacht, da lief alles über Weckalarme und durch die Monster-PCS7-Bausteine hat man da auch mal eher Zykluszeitprobleme. Nur hat man bei ner 400er ein par mehr Möglichkeiten...

Die Frage bei der 300er wäre, wie man das Prozessabbild im OB32 aktualisiert krigt... Vermutlich mit SFC26/27 oder SFC14/15 vielleicht auch mit PEW PAW Zugriffen...

Aber Konsistenzprobleme gibt es hier auch noch, wenn DBs z.B. dann vom HMI, OB34, OB32 gemeinsam verwendet werden und dort jeweils auch noch mehrfach geschrieben/gelesen wird...

Weiterhin vermute ich, das diese tollen prädiktiven Bausteine einen konstanten Zyklus benötigen, wie z.B. auch nen PID-Baustein...

Also das ganze ist nicht ganz ohne, wenns ordentlich werden soll. Ansonsten stinkts halt abundzu...

Auf ne 1518 umzusteigen wäre auch noch ne Idee, oder halt ne Soft-SPS ala 1515SP...

Oder halt schauen, ob man den prädiktiven Kram überhaupt braucht ;)

Gruß.
Zum Vergrößern anklicken....

Vermutlich erhofft sich der Hersteller einen Wettbewerbsvorteil bei geringen Mehrkosten ;)
Ich würd hier mal Richtung neuem Wago PFC200 Controller schauen.
Codesys hat ein besseres Task-Konzept als Siemens und wenn es damit nicht geht, dann kann man immer noch eine Linux-Applikation erstellen.
Und dabei billiger als die Siemens 317
 
Blockmove schrieb:
Vermutlich erhofft sich der Hersteller einen Wettbewerbsvorteil
Zum Vergrößern anklicken....

hmm, ich halte von diesen hochtragenden Regelungsgeschichten in der klassischen Industrieautomatisierung nichts...
In der Praxis kriegt schon kaum jemand nen PID-Regler ordentlich eingestellt. Geschweige denn nen MPC oder Zustandsraumregler...
Zumal die Probleme ganz andere sind: wenn ein PID schlecht funktioniert, liegt das meist dran, dass der Prozess nichlinear und zeitvariant ist. D.h. die tollen PID-Parameter passen nur an einem Arbeitspunkt unter bestimmten Bedingungen. An allen anderen Punkten ist er entweder zu langsam oder instabil.
Was man also bräuchte wäre ein nichtlinearer Regler der einfach einzustellen wäre und auch noch in 10 Jahren vom normalen Instandhalter verstanden wird... Sowas gibts aber nicht...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ducati schrieb:
hmm, ich halte von diesen hochtragenden Regelungsgeschichten in der klassischen Industrieautomatisierung nichts...
In der Praxis kriegt schon kaum jemand nen PID-Regler ordentlich eingestellt. Geschweige denn nen MPC oder Zustandsraumregler...
Zumal die Probleme ganz andere sind: wenn ein PID schlecht funktioniert, liegt das meist dran, dass der Prozess nichlinear und zeitvariant ist. D.h. die tollen PID-Parameter passen nur an einem Arbeitspunkt unter bestimmten Bedingungen. An allen anderen Punkten ist er entweder zu langsam oder instabil.
Was man also bräuchte wäre ein nichtlinearer Regler der einfach einzustellen wäre und auch noch in 10 Jahren vom normalen Instandhalter verstanden wird... Sowas gibts aber nicht...
Zum Vergrößern anklicken....

Ich sehe es nicht so pessimistisch.
Biogasanlagen sind mittlerweile eigentlich „Serienanlagen“.
Fernwartung ist da auch normal. Ein normaler Instandhalter wird kaum an die SPS müssen.
Nicht lineare Regler ein spannendes Thema ... Und ich bin froh, dass es mich nicht betrifft :D
 
Zuletzt bearbeitet:
Zurück
Oben