OSCAT Forum
oscat.lib => oscat.lib fuer Step 7 => Thema gestartet von: softcontrolag am 26. Dezember 2009, 12:38:00
-
Hallo Zusammen
Ich habe das Problem, dass der Actuator 3P irgenwann keine Regelausgang mehr bedient.
Der vorgeschaltete PID Regler reguliert noch tadellos. Mit einem Download des DB's funktioniert der Regler wieder über einige Tage.
Dann ist aber wieder Schluss. Kann uns jemand da weiterhelfen?
-
Hallo,
wann tritt das Problem auf beim laden von Bausteinen, stopp der CPU o. einfach nur so nach Zeit X ?
Gruss Daniel
-
Hallöchen,
Das Problem tritt nach der Zeit X auf, kein Fehler der CPU , kein Fehler am Baustein zu erkennen, Ich habe den folgenden Eindruck:
Ich benutze den Actuator 3P für Heizungssteuerung mit Ventilen AUF / ZU. Der Aqtuator 3P regelt mit dem Stellwert 0..100% aus dem PID Regler (Umgerechnet 0...1 für den Aktuator 3P) wunderbar an den verlangten Sollwert, nach der Zeit X (in Tagen) wenn ich wieder mal auf der Anlage bin oder der Kunde kalt hat habe ich zuerst festgestellt, dass der Actuator 3P auf 0% oder 100% steht. I
n diesem Zustand steuert er das Ventil weder AUF noch zu an. Dies habe ich abgefangen und gesagt, bei <= 0% = Actuator immer ZU, bei >= 100% Actuator immer AUF. Dies bringt, dass beim Endanschlag das Ventil sich bewegt und eine Istwertänderung nachfolgt (Ventil hat kine Rückmeldung um den effektiven Status zu definieren.
Nach dieser Änderung habe ich jetzt aber festgestellt (am 24. Dezember 2009, anstatt den Weihnachtsbraten zu geniessen) dass der eine Aqtuator auf 90% (Betriebsgebäude) der zweite auf 43% (Dekantergebäude) stehen geblieben ist, obschon der PID bei beiden Reglern 100% verlangt. Beide Aqtuatoren steuern weder OUT1 noch OUT zu an, somit ist meine optimierung 0% ZU / 100% AUF wieder hinfällig!
Ich habe bis jetzt sehr gute Erfahrungen mit der Libary gemacht und hoffe dieses Problem mit EUrer Hilfe auch noch in den Griff zu bekommen.
Grüessli der Schweiz
-
Hallo,
Danke, schön beschrieben eines habe ich allerdings vergessen zu Fragen welche Version der oscat.lib habt Ihr im Einsatz?
Gruss Daniel
-
Hallo Daniel
Die Version die wir jetzt benutzen ist 3.11 vorher hatten wir 3.05 benutzt. Dann haben wir kürzlich sämtliche Bausteine auf 3.11 geupdated, und gehoft das das Problem behoben ist!
Gruss
Marco
-
Ich habe noch vergessen zu erwähnen, das wir eine Siemens S7 CPU315/2DP einsetzten
-
ich habe mir den code vom actuator_3p mal angesehen und festgestellt das er sehr alt ist.
wir werden in der nächsten version den actuator_3p komplett neu machen und auf bestehende module der lib zurückgreifen.
dann sollten hoffentlich auch deine probleme behoben sein
-
Was meint Ihr? Wie lange wird das dauern?
-
Hallo Zusammen
Heute morgen hatten wir wieder das Problem, die Ausgabe des Stellgliedes ist stehen geblieben!
Folgendes haben wir festgestellt:
In der Zeile 107 (IF NOT busy AND tx < min_offtime THEN RETURN) wurde die Bearbeitung des Bausteins beendet!
Aufgefallen ist uns das Negativ ist: tx = -4D18H....
Wir haben die Autocalibrierung nicht aktiviert, da wir keine Rückmeldung des Stellgliedes haben.
Momentan als abhilfe haben wir die Zeilen 107-118 deaktiviert, und neu compiliert / geladen. Und hoffen das das Problem nun nicht mehr auftritt.
Grüsse aus der Ostschweiz
-
ich denke das wir bis ende januar zumiondest eine beta haben
allerdings besagt der negative wert beim timer das du eine timer korrektur bei s7 nicht umgesetzt hast.
daniel, ich denke hier fehlt die timer korrektur oder????
-
Hallo Marco,
werde es mir heute Abend mal ansehen.
Gruss Daniel
-
Was meinst du mit Timer Korrektur? Leider finde ich im Fourm keinen verweiss!
Gruss
Marco
-
Was meinst du mit Timer Korrektur? Leider finde ich im Fourm keinen verweiss!
Hallo Marco,
die Korrektur macht der Baustein STIME der Fehler liegt aber im Baustein ACTUATOR_3P.
Gruss Daniel
-
Hallo,
kann es sein das der Baustein bedingt aufgerufen wird, ein tx von -xxx ist eigentlich nicht möglich?
Wäre es möglich mir das Programm einmal zu mailen? PN mit mail an mich.
Achtung: bei einem anderen Topic ist mir aufgefallen das STIME noch einen kleinen Fehler enthält
siehe hierzu STIME Überlauf bit31 (http://www.oscat.de/community/index.php/topic,824.0.html)
Anbei noch die geänderte Quelle von STIME.
Gruss Daniel
[gelöscht durch Administrator]
-
Hallo Hugo
Hmm ... neu machen ... das hat mich aufgeschreckt!
Ich war bisher auch nicht grad glücklich mit diesem Baustein (und habe ihn deshalb auch nicht mehr verwendet) ALLERDINGS IM CODESYS.
Bitte lasse folgende Punkte einfließen:
- Synchronisieren darf teilweise nur in eine Richtung erfolgen (auf 0% od. 100%). zB Dampfregister (NIEMALS auf AUF). Kondensatorventil Kältemaschine (NIEMALS auf ZU).
- Synchronisieren ohne Endschalter (die meisten Antriebe haben nur einen internen oder gar keinen Endschalter). zB.: 2 min auf "ZU" oder "AUF".
- Synchronisieren muß "automatisch erfolgen". Wenn ein Antrieb ohne Endschalter bei POS 0% steht muß die Steuerung DAUERND ein "ZU"-Signal geben oder bei POS 100% steht muß die Steuerung DAUERND ein "AUF"-Signal geben. DAUERND (bei internen Endschaltern) kann in diesem Fall auch nur EINE GEWISSE ZEIT (bei Rutschkupplung und Magnetkupplung) sein. Damit wird verhindert, daß die Rutschkupplung nicht übermäßig belastet wird und natürlich auch wegen des Energieverbrauchs. So erfolgt in der Endlage immer eine automatische Synchronisation, wenn die Laufzeit des Antriebs ein paar sec. länger eingegeben ist als sie tatsächlich ist. Das Ganze stört einen PI bzw PID Regler überhaupt nicht. Und wenn man das Ganz genau haben will kann man es ja auf die sec. genau eingeben.
siehe dazu auch LINK: http://www.oscat.de/community/index.php/topic,411.0.html ganz am Ende. Da habe ich mal diese Änderungen gößtenteils einfließen lassen. (allerdings ohne Option "Rutschkupplung")
Vielen Dank für Euer Verständnis.
PS: Weiters sollten viele Antriebe im Anlagenstillstand mal bewegt werden. (zB jede Woche einal ganz "auf" und "zu")
-
Hallo Daniel
Habe ich das jetzt richtig verstanden? Der Baustein STIME muss nun im OB1 zyklisch aufgerufen werden? Wir haben ihn im OB100 programmiert mit "DBxx.Init := False". Habe dies mal irgenwo im Forum gelesen, das man dies so macht!
Gruss
Marco
-
Hallo Marco,
100% korrekt, der Baustein erkennt selbst ob er neu gestartet werden muss. Allerdings wie zuvor bereits geschrieben ist es wichtig das die Bausteine in denen er Verwendung findet, zyklisch aufgerufen und nicht über den EN Eingang des Bausteins gestartet werden. Wichtig, Bitte die neue Version verwenden da in der alten das Bit das den Überlauf merkt nicht mit gelöscht wird. Das kann zu den von Dir beschriebenen Problem führen.
Gruss Daniel
-
Wie sieht es denn mit dem neuschreiben des FB Actuator 3P aus? Gibt es schon eine BETA-Version?
Hatte bei dem Baustein auch so meine Probleme, die aber zum Teil immer noch nicht gelöst sind. Siehe http://www.oscat.de/community/index.php/topic,374.msg5347.html#msg5347 (http://www.oscat.de/community/index.php/topic,374.msg5347.html#msg5347)
Wollte mich daher jetzt gerade hingesetzt um den Baustein neu zu schreiben. Aber ich würde mir diesen Aufwand gerne sparen!
-
Leider haben wir immer noch das Problem das der Actuator_3P stehen bleibt!!
Wir haben die neue Version 1.4 von Baustein STIME.SCL geladen, doch ohne Erfolg!!
Gruss
Gregor
-
Die Probleme mit den Actuator-Bausteinen kenne ich.
Ich bin gerade dabei, das Modul zu überarbeiten.
Sobald ich erfolg habe werde ich es posten
-
Weist du in etwa wann das sein wird?
Gruss und Danke
Gregor
-
Also, ich habe nun den Actuator_3P ausgiebeig getestet und nur ein Problem festgestellt.
STIME muss die aktuelle Version (1.4) sein.
Ebenfalls muss der FB64 (STIME) im OB1 zyklisch aufgerufen werden.
OB1:
CALL FB64, DB64
Dann kann die negative Zeit nicht mehr vorkommen.
D.h. bei SPS-STOP und übergang in RUN initialisiert sich der Baustein von selbst und korrigiert sämtliche TX und TX_LAST.
Lässt man den aufruf im OB1 weg, kommt es bei neustart oder aber nach T=24D23H59M59S... zum stehenbleiben der Reglerbausteine die STIME benutzen.
Natürlich werde ich weiter testen und beobachten.
Gruß Stefan Hantschel
-
Hallo Stefan
Danke für deinen Hinweis. Wir haben den Fehler nun gefunden! In meinen Projekten habe ich den Aufruf im OB1 gemacht, daher hatte ich auch keine Probleme. Aber bei meinem Kollegen, war der Aufruf noch im OB100! :-(
Heute habe ich ihn nochmals speziell danach gefragt. ;-) Und siehe da..
Gruss und schönes Wochenende.
Gregor
-
Hallo Stefan
Wir hatten kürzlich wieder Probleme mit dem ACTUATOR_3P.
Die "Pos" wurde mit -41000 angezeigt, anstelle von irgenwo zwischen 0..100 %!
Irgenwie ist da immer noch der Wurm drin!
Gruss
Gregor
-
Kannst du mir mal das Proekt schicken?
Das würde ich mir gerne mal ansehen.
-
Guten Morgen,
besteht das Problem in der aktuellen Version immer noch? Könnt Ihr mir ein Projekt zukommen lassen, mit dem beschriebenen work around? Bei mir klappt das nicht...
Vielen Dank.
Gruß Ralf
-
Es gibt inzwischen eine STime 1.6 alle anderen gehen mit der 300er nicht