ACTUATOR_3P will nicht laufen

[rrbd]

Hallo, irgendwie bin ich zu dusselig, den Actuator_3P (version 2.0) auf einer Phoenix ILC150 zum laufen zu bringen. bestenfalls bleibt er (mit den verschiedensten Konfigurationen) mit Öffnung 0 und keinerlei Ausgangsansteuerung auf Status 103 stehen, mit anderen Konfigurationen macht er das "einfach so". Es ist mit nicht gelungen

Die Aufgabenstellung: Heizungsmischer 230V 3-Punktansteuerung, 100s Laufzeit, soll auf gewünschte Stellung 0 ... 255 entsprechend 0% ... 100% gefahren werden. Typischer Anlagenaufbau ohne Endlagenkontakte oder sonst etwas, je weniger sonstigen "Zusatzfunktionen außer der Kernanforderung" ("Test") veranstaltet werden, desto besser.

Wie es scheint, seh' ich den Wald vor lauter Bäumen nicht, wer weiß Rat?

Viele Grüße

Rainer

[gelöscht durch Administrator]

[Vaninger]

Hallo rrbd,

hatte mal das gleiche Problem, such mal nach "Actuator 3P - Funktioniert der Baustein unter PCWorx?" hier im Forum, vielleicht hilft dir das...
Habe den Baustein auch im Einsatz, leider hängt sich dieser ab und an auf und fährt entweder komplett auf oder zu...

Schöne Grüße
Daniel

[rrbd]

Hallo, danke für den Hinweis, habe das Thema "irgendwie" übersehen. Das klingt ja nicht gut, solche Ausfälle kann ich mir gar nicht leisten (Heizregister eingefroren - Produktion steht still ...), dann muss ich mir wohl selbst was "bauen".

Grüße

Rainer

[rrbd]

Manchmal ist man aber auch ... Ich schätze, ich habe doch einfach nie die passige Kombination der Eingangsbeschaltung verwendet. Nach Berücksichtigung der Hinweise auf http://www.oscat.de/community/index.php?topic=1193.0 probiere ich's erst mal mit diesem Baustein.

Ein Problem mit dem Start-Autotest bleibt allerdings. In der Mehrzahl meiner Anwendungen wäre der Automatische Test beim Programmstart extrem störend, da die Anlage dadurch in eine erschwerte Startposition gebracht wird (oder zerstört, bevor's los geht. Beispiel: Lüftungsinbetriebnahme im Winter, ACTATOR_3P treibt das Heizwasser-Ventil an. Wenn das einmal Aufgefahren wurde, ist im Heizkreis mächtig warmes Wasser, Zuluft zu warm, Regler fährt Ventil zu, Überschwinger, zu kalt, Frostschutzauslösung (wenn nicht schlimmeres). Klaro kann ich Anlagenstart (Lüfterstart) erst  sowie Durchschaltung der 3-Punkt-Ausgänge auch erst nach Testende des Letzten Antriebs aktivieren (ich brauche diesen Test nie),  aber das ist doch eher umständlich. Gibt es keine einfachere Lösung?

Grüße

Rainer

[rrbd]

Hallo,

so recht glücklich bin ich mit dem Baustein bisher aber nicht.  Nun steht er schon ca. 10 Minuten in Status 101, keine Ahnung ob das noch einmal endet. Ich hatte halt "Jokushalber" den Eingang "T_CAL" unbeschaltet belassen, also war der Default-Wert 600 (was auch immer) voreingestellt. Im Handbuch wird noch eine "CAL_RUNTIME" beschrieben, die ich aber als Eingang nicht finde, vermutlich ist "T_CAL" bemeint?!

Ich weiß nicht recht, welche Anwendung bei der Entwicklung angedacht war, aber irgendwie bin ich verwirrt und stelle mir vor, ich hätte ein Auto, das alle 600 weißnichtwas in voller Fahrt die Lenkung kalibriert und dafür einmal beide Anschläge testet ;-).

Kann mir jemand sagen, welche Einheit der Defaultwert von "T_CAL" hat und ob tatsächlich "T_CAL" =  "CAL_RUNTIME"?

Danke schon mal


Rainer

[peewit]

hallo

ich habe mal nachgesehen inwieweit der baustein sich vom codesys referenzcode unterscheidet
prinzipiell ist der identisch, ihr solltet aber mal genau nachsehen

1. ist die oscat_basic_333 eingebunden , wenn nicht dann unbedingt machen !
    (gemeint ist, innerhalb der building.lib als sub lib !)

2. der baustein actuatur_3p hat bei euch welche version 2.0 oder 2.1
    es sollte eigentlich 2.0 sein, damit dieser dem referenzcode entspricht
    ich kann leider nicht mehr nachvollziehen welchem ursprung die v2.1 hat


bei der v2.1 gibt es folgenden code

(* adjust position if end switch is active *)
IF SWITCH_AVAIL AND END_POS THEN
   POS := SEL(POS > BYTE#127, BYTE#0, BYTE#255);
   last_cal := tx;
END_IF;

bei der v2.0 gibt es folgenden code

(* adjust position if end switch is active *)
IF SWITCH_AVAIL AND END_POS THEN
   POS := SEL_BYTE(POS > BYTE#127, BYTE#0, BYTE#255);
   next_cal := tx + T_CAL;
END_IF;

es kann auch sein das die v2.1 eine noch nicht veröffentlichte anpassung ist

schaut bitte mal nach .....

[rrbd]

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

[peewit]

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

-> die building bibliothek selber als projekt öffnen und dann im projekt oben schauen welche bibliothek hier wiederum eingebunden ist

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

[rrbd]

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

[rrbd]

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]

[rrbd]

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]

[peewit]

hallo

kannst du eine einfaches testprogramm schreiben, das reproduzierbar ohne manuellen eingriff nach einer gewissen zeit (möglichst schnell) zum beschriebenen problem führt !

speichere bitte das projekt unter "speichern unter" -> Dateityp "gepackte Projektdateien"
und komprimierungsoptionen "anwender bibliotheken packen" und zwischencode packen
diese einzelne datei mir bitte zukommen lassen (online oder per pn)

denn dann kann ich dir wahrscheinlich helfen

[rrbd]

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

[rrbd]

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

[peewit]

hallo

das die beschreibung nicht ganz hilfreich ist, das mag sein
und die logik ist auch sehr fragwürdig .....

aber ich glaube dein grundproblem können wir beheben...

der baustein geht bei dir immer in den kalibriermodus und bleibt dort hängen, da dieser vorgang nie beendet wird.
wieso kommt es überhaupt soweit ?

Es gibt ein paar eingangsparameter die wenn sie nicht beschaltet werden einen defaultwert benutzen

VAR_INPUT CONSTANT
   T_RUN : TIME := t#60s;
   T_EXT : TIME := T#10s;
   T_CAL : TIME := t#600s;
   T_DIAG : TIME := T#10d;
END_VAR

das heisst standardmaessig wird die auto_kalibierung nach 600sek. aktiv
das passiert leider unabhängig vom parameter "SWITCH_AVAIL", denn es reicht wenn die T_CAL > T#0s ist
die Kalibierung wird dann nicht beendet weil der Endschalter "END_POS" nie erreicht wird bzw. "SWITCH_AVAIL" ja gar nicht aktiv ist

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