Unerklärliche Funktion FC226

werker · 15 März 2013

Hallo,

bin bei der Fehlersuche in einem Projekt auf folgendes Phänomen gestoßen:

Nach meinem Verständnis des FC226 darf der Merker 53.7 nur kommen, wenn der Merker 53.6 da war.

Sarek · 15 März 2013

#STOM ist eine OUT-Variable
=> diese muß beschrieben werden sonst kann "Schrott" drinstehen (aus L-Stack)

Sarek · 15 März 2013

siehe auch STE7-Hilfe

Wichtiger Unterschied bei Ausgangsparametern von FC und FB
In Funktionsbausteinen (FB) wird beim Zugriff auf Parameter die Kopie des Aktualparameters im Instanz-DB verwendet. Wird beim Aufruf eines FB ein Eingangsparameter nicht übergegeben bzw. im Baustein ein Ausgangsparameter nicht beschrieben, so werden die im Instanz-DB noch vorhandenen älteren Werte weiter verwendet (Instanz-DB = Gedächtnis des FB).
Funktionen (FC) haben kein Gedächtnis. Die Versorgung der Formalparameter ist deshalb im Gegensatz zum FB nicht optional, sondern zwingend erforderlich. Der Zugriff auf FC-Parameter erfolgt über Adressen (bereichsübergreifende Zeiger). Wird als Aktualparameter ein Operand aus dem Bereich Daten (Datenbaustein) oder eine lokale Variable des rufenden Bausteins verwendet, wird für die Parameterübergabe eine Kopie des Aktualparameters in den Lokaldaten des rufenden Bausteins temporär gespeichert.

Achtung
Wird in einem solchen Fall ein OUTPUT Parmeter in einem FC nicht beschrieben, können die ausgegebenen Werte zufällig sein!
Der für die Kopie bereitgestellte Bereich in den Lokaldaten des rufenden Bausteins wird mangels Zuweisung an den OUTPUT Parmeter nicht beschrieben und bleibt somit unverändert. Damit wird zufällig der in diesem Bereich stehende Wert ausgegeben, da Lokaldaten nicht automatisch mit z. B. 0 vorbelegt sind.

Beachten Sie deshalb Folgendes:

Initialisieren Sie wenn möglich OUTPUT Parameter.
Setze- und Rücksetze-Befehle sind VKE-abhängig. Wird mit diesen Befehlen der Wert eines OUTPUT Parameters ermittelt, wird bei VKE = 0 kein Wert gebildet.
Achten Sie darauf, dass - unabhängig von allen möglichen Programmpfaden innerhalb des Bausteins - die OUTPUT-Parameter auf jeden Fall beschrieben werden. Beachten Sie hierbei insbesondere Sprungbefehle sowie den ENO-Ausgang in KOP und FUP. Denken Sie auch an BEB und die Wirkung der MCR-Befehle.

Hinweis
Bei OUTPUT-Parametern eines FB bzw. INOUT-Parametern eines FC und FB können die ausgegebenen Werte zwar nicht zufällig sein, da hier ohne Beschreibung des Parameters der alte Ausgangswert bzw. der Eingangswert als Ausgangswert erhalten bleibt. Dennoch sollten Sie auch hier die oben gegebenen Hinweise beachten, um nicht unbeabsichtigt "alte" Werte weiter zu verarbeiten.

werker · 15 März 2013

Hallo
Vielen Dank für die ausführliche Antwort.

UN #E1
UN #E2
R. #STOM
SPA M001

Wäre das eine Lösung

Gruß

borromeus · 15 März 2013

Nein!
Wenn man davon ausgeht, dass der Programmierer die richtige Idee hatte, aber einfach nur nicht programmieren konnte sollte man aus dem FC einen FB machen und mit IDB aufrufen.

Ralle · 15 März 2013

Du kannst auch #STOM zu eier INOUT-Variablen machen, dann wird deren Zustand praktisch in der außen angelegten Variablen gespeichert. Ich nutze bei FC fast nur IN und INOUT, um genau das von Sarek dargelegte Problem zu umgehen.

PS. Dann darf aber natürlich außen an STOM auch keine lokale Variable angelegt werden!!!! Bei dir, mit einem Merker, sollte es funktionieren.

borromeus · 15 März 2013

Hast Du Angst vor DB's, Ralle?

Ralle · 15 März 2013

borromeus schrieb:
Hast Du Angst vor DB's, Ralle?

LOL, in gewissem Sinne schon, besonders, wenn es auch ohne geht! Die vielen IDB, das ständige "neu generieren" nervt ein wenig.

Ich nutze FB recht sparsam, stimmt, wird aber langsam mehr.

werker · 15 März 2013

