Keith
For an FC a parameter of type UDT uses the same format as a DB pointer (6 bytes consisting of db number + area pointer).
For an FB an input parameter of type UDT causes the block editor to insert a call to SFC20 (block copy) immediately before the FB call and the data is copied from the source of the UDT into the instance DB. (OUT parameter causes block copy after the FB call, IN_OUT causes block copy before and after FB call)
Please note that there are important considerations that arise from the above.
FC - UDT is passed as a pointer so the overhead at the block call is minimal. However, each UDT access inside the FC requires the pointer to be examined and if necessary the correct DB has to be opened. The following processing logic therefore applies.
Code:
L Motor.Speed
executes as
L P#motor
LAR1
L W[AR1,P#0.0]
L 0
==I
jc nodb
OPN DB[W[AR1,P#0.0]]
nodb: L D[AR1,P#2.0]
LAR1
L W[AR1,P#0.0] //this is the actual access to Motor.Speed !
This code may be implemented more efficiently in MC7 than I've shown, but there is no getting around the fact that the processing required to access a UDT variable inside an FC will result in extra memeory space being used and extra execution time being used.
FB - UDT is passed by copying the data into the instance DB each time so the overhead at the block call will depend on the size of the data area. This time however, each UDT access inside the FB is the same as any other access to FB interface data. The following processing logic therefore applies.
Code:
L Motor.Speed
executes as
L W[AR2,P#0.0]
So, FC's low overhead at block call, high overhead at each access, FB's high overhead at block call, low overhead at each access.