# Call in MC7



## Jochen Kühner (16 Juni 2010)

Weis jemand warum in MC7 bei einem Call vorher das Aktuelle Verknüpfungsergebnis auf irgendein freies Lokalbit geschrieben wird?

Oder interpretiere Ich das fallsch? (Wird aber auch im SImatic Manager so dargestellt wenn Ich einen Baustein von der CPU lade, indem ein Call ist und Step 7 den aufgerufen Baustein nicht hat.

Bsp:

```
Call
      BLD   1
      =     L      0.0
      UC    "POSITIONSKONTROLLE"
            P#E 1.0
            P#E 2.0
            P#E 3.0
            P#A 1.0
      BLD   2
      End Call
```

Für was könnte das = L 0.0 sein?


----------



## vierlagig (16 Juni 2010)

Jochen Kühner schrieb:


> Weis jemand warum in MC7 bei einem Call vorher das Aktuelle Verknüpfungsergebnis auf irgendein freies Lokalbit geschrieben wird?



1. nicht irgendeins, sondern das erste frei nach der definition, im nächsten freien byte.
2. 





> BLD <Zahl> (Bildbefehl; Nulloperation) führt keine Funktion aus und beeinflußt die Statusbits nicht. Die Operation dient dem Programmiergerät (PG) zum grafischen Bildaufbau. Sie wird automatisch erzeugt, wenn ein KOP- oder FUP-Programm in AWL angezeigt wird. Der Operand <Zahl> ist die Kennummer der Operation BLD und wird vom Programmiergerät erzeugt.


3. ein sinn erschließt sich mir im moment noch nicht, da auf das bit nicht mehr lesend zugegriffen wird, einzig die VKE-begrenzende komponente könnte hier ein grund sein. so wird sichergestellt, dass das VKE "zurückgesetzt" wird, also keine angefangene verknüpfung in den aufgerufenen baustein mit reingezogen wird.


----------



## Jochen Kühner (16 Juni 2010)

*So...*

D.h. wenn ich indirekt auf Lokaldaten zugreife kann es passieren das mit Step7 da einfach was reinschreibt?
Hat schon mal jemand probiert was passiert wenn man alle verfügbaren lokaldaten verwendet hat?


----------



## vierlagig (16 Juni 2010)

Jochen Kühner schrieb:


> D.h. wenn ich indirekt auf Lokaldaten zugreife kann es passieren das mit Step7 da einfach was reinschreibt?


wenn ohne sinn und verstand auf nicht definierte lokaldaten indirekt zugegriffen wird, ja, dann kann es passieren.
bei direkten zugriff ohne definition (U L49.0) erkennt es IMHO der compiler und setzt das "schmierbit" auf 50.0



Jochen Kühner schrieb:


> Hat schon mal jemand probiert was passiert wenn man alle verfügbaren lokaldaten verwendet hat?



ich nich ... aber da wird schon noch irgendwo ein bit sein ;o)


----------



## Jochen Kühner (16 Juni 2010)

vierlagig schrieb:


> wenn ohne sinn und verstand auf nicht definierte lokaldaten indirekt zugegriffen wird, ja, dann kann es passieren.
> bei direkten zugriff ohne definition (U L49.0) erkennt es IMHO der compiler und setzt das "schmierbit" auf 50.0



Macht man ja normalerweise auch nicht, aber steht das irgendwo in der Siemensdoku das dies so ist?? Das kann ja dann schon eine Fehlerursache sein!


----------



## vierlagig (16 Juni 2010)

Jochen Kühner schrieb:


> aber steht das irgendwo in der Siemensdoku das dies so ist??



aus der doku


> Gefahr: STOP der AS oder undefiniertes Laufzeitverhalten !Der Compiler greift für Adreßberechnungen auch schreibend auf Lokaldaten hinter den in VAR_TEMP definierten temporären Variablen zu.


----------



## vierlagig (16 Juni 2010)

