Quiz: How the parameters are really passed in & out of FC

From STEP7 STL Help / Parameter Transfer:
I striped (...) details on parameters transfer for FBs.

"The parameters of a block are transferred as a value ??
...
With functions a copy of the actual value lies in the local data stack ??
Pointers are not copied ? Prior to the call the INPUT values are copied ... to the L stack ??
After the call the OUTPUT values are copied back into the variables.
Within the called block you can only work on a copy. The STL instructions required for this are in the calling block and remain hidden from the user.
Note:
If memory bits, inputs, outputs or peripheral I/Os are used as actual address of a function they are treated in a different way than the other addresses.
Here, updates are carried out directly, not via L Stack."

Well, how exactly the parameters are transferred to FC seems to be hidden from the user by STL editor.
This might create confusions as when a parameter is transferred as a value or as an address (reference) and how FC is accessing the parameters inside.
Long story short all parameters are transferred as pointers by the calling block (ex OB1).
Let's analyze the following call to SFC17 in OB1 (same will be with an FC):

[code]
CALL "ALARM_SQ"
SIG :=M0.0
ID :=W#16#EEEE
EV_ID :=MD10
SD :=P#M 100.0 BYTE 12
RET_VAL:=MW20
[/code]

After removing STEP7 CALL construct the plain STL (phase 1) will be:

[code]
BLD 7
= L 20.0
L -4370 // W#16#EEEE
T LW 21 // Copy to L Stack of OB1 the constant param
L W#16#1002 // Start SD ANY Copy to P#L23.0 BYTE 12
T LW 23
L 12 // SD ANY
T LW 25
L 0 // SD ANY
T LW 27
L P#M 100.0 // End SD ANY Copy
T LD 29
UC "ALARM_SQ"
P#M 0.0 // Pointer to M0.0 for SIG param
P#L 21.0 // Pointer to L21.0 for ID param
P#M 10.0 // Pointer to M10.0 for EV_ID param
P#L 23.0 // Pointer to copy of SD into L Stack of OB1
P#M 20.0 // Pointer to M20.0 for RET_VAL
BLD 8
[/code]

So far so good.
But still how the parameters are transferred?
The next operation is to look at the MC7 opcodes around the UC SFC17 STL (phase 2):

[code]
UC "ALARM_SQ" OPCODE FB_77 (UC_SFC) 00_11 (SFC_17)
JU NEXT OPCODE 70_0B (JU_LABEL) 00_0B (LABEL_OFFSET)
P#M 0.0 83_00_00_00 // pure pointer to M0.0
P#L 21.0 87_00_00_A8 // pure pointer to L21.0 of previous block
P#M 10.0 83_00_00_50 // pure pointer to M10.0
P#L 23.0 87_00_00_B8 // pure pointer to L23.0 of previous block
P#M 20.0 83_00_00_A0 // pure pointer to M20.0
NEXT: BLD 8 OPCODE 10_08
[/code]

STEP7 STL editor inject JU_LABEL instruction after every CALL/UC to bypass & wrap the FC IN, OUT andIN_OUT parameter pointersstructure.
Now the called block when access a parameter it actually read the above parameter pointers area structure wrappedby JU_LABEL. This is the scratch-pad memory area where the calling/called block exchangeIN, OUT and IN_OUT parameter values through plainpointers. No L Stack no fuss no mysterious areas. That's it.
Inside the FC if you try to read/access a parameter beyond the parameter pointers area structure wrapped by JU_LABEL you will fault probable with an unknown area ID.
If you try to read the parameter pointer (L P##MyExtraInput) you will see for example BLD 8 or next STL instructions (S7-400) or compiled controller instructions (S7-300) of the calling block (OB1).
For this test you create an FC with one Input parameter and save/download/call it in OB1. Use MW10 as IN parameter and add other STL instructions after the CALL in OB1. Download OB1.
Open again FC and add additional IN parameters. Use L P##In_1, L P##In_2 etc in FC, download & monitor the FC online.
Only L P##In_1 will show the right pointer P#M10.0 the rest are showing work memory of OB1 after the CALL/JU_LABEL (see above description).

Attached is a screen-shot with above example where FC1 (rung 2) reads OB1 instructions after the CALL (OB1 rung 2).
We fooled FC1 to get his parameter pointers from outside of the parameter pointers area structure since OB1 has not updated the block interface with additional Inputs parameters (by replacing BLD 1 with NOP 0 we broke the CALL construction).
In S7-400 since STL is interpreted by S7-ASIC you can see STL opcodes where on S7-300 you will see µController equivalent compiled instructions instead.

Dec

Ates

1 in which vers did you wrote this ? now atm i have 5.4 *from pcs7* and i can not write
uc fc1
p#m10.0
i am confused bcoz cfc compiles like that and i can go online with its created codes.. but when i write same code it shows me red those pointers.. can u clarify this ?

Ates

2. where the hell you found compiled op codes of s7 300 .. i was looking to old s5 manuals to find something about opcodes i found some in s5 115u nothing else.. are u compiling and lookin with hex or connecting cpu somehow with opc get codes text based or what ?

You have to make a difference between STEP7 language opcodes (MC7 opcodes - STL) and processor opcodes.
To make a little clear this I will compare STEP7 language with Java or.NET CLR (common language runtime) where STEP7 MC7 opcodes arelike .NETIL opcodes. They are platform independent and OS independent (S7-300/S7-400/PC-WinAC) so your STL program executes on variouse OSs and hardware.
In my example I analyzed S7-300 where STL opcodes gets compiled (like .NET IL gets jited) whendownload/execute into microcontroller instruction.
In S7-400 STL instructions are interpreted in runtime.

Ates

3. when i call fcs sometimes fc confuses parameters .. but i dont remember sepecific problem can you tell me how can fc confuse or saw wrong outs somehow ?