IN-Variable im Baustein setzen?

kiestumpe

Level-1
Beiträge
726
Reaktionspunkte
84
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

der folgende Code verwirrt mich:

Code:
 U     #Temp_OK
  R     #Temp_OK

Temp_OK wurde im Baustein als IN-Variable deklariert. Beim Aufruf wird ein Merker aufgeschaltet: "VE_V81_Temp_OK"
Der Baustein schafft es tatsächlich den Merker "VE_V81_Temp_OK" zurückzusetzen - wie kann das sein? Warum läßt Step7 überhaupt das Rücksetzen zu?
 
Hallo,

der folgende Code verwirrt mich:

Code:
 U     #Temp_OK
  R     #Temp_OK

Temp_OK wurde im Baustein als IN-Variable deklariert. Beim Aufruf wird ein Merker aufgeschaltet: "VE_V81_Temp_OK"
Der Baustein schafft es tatsächlich den Merker "VE_V81_Temp_OK" zurückzusetzen - wie kann das sein? Warum läßt Step7 überhaupt das Rücksetzen zu?




Das Eingangsabbild wird beim Aufruf EINMAL eingelesen und kann dann beliebig verändert werden.

Bei realen Eingängen der SPS ist es auch so

Code:
SET
U E1.1
R E1.1
S E1.2
usw.


Das mit S Ex.x ist ja ganz nützlich, man sollte es aber nur im OB1 - GAAANZ OBEN - NW1 machen
damit diese IBN-Tricks keiner übersieht.
 
Zuletzt bearbeitet:
Hallo,

der folgende Code verwirrt mich:

Code:
 U     #Temp_OK
  R     #Temp_OK

Temp_OK wurde im Baustein als IN-Variable deklariert. Beim Aufruf wird ein Merker aufgeschaltet: "VE_V81_Temp_OK"
Der Baustein schafft es tatsächlich den Merker "VE_V81_Temp_OK" zurückzusetzen - wie kann das sein? Warum läßt Step7 überhaupt das Rücksetzen zu?

Hallo,

ich habe deine Frage nicht ganz kapiert.

Du schalltest auf den Call Befehl des FC auf #Temp_OK das DatenWort/bit einen Merker.

