Nachrichten

121

Bestehende Module / Existing Modules / Re: Bug in ACTUATOR_3P?

« am: 08. November 2012, 18:05:00 »

Hallo,

es stellt sich sicherlich die Frage, warum du eine Fußbodenheizung (noch dazu mit langem Tastintervall für die Fühler) mit einem PID-Regler versiehst, aber das ist eine andere Frage.

Zur Klärung deines Problems wäre die Antwort auf einige fragen interessant:

a) Funktioniert denn der ACTUATOR_3P für dich, wenn du Manuell (per Forcen oder wie auch immer) Stellungssollwerte vorgibst?
b) Kannst du ein möglichst einfaches Minimal-Testprogramm anbieten (lieber ausgedruckt als als Programmdatei), mit dem das Problem für dich reproduzierbar ist?
So in der Art
 - Per Forcbarer Bool-Variable wird ein  Einzelimpuls gestartet
 - Impuls mit Dauer über Variable setzt Stellungssoll für Impulsdauer (meinetwegen auch für nur 1 Zyklus) von 0 auf 1,
   nach Impulsablauf wieder auf 0
 - Selbsthaltung an OUT 1 zeigt, ob der Ausgang gekommen ist
 - Stellung kann man ablesen
Dann mal weiter sehen.

Grüße

Rainer

122

Bestehende Module / Existing Modules / Handbuch-Fehler oscat_basic333 für GEN_SIN

« am: 08. November 2012, 09:56:27 »

Hallo,

bei meinem Verusch, das Problem in "bugfix Vorschlag für FILTER_MAV_W" http://www.oscat.de/community/index.php/topic,1863.msg9851.html#msg9851 nachzuvollziehen habe ich eine Ungenauigkeit im mir vorliegenden Handbbuch bemerkt.

In der Beschreibung heißt es unter anderem:
- AM : REAL (Signal Amplitude)
- Der Eingang AM und OS legen die Amplitude ...
- einstellbarer Amplitude

Arbeit mit dem Beispielprogramm und auch der Graph im Handbuch für den Baustein-Eingang AM zeigen aber, dass der Zahlenwert vom Baustein nicht als Amplitude,  sondern als Spitze-Spitze-Wert verwendet wird; die korrekten Definitionen stehen in Wikipedia http://de.wikipedia.org/wiki/Amplitude.

Auf jeden Fall sollte das im Handbuch korrigiert werden. Für den Baustein fände ich eigentlich einen Amplitudeneingang sinnvoller, aber das ist sicher Geschmackssache, und aus Kompatibilitätsgründen ist eine Änderung wohl eher nicht empfehlenswert. Vielleicht sollte aber der Baustein- Eingang passiger benannt werden?

CU

Rainer

123

oscat.lib fuer TwinCAT/CoDeSys / Re: bugfix Vorschlag für FILTER_MAV_W

« am: 08. November 2012, 06:49:11 »

Hallo,

ich kann das Problem mit PC WORX EXPRESS und Phoenix ILC 130 bestätigen. Im Beispielprogramm "FILTER_MAV_W_TEST.zwe" http://www.bielefeldundbuss.de/OSCAT/FILTER_MAV_W_TEST.zwe durchläuft der Eingang des Filters Werte von 45 ... 55, also sollte auch der Ausgang des Filters irgendwo in diesem Bereich liegen. Der Screenshot zeigt aber einen Ausgangswert von 6914 an, das kann nicht gut sein.

Ein TRUE auf den RST Eingang schaltet erst mal den Eingangswert auf den Ausgang durch, nach RESET-Ende ist nach wenigen Augenblicken wieder der unsinnige Ausgang zu sehen.

Grüße

Rainer

[gelöscht durch Administrator]

124

Anwendungsbeispiele / Application Examples / Re: Hilfe bei Regelung mit FT_PIDWL und ACTUATOR_3P

« am: 08. November 2012, 06:09:17 »