Ich muß gestehen, da fehlen mir Einiges an Wissen.
Laut Analyzer, dachte ich schon, daß an dem Baustein etwas faul ist.
Es gibt noch einen zweiten Fehler, daß sporadisch die erwartete Temperaturänderung nicht erfolgt.
Deshalb steht in Moment 0 am Baustein.
(Betriebselektriker)
Gibt es eine einfache Lösung

Dieter

Sarek · 15 März 2013

Wobei man aber nicht genau weiß was der Baustein eigentlich machen soll,
bzw. das bisher programmierte überhaupt richtig ist.

Soll #STOM speichernd sein wenn er aufgetreten ist und dann nur mit M0.3 gelöscht werden?
Soll #STOM auch bei E1=1 (Temperatur einfrieren) gelöscht werden?
Soll #STOM auch bei E2=0 (Temperatur nicht vergleichen) gelöscht werden?

der M0.3 hat auch nichts im Baustein zu suchen, er sollte auch nach aussen gelegt werden.

werker · 15 März 2013

Die erste Bedingung.
Was mir noch eingefallen ist , der FC 226 wird in vier anderen Zonen unter gleichen Bedingungen aufgerufen. Dort taucht der Fehler nicht auf.
Dieter

Ralle · 15 März 2013

werker schrieb:
Die erste Bedingung.
Was mir noch eingefallen ist , der FC 226 wird in vier anderen Zonen unter gleichen Bedingungen aufgerufen. Dort taucht der Fehler nicht auf.
Dieter

Ja, das ist durchaus möglich, im Siemenstext steht ja auch sinngemäß "kann das Ergebnis zufällig sein". Das liegt daran, dass das Ergebnis ja im lokalen Speicher liegt. Wenn nun keine andere Funktion im Programm genau diesen lokalen Speicher auch mit irgendwelchen Daten beschreibt, dann greift deine Funktion beim nächsten Aufruf tatsächlich wieder auf dieses Bit zu und das ist dann auch 0 oder 1 wie vorher. Sicher kann man aber nicht sein, daher geht es halt manchmal und manchmal nicht.

MSB · 15 März 2013

Also im Prinzip ist der Beitrag von Sarek zwar richtig, aber:

Wenn an einem FC an einer Variable ein E, A, M, oder DBX(B,W,D) steht, dann ist letzten Endes jede Variable her vom Verhalten IN-OUT.
Lediglich beim Vollqualifizierten DB-Zugriff ala DB10.DBX10.0 wäre das ein Problem.

Also wie auch immer, das Problem liegt 100% sicher nicht an der Programmierart der OUT-Variable "STOM".

P.S. Warum steht hier: http://support.automation.siemens.com/WW/view/de/189227

Mfg
Manuel

Ralle · 15 März 2013

@MSB

Ich kann nicht nachvollziehen, was genau du meinst.

Achtung
Wird in einem solchen Fall ein OUTPUT Parmeter in einem FC nicht beschrieben, können die ausgegebenen Werte zufällig sein!
Der für die Kopie bereitgestellte Bereich in den Lokaldaten des rufenden Bausteins wird mangels Zuweisung an den OUTPUT Parmeter nicht beschrieben und bleibt somit unverändert. Damit wird zufällig der in diesem Bereich stehende Wert ausgegeben, da Lokaldaten nicht automatisch mit z. B. 0 vorbelegt sind.

Das hier sagt eigentlich alles aus.

Dazu kommt noch der Hinweis, das "S" und "R" bei VKE = 0 nichts bewirken, also einer Output-Variable nichts zuweisen.
Genau das passiert im FC des TE.
Demzufolge ist jede Outputvariable, der nicht explizit im FC etwas zugewiesen wird unbestimmt.
Im günstigaten Fall belibt der Wert der letzten Zuweisung erhalten, wenn kein anderer Baustein die Lokaldaten verändert.
Dann scheint alles normal zu funktionieren. Eine ganz netter Fallstrick; leider.
Das liegt natürlich daran, wie man das im FC programmiert, aber was da außen an der Variablen anliegt, spielt m.E. nach keine Rolle.
Der von dir verlinkte Beitrag sagt das ja auch aus.

MSB · 15 März 2013

@Ralle
Elementare Parameter die mit EAM und einfachen DB Zugriffen beschrieben werden landen eben NICHT im Lokalstack, und sind somit auch nicht davon betroffen.
Diese werden direkt mit P#EAMDBX übergeben, somit wird innerhalb des FC DIREKT auf den jeweiligen Operanden oder auch gelesen.

Siehe:

