Yes my point was that the in parameter although in most IDE's you could write to it inside the function it will not return the modified value, as explained before the variables (used in the calling program) are passed to temporary variables for the function block to use, and the OUT are passed back to the calling program, so altering the IN variable (used inside the FB) is not passed back.
When Mitsubishi first developed the IEC programming (GXIEC) instead of producing a new hardware they made it so it was sort of compatible with the existing platforms. so when you create a FB then the compiler allocates existing memory i.e. D & M (word & bit) in the upper range to use as "SCRATCH" memory, so out of the D memory D0 to D9999 then the upper few hundred words are reserved for use in temporary variables in FB's, these can be accessed directly in the program but as these may be re-used by the functions a number of times the data may not be valid.
In the pics below is a simple call to a simple FB (not that you would use it as it creates more code but just is a simple example of how a FB and it's parameters are passed, and in some platforms it is assumed there is memory allocated for these local variables for the FB.
In the pics below you can see the actual FBD code where a FB is a simple ADD and is called in a program.
The actual compiled code is in the second pic.
The plc compiled code is as follows, the IN variables are moved to the temps
D12286 & D12287, it then jumps past the end of the sequence program to the pointer of the function the function ADD uses these and stores it in D12285 , it then returns back to the program and moves the return value back to the OUT variable.
Many years ago when SLC500 came out I had to write a program that required many bits of code that were the same, as I was used to Siemens who already had FB's and my knowledge of many programming languages including assembler I created a program that used my reserved N & B variables as temps, created the program block then in another program block transferred the required variables for each call to the temps, jumped to my "FB (standard program block) then after this moved any output variables from the temps back to my Effective OUT variables, this saved a lot of programming.