Hallo,

ich hatte gerade ein paar ähnliche
http://www.oscat.de/community/index.php/topic,1866.0.html
http://www.oscat.de/community/index.php/topic,1866.0.html
Probleme und weiß Lösungen bzw. Lösungsansätze, aus denen ich am Wochenende Lösungen machen werde. Ehe ich aber Seiten-lang etwas schreibe: ist dein Problem noch aktuell?

Grüße

Rainer

125

oscat.lib fuer PC WorX/MULTIPROG / Re: I-Anteil des PI-Reglers "RLT30_FB_CTRL_PI" hängt sich auf - Mehr Beobachtung

« am: 07. November 2012, 19:15:19 »

Hallo,

nach ein paar weiteren Stunden ohne Änderung beim Ausgangswert habe ich nun mal den Reglereingang RST kurz auf 0 gesetzt. Mich wundert, dass der Regler Ausgang daraufhin auf 0% gegangen ist, was für mich nach Durchsicht des Handbuchs ("Mit RST kann der interne Integrator jederzeit auf 0 gesetzt werden") bedeutet, dass zu dem Zeitpunkt kein P-Anteil am Ausgang vorhanden war? Der Ausgang stieg dann auf gut 10% und verharrt dort wieder.

Was auch immer das bedeuten mag.

Grüße

Rainer

126

oscat.lib fuer PC WorX/MULTIPROG / Re: I-Anteil des PI-Reglers "RLT30_FB_CTRL_PI" hängt sich auf - Testprogramm

« am: 07. November 2012, 14:39:00 »

Hallo,
ich habe auch zu diesem Problem (wie bei der ACTUATOR_3p- Frage) ein gepacktes Testprogramm bereit gestellt: http://www.bielefeldundbuss.de/OSCAT/PI_Test_ab.zwe

Das Testprogramm habe ich ein paar Stunden auf einer ICL 130 laufen lassen, sie simuliert die Verhältnisse in einer Heizungs-Temperaturregelung; Regler-Istwert und Regler-Sollwert entsprechen verzehnfachten Temperaturwerten (in der HLK-Technik gebräuchliches Verfahrren), also grob 50°C . Der Sollwert ändert sich allmählich über den unteren Sinusgenerator mit 12 Stunden Periodendauer, und die gemessene Temperatur wird über einen Sinusgenerator mit 10 Minuten Periodendauer und einer Rückkopplung simuliert. Das sah realistisch aus.

Dann habe ich die Eingangs-Situation "eingefroren", indem ich während des Programmlaufes beide Periodendauern (über die Eingangsvariablen) drastisch verlängert habe. Ergebnis: Betrag der Regelabweichung ca 5.0, Actuator_3P schaltet mit 2 Hz (so jedenfalls auf dem Bildschirm sichtbar) zwischen Position 126 und 127 hin und her.

Erwartetes Verhalten:     Das (mittlere)  Ausgangssignal des PI-Reglers sollte sich über den Integralanteil ganz allmählich verringern.
Tatsächliches Verhalten: Ausgangssignal pendelt unendlich zwischen den beiden selben Werten umher.

Ich habe sicherheitshalber KI in verzehnfahcungs-Schritten von 0.00001 bis 10000.0 geändert: kein Effekt. Der Regleraugang pendelt nun bereits seit über einer Stunde zwischen 49.81 und 79.71. Das ist definitiv so nicht brauchbar.

Die Fragen sind:
a) Irgendein Beschaltungsdetail nicht optimal und behindert den I-Regler?
b) Reagiert der Reglerbaustein überhaupt auf Eingangsänderungen zur Laufzeit? KP-Änderungen wirken sichtbar und genau wie erwartet.

Mit diesem Programm habe ich's noch nicht versucht, in einer realen Anlage war es aber so, dass der I-Regler zunächst ganz eindeutig funktionierte, bei Eingefrorenen Eingängen mit Regelabweichung sah man den Ausgang stetig in die richtige Richtung "krabbeln", Versuch zu einem Späteren Zeitpunkt zeigte dann das Bild wie im Testprogramm ohne I-Regelung

