FT_PT1: Hängt auf Phoenix ILC 155

[rrbd]

Hallo,

heute konnte ich mehrfach ein Hängenbleiben des o.g. Bausteins erleben. Eine ganze Weile arbeitete er zuverlässig, aber in bestimmten Situationen bleibt der Ausgang auf seinem Wert stehen und folgt dem Eingang nicht auf 0. Alle Details im angehängten PDF. Sehr ärgerlich, da ich eigentlich hoffte, mit diesem Filter die Probleme aus "Limitierung für FILTER_I bei großen Zeitkonstanten" http://www.oscat.de/community/index.php/topic,1914.msg10043.html#msg10043 umgehen zu können

Bisher hatte ich noch keine Zeit, das Problem in einer Testumgebung auf dem Schreibtisch zu reproduzieren, problematisch ist, dass der Fehler auch an der realen Anlage nicht hundertprozentig reprodzierbar ist. Hat jemand eine Idee?

Grüße

Rainer

Nachtrag 2013-06-18: Falschen Anhang ersetzt durch  2013-06-17_Filterproblem.pdf

[gelöscht durch Administrator]

[rrbd]

Weitere Tests (abwarten und Tee trinken) ergaben dass sich der Filter regelmäßig aufhängt, ich muss die Anlage einfach nur eine Weile laufen lassen, es hängen sich immer beide verwendeten Filter auf, (habe allerdings noch nicht genauer untersucht, ob sie EXAKT gleichzeitig versagen.

[peewit]

hallo

hast du denn schon mal die oscat basic 3.33 ausprobiert ?

[rrbd]

Hm, ich dachte ich hätte genau diese Lib? Ist jedenfalls aus einer pcworx_basic_333.zip, heruntergeladen im August 2012. Und mein Anhang war Unsinn, hae die falsche Datei erwischt, so dass mein Ausgangsposting evtl. reichlich unverständlich war, ich ersetze ihn gleich.

[rrbd]

Und ich habe mal ein Miniprogramm zum testen auf einer ILC 130 gestartet, ein Sinusgenerator lässt am Eingang einen Sinus-Wert wert von 1000 +- 20 mit 10 Minuten / Sinusdurchlauf eiern, mal sehen, was passiert.

[rrbd]

Testprogramm ist jetzt 7h gelaufen ohne dass die Filter hängen geblieben sind, so einfach ist's also (nicht ganz unerwarteter weise) leider nicht. Nun also nächster schritt, Testlauf mit vollständigem Programm + Testsinus.

Nachtrag 2013-06-18 17:35:25
=======================
Ich habe mal das Innenleben der Filter "FT_PT1"  im Debugmodus angesehen. Die Ursache des Problems dürfte sein, dass ich in der
Zeile 3 bei "tx:= T_PLC_US.T_PLC_US;"
in der SPS der Anlage (an der ich seit gestern, nachdem der Filterausgang stecken geblieben ist, nichts mehr geändert habe), ein Konstantwert steht.
In meinem Testaufbau mit einer IKC 130 ETH auf dem Schreibtisch läuft der Zahlenwert (wie in der letzten Zeile 13) weiter. Nun ist die spannende Frage warum (T_PLC_US() keine Werte liefert ...?). Wenn das nicht offensichtlich ist könnten wir vielleicht eine Teamviewer-Telefonsitzung (0531 270 20 35) machen? Eine Ahnung sagt mir, dass das Phänomen natürlich nicht bei meinem Testaufbau auftreten wird, deshalb lasse ich die Anlagen-SPS bis morgen Früh erst mal ungeändert, muss dort aber natürlich auch bald wieder eine Funktionierende Lösung "hinstellen". Ich bin meistens, auch zu nichtnormalen Arbeitszeiten, erreichbar.

Grüße

Rainer

[rrbd]

Falsch gedacht. Um einen normalen Testbetrieb zu simulieren habe ich etwas in der Webvisualisierung gespielt, am Sinus die Festwerteingänge durch Variable ersetzt und das geänderte Programm noch mal im laufenden Betrieb 'runter geschoben, anschließend liefen die Filter noch, aber ein paar Minuten Später war's vorbei. Phänomen wie beschrieben, im Debug-Modus sehe ich die Zeit im Filter nicht mehr laufen. Habe natürlich keine Ahnung, ob die Manipulationen etwas mit mit dem Problem zu tun haben oder ob sich das einfach zufällig ergab. Ich kann das Programm gern mal für Testzwecke packen.

Grüße

Rainer

[peewit]

hallo

es wäre nicht schlecht zu wissen ob das problem auch ohne deine manipulationen auftritt !

wenn es wieder nicht vollständig klappt, dann mach mir bitte ein möglichst einfaches testprogramm bei dem der fehler
schnell auftritt und dann kann ich das problem hoffentlich auch relativ schnell finden

[rrbd]

Hallo,
ich arbeite an dieser Frage.
Das Testprogramm, mit dem das Problem auftrat, habe ich dir gerade zum Download auf einen Server http://www.bielefeldundbuss.de/OSCAT/Filtertest130618_01.zwe hochgeladen, es ist aber nicht einfach. Da ist die problematische Stelle im POE RLT30 (2 Filter FT_PT1).

Ich werde jetzt noch mal probieren, ob das kleine Programm mit den Manipulationen zum Aufgeben bringen kann.

Grüße

Rainer

[rrbd]

Sieht nicht so aus, wirst Dir das große mal vornehmen müssen.

[rrbd]

So, als quasi abschließende Untersuchung habe ich in das Programm, das ich zum Download bereit gestellt habe, noch mal einen T_PLC_US "zum Angucken" eingebaut. Der dann natürlich auch aufhört, werte auszugeben. Im Innern von T_PLC_US wird tx dann auch nicht mehr geändert, was immer das heißt.
Mein Ablauf, den Stillstand zu provozieren: Ich Force/Überschreibe die Eingänge des Sinusgenerators mit kleinen änderungen, führe dann mit leicht veränderten Werten dieser Variablen noch mal ein "Make" durch und schicke im laufenden Betrieb das neue Programm zur SPS. Zwischendurch (nach Eingabe Passwort "5555") spiele ich noch immer wieder mal mit den Knöpfen und Handeingaben im L30.TEQ (Das Web-Projekt findet sich Im Unterordner "WEB". Und meistens bleibt dann innerhalb von wenigen Minuten nach dem neuen Programmload zur SPS T_PLC_US stehen.

Ob es da einen Zusammenhang mit den von mir beobachteten "ACTUATOR_3P will nicht laufen" und "I-Anteil des PI-Reglers "RLT30_FB_CTRL_PI" hängt sich auf." gibt?

BTW, in der mir vorliegenden "oscat_basic333_de.pdf" heißt es:
21.14. T_PLC_US
Type Funktion : DWORD
Output DWORD (SPS Timer in Mikrosekunden)

Tatsächlich ist der Ausgangswert aber ein UDINT

Ich fürchte, mehr Informationen zum Problem kann ich aus eigener Kraft momentan nicht beisteuern.

Grüße

Rainer

[peewit]

hallo


was du eventuell noch machen könntest

wenn der t_plc_us nichts mehr macht dann den baustein im online modus betrachten und von der variablentabelle einen screenshot machen

[rrbd]

Hallo,

als Anlage habe ich ein paar herauskopierte Daten beigefügt.

Dabei habe ich gleich festgestellt, dass das Problem evtl noch ernster als zunächst gedacht ist. Zum einen habe ich den Filter noch an einer anderen Stelle verwendet, ist nur ein Anzeigewert, aber ich hatte mich da auch schon mal gewundert.
Der T_PLC_US ist noch an 14 anderen Stellen irgendwo "verbaut", wenn ich nichts übersehen habe aber nur in nicht verwendeten OSCAT-Funktionen (Siehe Tabelle "WoNochVerwendet"), so dass mein Ansatz, mir notfalls einen eigenen Tiefpassfilter zu schreiben, doch Erfolg verspricht.

Grüße

Rainer
 

[gelöscht durch Administrator]

[rrbd]

So, mein eigener Filter ist fertig. Da Problem hier habe ich (wie bei allen meinen Bausteinen mit integratoren) mit einem externen 5Hz-Taktgeber umgangen (für meine Gebäudetechnischen Anwendungen ist die Reaktionszeit damit mehr als ausreichend), zum FT_PT1 - Funktionsumfag habe ich noch 2 Features eingebaut:

a) Freigabe
Hintergrund: Diverse Analogeingänge übergeben bis nach dem ersten Zyklusdurchlauf unsinnige Werte, so fängt derzeit beim alten K&P-CU-250-Temperaturfühler die Werteübergabe mit -250°C an, wenn dass der erste Wert ist, den die meisten Filter sehen, ist das auch der Anfangs-Ausgabewert, und wenn ich dann eine Zeitkonstante von mehreren Stunden habe ... . Mein Filter fängt erst an zu filtern, wenn die Freigabe auf 1 ist.

b) Definierter Anfangs-Ausgangswert.
Solange "a" fehlt, wird ein weiterer Eingangswert direkt auf den Ausgang durchgeschaltet. Je nach Beschaltung von Prozesseingang, Ruheausgangswert und Freigabe lassen sich damit unterschiedliche definierte Ausgangssituationen herstellen.

Da der Eigenbau meine Bedürfnisse besser erfüllt als die OSCAT-Filter werde ich die O.-Filter bei Gelegenheit durchgehend ersetzen, das Im Ursprungsposting angegebene Problem spielt für mich keine Rolle mehr.

Grüße

Rainer

[peewit]

hallo

in dem file "T_PLC_US.ods" steht oscat_basic.3.30 drinnen ?

hast du nun die basic 3.30 oder die basic 3.33 eingebunden


du solltest unbedingt die basic 3.33 verwenden