grad nochmal getestet: direkte zugriffe auf lokaldaten ála Lxy.z werden vom compiler erkannt und das "schmierbit" dementsprchend in das nächsthöhere, freie byte geschoben.


----------



## Jochen Kühner (16 Juni 2010)

Compiler versucht dann das nächsthöhere zu verwenden, und Ich kann den Baustein nicht mehr übertragen!


----------



## vierlagig (16 Juni 2010)

Jochen Kühner schrieb:


> Compiler versucht dann das nächsthöhere zu verwenden, und Ich kann den Baustein nicht mehr übertragen!


 ... kann dieser beschreibung keine zustimmung geben. bei mir überträgts...


----------



## Jochen Kühner (16 Juni 2010)

vierlagig schrieb:


> ... kann dieser beschreibung keine zustimmung geben. bei mir überträgts...



Ich habe 508 Byte lokaldaten im OB 1 angelegt, dann gehts. (509.0 wird für call verwendet!) Wenn ich nun 509 bytes anlege gehts nicht mehr! Wollte das ja nur testen...


----------



## vierlagig (16 Juni 2010)

Jochen Kühner schrieb:


> Ich habe 508 Byte lokaldaten im OB 1 angelegt, dann gehts. (509.0 wird für call verwendet!) Wenn ich nun 509 bytes anlege gehts nicht mehr! Wollte das ja nur testen...



vielleicht solltest du demnächst dazu schreiben, was du gerade getestet hast, denn das hat nichts mit meinem test zu tun gehabt. :roll:


----------



## Jochen Kühner (16 Juni 2010)

vierlagig schrieb:


> 3. ein sinn erschließt sich mir im moment noch nicht, da auf das bit nicht mehr lesend zugegriffen wird, einzig die VKE-begrenzende komponente könnte hier ein grund sein. so wird sichergestellt, dass das VKE "zurückgesetzt" wird, also keine angefangene verknüpfung in den aufgerufenen baustein mit reingezogen wird.



Mhhm, aber der UC und CC Call welche von CALL verwendet werden setzen ja das ER Bit auf 0, also sollte das ja nicht nötig sein.... Naja, warum auch immer...


----------



## vierlagig (17 Juni 2010)

Jochen Kühner schrieb:


> Mhhm, aber der UC und CC Call welche von CALL verwendet werden setzen ja das ER Bit auf 0, also sollte das ja nicht nötig sein.... Naja, warum auch immer...



programmiere ich einen UC/CC bleibt er ein UC/CC und auch wird kein = Lxy.z vorangestellt. es ist also eine CALL-eigenheit.
nun ist CALL der einzige bausteinaufruf, der auch in K*U*P dargestellt wird. der BLD-befehl deutet ebenso darauf hin, dass es etwas mit der darstellung zu tun hat. (zusätzlich zum verknüpfungsabschluss, den sowohl CALL als auch CC und UC schreiben aber zusätzlich durch ein = "Schmierbit" erreicht wird)


----------



## Jochen Kühner (17 Juni 2010)

vierlagig schrieb:


> programmiere ich einen UC/CC bleibt er ein UC/CC und auch wird kein = Lxy.z vorangestellt. es ist also eine CALL-eigenheit.
> nun ist CALL der einzige bausteinaufruf, der auch in K*U*P dargestellt wird. der BLD-befehl deutet ebenso darauf hin, dass es etwas mit der darstellung zu tun hat. (zusätzlich zum verknüpfungsabschluss, den sowohl CALL als auch CC und UC schreiben aber zusätzlich durch ein = "Schmierbit" erreicht wird)



Wenn es nur eine darstellungssache wäre, bräuchte der Aufruf aber ja nicht unbedingt noch ein freies lokaldatenbit (Wenn keines mehr frei ist kann man ja keinen call mehr übertragen). 
Und ein Call wird ja in ein UC oder CC umgewandelt.
Naja was sie damit bezweckt haben weiss ja nur siemens...


----------