Wer kann Licht in's Dunkel bringen?

Grüße


Rainer

[gelöscht durch Administrator]

127

oscat.lib fuer PC WorX/MULTIPROG / Re: ACTUATOR_3P will nicht laufen

« am: 07. November 2012, 07:07:19 »

einzige schnelle lösung ist nun den auto kalibiermodus zu blockieren
dazu musst du nur bei T_CAL eine T#0s parametrieren
um die Auto Diagnose auch zu blockieren musst du bei T_DIAG auch T#0s übergeben

Moin, das entspricht ja so weit dem Handbuch, und ich kann in so fern einen Erfolg melden, dass das gestern morgen so gestartete Testprogramm immer noch läuft.

Ich habe noch etwas weiter geforscht und festgestellt, dass mein Problem, dass der Actuator bei einigen Tests gar nicht anlief, daran lag, dass ich für T_EXT owhl auch "0s" vorgegeben hatte, jedenfalls läuft der Antrieb dann nach dem Kaltstart nicht an. Der Status geht seinen ablauf durch, (103 ... 104 ... 100), aber der Ausgang bleibt eisern auf 0. Da müsste ja zumindest ein Fehlerstatus ausgegeben werden, und im Handbuch sollte das auch erwähnt werden.

Wenn man das alles beachtet scheint der Baustein zu funktionieren, für Weiterentwicklungen sollte m.E. aber wirklich eine völlige Abschaltung des Testlaufs nach Kaltstart erwogen werden, ein wahlweises definiertes Anfahren einer der Endlagen vor dem Anlauf hingegen wäre sehr sinnvoll (einfach 1,25x T_RUN in die vorgegebene Richtung). Auswahl beispielsweise über einen BYTE-Eingang
0: Definiertes Schließen
1: Definiertes Öffnen
>1: Testlauf wie bisher (default = 2)

Ich habe mein Testprogramm mal um einen PI-Regler erweitert, mal sehen, ob sich so auch das oben Geschilderte I-Hänger-Problem eingrenzen lässt?

Grüße

Rainer

128

oscat.lib fuer PC WorX/MULTIPROG / Re: ACTUATOR_3P will nicht laufen - Testergebnisse Eigenkonstruktion

« am: 06. November 2012, 06:48:29 »

Hallo,