Der elementare Formalparameter wird mit einem Merker, einem Ein- oder Ausgang aus dem Prozessabbild oder aus dem Lokaldatenstack (L-Stack) des aufrufenden Bausteines versorgt.
In diesem Fall arbeitet der Code der Funktion mit einem bereichsübergreifenden Zeiger direkt(!) auf diesen elementaren Aktualparametern (z.B. P#E0.0, P#M0.0).

Da das ganze dann eben nicht über den Lokaldatenstack abläuft, kann es auch zu keinem Zeitpunkt "zufällige" Werte geben.

Mfg
Manuel

Ralle · 15 März 2013

Ahhh, hier steht es ja auch in Sareks Auszug aus der Step7 Hilfe:

Wird als Aktualparameter ein Operand aus dem Bereich Daten (Datenbaustein) oder eine lokale Variable des rufenden Bausteins verwendet, wird für die Parameterübergabe eine Kopie des Aktualparameters in den Lokaldaten des rufenden Bausteins temporär gespeichert.

Das gilt also für DB-Zugriffe (qualifiziert) und Lokaldaten des aufrufenden Bausteins.

Dann ist im Falle des TE (der hat einen Merker verwendet) tatsächlich die Ursache eine andere. Wobei man nun wieder neu suchen muß...

Ich heut nicht mehr, ich gehe heute zu einem echten kanadischen Eishockeyspiel.

thomas_1975 · 15 März 2013

Ich glaub dein Bock liegt schon in DB150.DBW12, wo und wie wird das gebildet ?

gruß Thomas

werker · 17 März 2013

Hallo
Jetzt habt ihr mich aber schwindelig geschrieben. Ist es richtig, nur wenn #E2 da ist, kann #STOM kommen..., können wir nochmal neu anfangen ?
Dieter

bike · 17 März 2013

Ja so ist es.
Der SPS Analyser gibt nicht immer alles wieder, das ist dir klar?
Ist mir auch schon passiert,dass ich mich auf den Analyser verlassen habe und dieser ab und an eine Impuls nicht mitgeschrieben hat.
Wobei du nicht so echt genau geschrieben hast, welches Problem an der Anlage besteht.

Schreib dir eine Fangschaltung, dann bist du sicher, da diese ja ebenfalls zyklisch abgearbeitet wird

bike

thomas_1975 · 17 März 2013

Okay,
also du hast schon recht, #Stom kann seinen Zustand eigentlich nur ändern wenn:
1. m0.3 ( reset ) zwingt #stom nach log.0 voraussetzung ist natürlich, das im gleichen Zyklus nicht m53.6
auf high zur Prüfung ist. Denn wenn dieser auf High ist würde #stom erst rückgesetzt werden und dann in mit m53.6 in die nächste Prüfung gehen.

Code:

U M 0.3 M0.3 -- Störung quittieren  //bei log.1
R #STOM                     //rücksetze stom
UN #E1                        //und nicht In E1 ( m53.5 )
UN #E2                        //und nicht In E2  ( m53.6 )
SPB M001                    //Sprung zum beenden
U #E1                         //und E1
SPB M002                    //Sprungziel m002
U #E2                          //und E2
SPB M003                    //Sprungziel m003
M002: L #AKT_TEMP    //Marke m002 laden der aktuellen Temperatur
L #DT_WERT                //lade in DT_Wert ( in diesem Fall 10 )
+I                                //addiere Int
T #VERG_TEMP            //transfer in diesem Fall nach mw192
SPA M001                    //Sprung zum beenden
M003: L #AKT_TEMP    //Marke m003 laden der aktuellen Temperatur
L #VERG_TEMP            //Lade Wert in diesem Fall aus mw192
<I                               //vergleich #akt_temp ( Db150.DBW12 ) < #VERG_TEMP ( mw192 )
= #STOM                    //zuweisen von #stom
M001: NOP 0

Ah eben, lese ich bike´s beitrag, kenne den Analyser nicht.
Die Auswertung des Analysers hat mich halt extrem geschickt, da DB150.DBW12 in der Auswertung meist gar nicht geschrieben wird.
Das Problem das der Ersteller hat, ist imho M53.7 nimmt wird willkürlich High ohne die Auswertung durch M53.6 angestossen zu haben.
Der Analyser gefällt mir , wenn es funzt jedenfalls.

gruß Thomas

Unerklärliche Funktion FC226

Level-1

Anhänge

Level-2

Level-2

Level-1

Level-1

Super-Moderator , User des Jahres 2006-2007

Level-1

Super-Moderator , User des Jahres 2006-2007

Level-1

Level-2

Level-1

Super-Moderator , User des Jahres 2006-2007

Level-3

Super-Moderator , User des Jahres 2006-2007

Level-3

Super-Moderator , User des Jahres 2006-2007

Level-1

Level-1

Level-1

Level-1

Similar threads

Wir schützen deine Privatsphäre