# Flankenerkennung und SR-Kippstufe mit CoDeSys 2.3 und WAGO Perspecto CP 57



## Exing (13 April 2015)

Hallo CoDeSys- und WAGO-Profis,

für eine größere Steuerungseinheit nutzten wir das Perspecto CP 57 von WAGO mit einem Ethernet-IO-Knoten. Das Perspecto-Display programmieren wir mit CoDeSys 2.3.9.46 (Oct. 2014 / dürfte die neueste Version sein) via ST.
Nun haben wir parallel zum PLC_PRG eine PLC_VISU_PRG zur Visualisierungssteuerung, die auf fünf externe Tasten (hoch, runter, links, rechts, OK) reagiert (auf die Touch-Funktionalität verzichten wir, weil die Steuerungen durchaus mal in den Ex-Bereich hinter eine dicke Glasscheibe kommen). Außerdem gibt es noch parallel dazu einen Bautein PLC_ZUORDNUNG_PRG, welcher die Eingänge DI1 bis DI16 in sprechende globale Variablen (wie z. B. b_ControlDown) überträgt.
Dabei treten folgende Probleme auf:
1. Über R_TRIG wollen wir die Flanke eines Tasters erkennen und entsprechend z. B. einen Bildschirm weiterschalten oder einen Wert ändern. Außerdem wird eine Variable b_VisuActive (lokal) bei einer steigenden Flanke einer lokalen Variable aus PLC_PRG auf TRUE gesetzt, um die Visualisierung aktiv zu schalten. b_VisuActive wird nur hier geschrieben, nirgends anders (auch nicht auf FALSE gesetzt); ansonsten wird sie nur gelesen. Nun haben wir festgestellt, dass bei jedem Programmzyklus eine steigende Flanke erkannt wird, auch wenn der jeweilige Taster die ganze Zeit gedrückt gehalten wird und z. B. b_ControlDown ständig TRUE ist (Es gilt in diesem Beispiel: b_Down_RE(CLK:b_ControlDown)). Auch b_VisuActive flackert ständig (mal TRUE, mal FALSE), obwohl die lokale Variable in PLC_PRG TRUE bleibt. Warum ist das so? Werden bei jedem Programmdurchlauf die Variablen wieder auf Ihren Initialisierungswert gesetzt? (soweit ich weiß, doch nicht, oder?) Werden die Variablen als RETAIN PERSISTENT oder global deklariert, gibt es keine Probleme...
2. Um den oben beschriebenen Fehler zu finden, haben wir b_VisuActive nicht mehr über eine R_TRIG-Instanz gesetzt, sondern über eine SR-Kippstufe (SR). Von dieser gibt es - im Gegensatz zu R_TRIG - nur eine Instanz. SET läuft über die Variable aus dem Hauptprogramm, RESET über eine Variable, die wir explizit mit FALSE initialisieren und die niemals auf TRUE gesetzt wird. Da tritt jetzt das Phänomen auf, dass der Ausgang der SR-Kippstufe und damit b_VisuActive sich laufend mit dem SET-Eingang ändert und niemals TRUE bleibt. Dabei bleibt die SET-Eingangsvariable (aus PLC_PRG) immer TRUE. Nutzen wir stattdessen eine globale Variable für SET, die dann in PLC_PRG gesetzt wird, ändert sich gar nichts. Woran kann das liegen?
3. Ich habe jetzt gelesen, dass bei einer Task-Konfiguration kein PLC_PRG existieren darf. Stimmt das? Kann das die Ursache all unserer Probleme sein?

MfG
Exing


----------



## PN/DP (13 April 2015)

Ich kenne Dein System nicht, doch für mich klingt das wie der Klassiker, daß Deine "lokalen" Variablen TEMP-Variablen sind - die können sich nichts merken.

Harald


----------



## Exing (13 April 2015)

Hallo Harald,

danke für Deine erste Antwort. Allerdings sind die Variablen ganz klar NICHT als VAR_TEMP deklariert!

MfG
Exing


----------



## PN/DP (13 April 2015)

Wie und wo sind sie denn deklariert?

Harald


----------



## Exing (13 April 2015)

Im Deklarationsteil des Bausteins PLC_VISU_PRG zwischen VAR und END_VAR.

MfG
Exing


----------



## Ghosty (13 April 2015)

Versuchs mal mit VAR RETAIN.


----------



## Exing (13 April 2015)

Hallo Ghosty,

ja, mit VAR RETAIN funktioniert es; genauso wie mit VAR GLOBAL (dann natürlich nicht im Baustein, sondern unter Globale Variablen). Allerdings hatte ich es so verstanden, dass die Variablen beim normalen Programmdurchlauf erhalten bleiben - oder ist das CoDeSys-Handbuch da einfach missverständlich geschrieben?
Noch ein Update zu meinem dritten Punkt ganz oben: Ich hatte den Baustein PLC_PRG mal umbenannt -> leider keine Verbesserung . Wir werden jetzt mit RETAIN- bzw. globalen Variablen arbeiten...
Schon mal Danke für Eure Hilfe.

MfG
Exing


----------



## Exing (17 April 2015)

Hallo Leute,

Kommando zurück, nichts geht hier. Brachte die Umstellung auf rein globale Variablen kurzfristig Besserung, müssen wir jetzt ALLES auf RETAIN-Variablen umstellen.
Problem: Wir initialisieren einige Variablen, die wir als Grenzwerte nutzen (diese Grenzwerte sollen später dynamisch werden, daher kein CONSTANT möglich!) mit z. B. 1 und 3. Als "normale" globale Variablen (also weder Retain noch Persistend noch Constant) lief das auch ganz gut - bis wir das Programm erweitert haben. In Bezug auf diese Grenzwerte haben wir NICHTS geändert, es sind nur mehr Variablen hinzugekommen. Jetzt werden die Variablen aber einfach so mit 0 initialisiert! Mit Retain und Persistent geht es - ich frage mich aber ehrlich gesagt, ab wann das da auch nicht mehr geht und die SPS sogar die Konstanten ändert...
Oder kann das mit dem Überschreiten der maximalen Monitoring-Variablen zusammenhängen?
Also, Wago- und Codesys-Profis, habt Ihr die Erfahrung auch schon mal gemacht, das die Initialwerte einfach geändert worden sind? Ich meine, eine SPS hat doch kein Recht auf eine eigene Meinung, oder?

MfG
Exing


----------



## Exing (19 Mai 2015)

Hallo Leute,

für die, die es interessiert. Das Problem ist gelöst. Die Lösung findet Ihr hier: http://www.sps-forum.de/wago/76624-seltsames-verhalten-von-variablen-und-analoge-eingaenge.html

MfG
Exing


----------