meine Eigenkonstruktion habe ich jetzt 2 Tage in einer echten Anlage getestet.  Wegen der Probleme mit dem OSCAT PI-Regler (http://www.oscat.de/community/index.php/topic,1866.msg9832.html#msg9832) habe ich für die Regelfunktion den mit PC WORX gelieferten PID-Regler für den eigentlichen Regelungsvorgang benutzt. Dieser Baustein ist zwar für die dauerhafte Verwendung nicht geeignet, der Ausgang kann anscheinend nicht auf einen sinnvollen Bereich begrenzt werden, und Änderungen der Regelparameter zur Laufzeit haben gruselige Nebenwirkungen, aber bis ich habe die Anlage erst mal am Laufen.

Mein Testergebnis: Ich kann zwar die tatsächliche Antriebsstellung nicht beobachten (Fernwartungszugriff), aber die Anzeigen sind plausibel. Würde ein Antrieb am Vortag im Bereich 20% ... 25% fahren und unter gleichen Bedingungen am Folgetag von 80% ... 85% wäre das ein Zeichen, dass sich errechnete und tatsächliche Position "auseinandergelebt" haben, das beobachte ich da aber nicht. Allerdings sind das dort eine sehr ruhige Regelstrecken, wie das mit viel Bewegung langfristig aussieht wäre noch mal abzuwarten. Ich sehe aber keine Schwierigkeiten auf mich zukommen.

Grüße

Rainer

129

oscat.lib fuer PC WorX/MULTIPROG / Re: ACTUATOR_3P will nicht laufen - Debugprojekt

« am: 06. November 2012, 06:37:15 »

Hallo peewit,

danke dass Du Dir das mal ansehen willst. Das Testprojekt steht zum download auf <http://www.bielefeldundbuss.de/bilder/Actuator_Test_aa.zwe>, ich hab's gestern Abend gestartet und heute hing der ACTUATOR_3P in Status 101 auf Stellung 255 fest, vermutlich schon lange. Ich möchte vermuten, dass nach Ablauf von T_CAL ein "Kalibrierungslauf" gestartet wurde, der nicht abgeschlossen werden kann. Es stellt sich die Frage, was die Funktion mit Stellung 255 bezwecken will? Warum nicht 0? Natürlich kann von Fall zu Fall mal die eine, mal die andere Endlage als Anlaufpunkt zweckmäßiger sein, aber es müsste in der Beschreibung erläutert werden, warum das Programm was genau macht.

Die weiteren Schwierigkeiten (warum ist der Baustein manchmal nicht in Gang zu bekommen?) habe ich (noch) nicht weiter untersucht, mag da aber momentan nicht nennenswert Zeit investieren, da ich den Baustein vom Grundkonzept her für misslungen halte. Entweder fehlen in der Beschreibung ein paar Details, die mich für die vorgesehenen Funktionen begeistern, oder der Baustein ist in seiner jetzigen Form für die praktische Verwendung eher ungeeignet. Eine Funktion, die (soweit ich das bisher absehen kann) ohne Rücksicht auf Prozessbelange irgendwelcher Selbstbeschäftigung nachgeht, mag ich nicht verwenden.

Grüße

Rainer

130

Bestehende Module / Existing Modules / Verbesserungsvorschlag für Filter (FILTER_I)

« am: 05. November 2012, 13:34:36 »

Hallo,

ich benötige den FILTER_I recht oft, und er tut seinen Dienst klaglos, aber ich vermisse bei dem Funktionsbaustein eine Funktione, die ich von der parallel benutzten SAIA-SPS kenne und schätze.

Dort haben entsprechende Filterfunktionen eine Auswahl für den Startwert, bei der Programmerstellung  lässt sich alternativ  festlegen
a) Startwert mit programmiertem Festwert
b) Startwert = Eingangswert.

'a' ist eine Erweiterte Form des OSCAT-Filterverhaltens, der nach einem Kaltstart stets so anfängt, als sei beim Kaltstart der Eingang auf 0 gewesen, also der Ausgang startet auch mit wert "0". Das kann sehr lästig sein, wenn man beispielsweise einen Außentemperaturmesswert mit einer Zeitkonstante von 10 Minuten filtert (weil gelegentlich vor der Sonne vorbeiziehende Wolken nicht interessieren). Man hat erst mal 1/4 Stunde Winter. Noch lästiger wird es, wenn man Schwankungen um einen hohen Sockelwert herum filtern möchte, beispielsweise die Anzeige die Raumluft-CO₂ Gehalts, meinetwegen angestrebter Wert 800 ppm, Zeitkonstante 1/4 h. Da zeigt die Anzeige erst mal eine ganze Weile Unsinn an.

Deshalb wäre eine Alternative schön:

'b' setzt den Ausgang nach dem Kaltstart auf den Eingangswert, und von da an wird gefiltert. Das dürfte für fast alle Anwendungen, wo der Filter zur "Glättung" eines Prozess-Messwerts verwendet wird, die geeignetste Methode sein. Desahb mein Wunsch, auch für die filter zu anderen Datentypen.

Ich weiß, der FT_PT1  startet gemäß Verfahren 'b', hat aber auch keine Wahlmöglichkeit, und den gibt's nur für REAL ...

So also kein wichtiges Problem sondern nur ein kleiner Denkanstoß.

Grüße