Damit verbindet sich ja der Merker fest mit dem #Temp_OK
Dies bedeutet solang der Call des FC abgearbeitet wird ist der Merker und das #Temp_OK wie eine Varibale zu behandeln.
Wie eien feste Variablenverknüofung (istzwar nicht richtig erklärt aber hier hat dein Temp_OK=Mx.x bzw.

u #Temp_OK
= Mx.x

Wird das Temp_OK verändert, wird immer auch gleichzeitig der Merker verändert.
 
Genau, der Call-Aufruf sieht etwa so aus.

Code:
      CALL  FC 102
...
       Soll_Temp         :="EBR".DS81_Soll_Wassertemp
       Ist_Temp          :="EBR".VE_TICRA02
       Anf_Wasser        :="DS81_Anf_Ve_Wasser"
       Freig_Wasser      :="FRG_VE_Wasser"
       Temp_OK           :="VE_V81_Temp_OK"
...

wohlgemerkt, es handelt sich um eine IN-Variable. Eigentlich hatte ich eher erwartet, dass der Wert von "VE_V81_Temp_OK" auf die Variable Temp_OK kopiert, nicht aber dass dies ein und das selbe ist. Dazu sollten doch nur die IN-OUT Variablen da sein.
 
Dies funkioniert nur mit elementare Datentypen, nicht mit komplexen Typen wie, z.B. volle DB addressen vom Typ DB1.DBX1.0.

Ich habe mich auch herumschlagen müssen mit Programmen die sowas machen und ich mag es überhaupt nicht. Ich finde es extrem irretierend, trotzdem, Tatsache ist mit einfachen Datentypen funktioniert es.

Eine bessere Erklärung findest Du hier.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber nur zur Unterhaltung von Bush & Co.....

und, worüber sich die Irren in dem Link unterhalten ist:
Jaaaaa, Maschinencode ist nicht Step7.... auch wenn es AWL ist!
 
Zuletzt bearbeitet:
Fazit und Bei anderen System?

Für mich heisst das nun:

1. Auf IN-Variablen in Bausteinen NIE zu schreiben.
2. Bei fremden Programmen den Aufruf call nicht durch den FUP/KOP-Aufruf ohne weiteres zu ersetzen.
3. Die Referenzliste gibt nur bedingt Auskunft zum schreiben auf Globale Daten...

Ist das eigentlich in anderen Steuerungen genauso? Also z.B. CoDeSy, Elau usw?
 
Für mich heisst das nun:

1. Auf IN-Variablen in Bausteinen NIE zu schreiben.
2. Bei fremden Programmen den Aufruf call nicht durch den FUP/KOP-Aufruf ohne weiteres zu ersetzen.
3. Die Referenzliste gibt nur bedingt Auskunft zum schreiben auf Globale Daten...

Ist das eigentlich in anderen Steuerungen genauso? Also z.B. CoDeSy, Elau usw?

JA:

zu 1.: Das habe ich bisher nie gemacht, ist aber gut zu wissen, wenn man Fremdprogramme am Wickel hat - man weiß ja nie.

zu 2.: Ja, aber was ist bei Bibliotheken :confused:

zu 3.: Ja, sonst müßten #Temp Variabeln auch in der Lister der Refernzdaten auftauchen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was ich mittlerweile weiß,
der FC kann auch OUT-Variablen lesen,
das mit den IN-Variablen war mir persönlich neu,
ist aber letzten Endes die logische Konsequenz daraus.

Ich hatte letztens mir einen Skalierungsbaustein geschrieben, in SCL,
da hatte ich dann den Ausgang, "PAW_Analogkanal".
Irgendwie hatte ich da dann wohl nicht aufgepasst und geschrieben:
PAW_Analogkanal:= PAW_Analogkanal;

Wenn nun am Ausgang ein MW, DBW ... stand hat der Baustein funktioniert,
mit einem PAW am Ausgang aber nicht -> Logisch der Aktuelle Wert eines PAW ist nicht anzeigbar.

Mfg
Manuel
 
...
Ist das eigentlich in anderen Steuerungen genauso? Also z.B. CoDeSy, Elau usw?

Ich musste das gerade mal testen. Da ich das schreiben auf VAR_INPUT in einem FC noch nie bewusst gesehen oder gemacht habe.

Man kann eine IN Variable überschreiben sie sind dann innerhalb der FCs ab dem Punkt des Überschreibens mit dem neuen Wert versehen. Aber an der Aufrufenden Variable ändert sich dadurch nichts.

Bei einem CoDeSys FC gibt es allerdings auch keinen IN_OUT Bereich der ist den FBs vorbehalten (Ein FC hat nur IN/TEMP und einen RETVAL). Aber auch bei einem FB verhält sich die IN Variable so das die Änderung an der IN Variable nur in der Instanz und nur ab dem Punkt des Überschreibens den Wert ändert. Da wird nichts nach außen gegeben. Das ist ja die Funktion von IN_OUT.

Getestet habe ich das mit lokalen statischen und globalen Variablen auch mit Merkern.

Kurz um verhält sich das ganze so wie ich es auch erwartet habe.
 
Ich musste das gerade mal testen. Da ich das schreiben auf VAR_INPUT in einem FC noch nie bewusst gesehen oder gemacht habe.

Man kann eine IN Variable überschreiben sie sind dann innerhalb der FCs ab dem Punkt des Überschreibens mit dem neuen Wert versehen. Aber an der Aufrufenden Variable ändert sich dadurch nichts.

Kurz um verhält sich das ganze so wie ich es auch erwartet habe.

genau so hab ich's eigentlich auch erwartet, aber hier zeigt sich anscheinend:"Warum denn einfach, wenn man auch Siemens einsetzen kann! "

Ich werd mal meine Bibliothek durchsehen, ob ich irgendwo mal auf ein IN schreibe. Eigentlich tue ich sowas auch nicht :-?

Wie gesagt, der effekt tritt auch nur beim awl-call auf, beim anderen Aufruf "stimmts".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das wirft jetzt für mich dann noch eine Frage auf:
Es wurde hier ja mal behauptet das der Zugriff über IN/Out auf UDT's angeblich sehr Zykluszeitfressend ist,
ist da dann überhaupt ein Unterschied ob der UDT nun bei IN / OUT oder IN/OUT steht?

Weil eigentlich können ja dann, warum auch immer, alle Variablen gelesen und beschrieben werden.
Der einzige Unterschied zwischen den Deklarationsmöglichkeiten wäre ja dann die Position "Rechts oder Links" beim graphischen Aufruf.

Mfg
Manuel
 
fast...

Hier kommt die nächste Spezialität. Der Effekt tritt nur auf bei: Merker, Eingänge,
Peripherieeingänge.

Angeblich soll dies mit diesem Text hier erklärt sein, den ihr unter dem Stichwort "Parameterübergabe" in der OH zu AWL findet:


Hinweis: Wenn Merker, Eingänge, Ausgänge, Peripherieeingänge oder Peripherieausgänge als Aktualoperanden an einer Funktion verwendet werden, werden diese anders behandelt als die anderen Operanden. Die Aktualisierung erfolgt hier nicht über den L-Stack, sondern direkt.

Verstanden habe ich das allerdings selber nicht...
 
Hinweis: Wenn Merker, Eingänge, Ausgänge, Peripherieeingänge oder Peripherieausgänge als Aktualoperanden an einer Funktion verwendet werden, werden diese anders behandelt als die anderen Operanden. Die Aktualisierung erfolgt hier nicht über den L-Stack, sondern direkt.

Verstanden habe ich das allerdings selber nicht...

es erfolgt kein explizites Kopieren auf eine interne (unsichtbare) Lokalvariable, sondern der angelegte Merker wird als "Zwischenspeicher" verwendet".

d.h. es NICHT so wie nachfolgend gezeigt!!!
Code:
U Merker
= L0.0
 
U L0.0
= tue was

.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn der VAR_INPUT bereich bei Stept7-AWL nicht zwischen gepuffert wird, sollte er wenigstens innerhalb der FCs Readonly sein!

Ich finde das beschreiben von VAR_INPUT zwar eh unsauber aber das was das große S da geliefert hat kann man auch nicht gerade sauber nennen. Wenigstens ist es irgendwo Dokumentiert ;o)
 
