Unerklärliche Funktion FC226

W

werker

Level-1
Beiträge
31
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 

Anhänge

Zuviel Werbung?
-> Hier kostenlos registrieren
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.

[TABLE="width: 498"]
[TR]
[TD="width: 11, bgcolor: white"][/TD]
[TD="width: 486"] 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.[/TD]
[/TR]
[/TABLE]


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.

[TABLE="width: 498"]
[TR]
[TD="width: 11, bgcolor: white"][/TD]
[TD="width: 486"] 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.[/TD]
[/TR]
[/TABLE]
 
Hallo
Vielen Dank für die ausführliche Antwort.

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

Wäre das eine Lösung

Gruß
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
Zum Vergrößern anklicken....

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. ;)
 
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
 
Zuletzt bearbeitet:
@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.
Zum Vergrößern anklicken....

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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
@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:
  1. 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).
Zum Vergrößern anklicken....
Da das ganze dann eben nicht über den Lokaldatenstack abläuft, kann es auch zu keinem Zeitpunkt "zufällige" Werte geben.

Mfg
Manuel
 
Zuletzt bearbeitet:
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.
Zum Vergrößern anklicken....

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. :ROFLMAO:
 
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
 
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
 

Similar threads

O
Sonstiges Der Scalance XB208 nutzt automatisch die IP XXX.XXX.XXX.251 (Gelöst, Benutzerfehler)
Antworten
13
Aufrufe
1K
Blockmove
B
H
Sonstiges Veränderliche Wiederstände mit S7 1200 auslesen
Antworten
8
Aufrufe
772
Holzmichl
H
S
TIA Zeitmessung S1200
Antworten
12
Aufrufe
777
Botimperator
Botimperator
N
Step 7 Erste Übung mit UDT-Array (Fehler beim CPU Start)
2
Antworten
33
Aufrufe
4K
Peter Wahlen
Peter Wahlen
P
TIA Daten in Variablen oder Datenbaustein abspeichern - Unterschied
Antworten
9
Aufrufe
1K
Patrick_L
P
Zurück
Oben