Rainer

131

oscat.lib fuer PC WorX/MULTIPROG / Re: ACTUATOR_3P will nicht laufen - Weitere Infos

« am: 05. November 2012, 06:50:52 »

Hallo,

in meinem Testprogrämmchen (siehe voriges Posting) hatte ich ja auch den OSCAT ACTUATOR_3P mit laufen lassen, der sich dann nach einigen Stunden in Status 101 fest gefahren hat. Theoretisch kann man die Eingangs-Parametrierung diskutieren, aber "eigentlich" darf es keine geben, mit der das passiert. Ich hänge noch mal den Programmaufbau und einen Ausdruck des FB-Inhalts mit Debug-Werten an, muss mich dann abr erst mal um die nächste Baustelle "I-Anteil des PI-Reglers "RLT30_FB_CTRL_PI" hängt sich auf." kümmern.

Grüße

Rainer

[gelöscht durch Administrator]

132

oscat.lib fuer PC WorX/MULTIPROG / I-Anteil des PI-Reglers "RLT30_FB_CTRL_PI" hängt sich auf.

« am: 05. November 2012, 06:47:35 »

Hallo,

ich habe festgestellt, dass sich der o.g. Regler bei Betrieb mit Phoenix ILC 150 nach ein paar Stunden zuverlässig aufhängt. Nach dem Kaltstart eines Neuen Programms funktioniert zunächst alles wie erwartet, wenn ich nach ein paar Stunden wieder nachsehe hängt der Regler.

Der Effekt:
- P-Anteil funktioniert weiterhin wie zu erwarten
- I-Anteil hängt fest.

In der beobachteten Situation (Temperaturregler Zuluft, mehrere Grad Regelabweichung, ähnlich wie im Screenshot (dort aber zufällig nur geringe Regelabweichung)) krabbelt sonst der Regler-Ausgang langsam aber stetig in die richtige Richtung zur Korrektur der Abweichung, wenn der Fehler dann auftritt zappelt der Ausgang nur noch etwas hin und her, recht offensichtlich P-Regler-Reaktionen.

RESET des I-Anteils bringt die Angelegenheit meist wieder in Gang, Kaltstart der SPS zuverlässig.

Die Reglerparameter im Screenshot sind beliebige Werte, mit denen ich versucht habe, die Reaktionen zu testen, und nicht die eigentlich für die Anwendung vorgesehenen.

Ich werde parallel mal im SPS-Forum fragen, ob da jemand eine Abhilfe weiß, und mir wohl lieber erst mal selbst einen PI-Regler "bauen".

Grüße

Rainer

[gelöscht durch Administrator]

133

oscat.lib fuer PC WorX/MULTIPROG / Re: ACTUATOR_3P will auf Phoenix ILC nicht laufen - Ersatz

« am: 04. November 2012, 18:28:04 »

Hallo,

bei weiteren Versuchen blieb es dabei, der FB läuft nur "nackt" als Demo. Sowie ich zusätzlich Beschaltung für die Anwendung anbringe läuft er mit etwas Glück eine Weile, meistens aber gar nicht erst.

Da der Baustein für meine Anwendungen eh nicht besonders geeignet wäre (und der Kunde wartet)  habe ich einen Ersatz geschrieben. Um sicher zu sein, dass der dann nicht unter der gleichen, bisher unbekannten Malaise wie der OSCAT ACTUATOR_3P leidet, habe ich nur sehr elementare FU und FB benutzt. Im Demo an einem Sinusgenerator funktioniert er sehr schön, der praktische Anwendungstest an einem echten Antrieb steht noch aus. Letztlich bleibt die Frage kritisch, wie genau die etwas zusammengestoppelte Berechnung der aktuellen Funktion die tatsächliche Antriebsstellung nachbildet.