Wobei, wenn man aber ehrlich ist, liest man sowas eigentlich immer erst,
wenn man mal mit "bösen" Effekten auf die Schnauze geflogen ist. :cool:
Und ob man in dem Fall dann den Text, in perfektem Siemensianisch in der Hilfe finden würde ...
 
Puh... jetz bin ich ganz durcheinander. Helf mir mal bitte.

Eine IN_VARIABLE kann man selbstverständlich im FC neu beschreiben, also einen neuen Wert zuweisen. So wie es ja auch mit eingängen funktioniert. Am Anfang des Themas wurde aber doch behauptet, das die Variable oder Merker, Datenwort, sonst was, das beim FC-Aufruf an diese Variable "angebunden" wird, sich daraufhin auch ändert!? Was mich stark wundert... Das dürfte nur mit IN_OUT variablen gehen, oder?

Bei OUT Variablen ist klar, das die beschrieben werden können. Aber können diese auch gelesen werden? Wie gesagt... IN_OUT ist logisch...

Wie ist es jetzt richtig mit der IN_Variable? Muss das auf der Arbeit mal mit einer echten CPU testen...


Hatte auch mal ein interessantes Phänomen:
Ein Baustein mit mehrern OUT_Variablen, wobei nicht in jedem Zyklus die OUT_Variablen beschrieben wurden. Kann man dann natürlich am Bausteinaufruf keine Temporäre anbinden, logisch. Mit einem Ausgang direkt funktionierte es, auch mit einem Merker. Jedoch nicht mit einem Bit aus einem Datenbaustein!! (Wurde auch nicht doppelt verwendet dieses Bit oder sonst was) Habe gehört es liegt daran, das Step7 alle OutVariabeln am Anfang auf Temporäre legt und diese deshalb einen undefinierten Zustand haben. Bei Merkern verhält es sich wohl anders, weil diese in einem anderen Speicherbereich liegen... könnt ihr mir da was genaues zu sagen?
 
Zurück
Oben