Für interessierte habe ich die Beschreibung und einen Ausdruck angehängt, ganz interessierte können sich ein gepacktes Demo-Progrämmchen für PC WORX EXPRESS Phoenix ILC hier http://www.bielefeldundbuss.de/bilder/Actuator_ab_OSCAT.zwe herunterladen und testen. Für den Test muss noch die basic_333 Lib. und für den parallel eingebauten ACTUATOR_3P die building100 Lib. eingebunden werden.

Das Demo-Programm benötigt 2 weitere selbst erstellte Funktionen, die im .zwe enthalten sind.

Evtl. eine Anregung für einen zusätzlichen, vereinfachten Actuator-Baustein in der OSCAT Lib.?

Ich bin auch gern beim Debugging des Original-ACTUATOR_3P behilflich.

Viele Grüße

Rainer

[gelöscht durch Administrator]

134

oscat.lib fuer PC WorX/MULTIPROG / Re: ACTUATOR_3P will nicht laufen wie ich es will

« am: 01. November 2012, 07:56:29 »

ist auch innerhalb der building.lib die oscat_basic 3.33 eingebunden ?
also nicht in deinen eigene projekt sondern in der building.lib selber

Hallo,
Habe das überprüft und sah im building_100 Projekt die basic_333 eingebunden, siehe Screenshot. Hab's nicht ausprobiert, aber müsste PCWORX beim build der building.lib nicht meckern, wenn die basic_333 fehlt?

optional könntest du auch mal den Code von v2.1 einbauen und testen .....

Das sagst Du dem richtigen :-/
pcworx_building_100 als Projekt öffnen, ACTUATOR_3P mit den Textzeilen aus deinem Posting ändern, build erstellen, geänderte Lib. im Anwendungsprojekt neu einbinden und sehen was passiert?

Viele Grüße

Rainer

135

oscat.lib fuer PC WorX/MULTIPROG / Re: ACTUATOR_3P will nicht laufen

« am: 31. Oktober 2012, 22:29:25 »

Hallo,

danke für die Rückmeldung!

ist die oscat_basic_333 eingebunden , wenn nicht dann unbedingt machen !

Ist eingebunden, ich benutze anderweitig verschiedene Bausteine aus der Lib.

In Help/FU steht V2.0, gleiches in der revision history des Quelltextes, in dem ich eindeutig nur die 2.0 Codestelle finde

Leider habe ich von AWL nur noch wenig Ahnung, so dass ich Probleme hätte, da herauszufinden, wo Probleme liegen. Jedenfalls ist der Baustein in meiner Testanlage anscheinend schon wieder irgendwo hängen geblieben, nach anfänglich plausibler Funktion unter Beobachtung ist es nun dort eisekalt, Positionsausgang steht auf 255 (= Maximale Heizung), aber da ist der Antrieb ganz sicher nicht hingefahren. Ein sonstiges Problem im Programm möchte ich eigentlich eher ausschließen, wenngleich die Tatsache, dass ich die Ausgänge Forcen kann und der Antrieb dann fährt, wenig aussagt. Letztlich ist nicht einmal hundertprozentig sicher, dass es nicht doch ein Anlagenproblem ist, ich hatte im Laufe der letzten grob geschätzt 10 Jahre 2 technisch vergleichbare Antriebe, bei denen durch Kondensator-Alterung die Drehrichtung nach dem Start Glücksache war. Leider ist das selbst vor Ort schwer zu beobachten, und ich sitze weit weg von der Anlage im Büro ... . Ein halbwegs sichere Testmethode wäre, einen Funktions-Baustein bastelt und anzuhängen, de auf Actuater_3P - Ausgang 255 auf das "Auf" Signal Dauerausgang gibt und auf 0 Dauersignal auf den Zu-Ausgang. Dann erkennt man das Antriebsproblem daran, dass der Antrieb bei Auftreten des Fehlers bald am falschen Anschlag hängt. Heute Abend komme ich aber nicht mehr dazu, diesen Test sicherheitshalber einzubauen.

Viele Grüße

Rainer