S7 Block has me a confused

Hi,
Can anyone tell me why if I have e.g. DB1.DBW0 on the OUT variable #MobileLocation it will on the rising edge of #startlocation count up 1 then on the next rising edge not count at all and on the next rising edge count up 2.
If I replace DB1.DBW0 with MW1000 it works fine (counts up 1 on each rising edge)
Also if I change #MobileLocation to IN/OUT DB1.DBW0 works fine?

I'm testing this using PLCSim

Thanks in advance!

As you are using a fully qualified DB access (DBx.DBWy), it is not possible to pass this as a parameter to an FC (all FC parameters are passed as area pointers, the area pointer does not contain the DB number).
Any fully qualified DB will actually be passed as a local variable and the local variable is then written to the fully qualified DB location when the FC finishes. Your FC is not always writing to MobileLocation, hence, when the FC finishes the local variable used for the parameter contains a semi-random value - hence your results.
It works with an MW because this can be passed to a FC without having to use a temp.

OUT variables should always be written to inside FC's
As you have found, an IN/OUT is the alternative.

Clear as mud

Here's a screen shot showing that if you pass a fully qualified DB, the FC refers to the V area (the local data of the preceding block), whereas if a MW is used, the FC refers to the MW directly.

On a side note, if you pass in a MW as an input, then as the FC actually refers to the MW directly, you can write to the MW via the input parameter. If you pass an input using a fully qualified DB, the db values gets copied to local data first and then passed to the FC. If you write to the input this time, all you will do is write to the local data of the calling block, not the global DB.

Clear as mud

Click to expand...

... and the real problem is, I'd trust your explanation unreservedly!
You can pick out just a few words and phrases and anticipate how an inexperienced S7 programmer would trip over them -
"fully qualified access"
"area pointer"
"local variable"

When will Siemens ever learn about "ease of use" as a feature? When I drive my car I don't want to have to understand how the clutch works, or that I should pre-heat the spark-plugs in a particular order, or why the wipers are controlled by the switch on the left most of the time except when the lights are on, and then it's the one on the right, (unless I've got the bigger '07-onwards model where the wiper function has been embedded in the accelerator so they are linked to my speed) etc etc ...

Grrrrnnnhhh!!!

Ken

Here's what is really going on in OB1 (I'm using inputs in my example)

Thanks very much for the examples!
What is different when I use an IN/OUT? Does it write the current value of DBW0 to the local area so it doesn't have a random value at the end of the call?
Is it possible to explain why it changes value every other rising edge?

Marshy said:

What is different when I use an IN/OUT? Does it write the current value of DBW0 to the local area so it doesn't have a random value at the end of the call?

Click to expand...

Exactly.

Here's OB1 when FC1 contains IN/OUT parameters:

To explain your particular observation of the way the block counts requires analysis of the complete program. However, hopefully the following will clarify things.

If you made a trivial program that consisted of OB1 calling FC500, the counting would work as required. This is because there is no other processing taking place that could modify the temp variable allocated for the OUT from the FC when using the fully qualified DB.

If you now add some more processing, using another similar block call for example, the local variable that was previously used will now be modified by the new processing - turning what was a working program into a chocolate teapot. The results are not random in that you can tell what will happen with any given data by tracking how the local data is used and modified through program flow.

I've known of programs that have been working for years with this type of coding error, only to come to a grinding halt when a program modification is done in what appears to be an completely unrelated area.

One possibility is to only use FC's with input parameters and a RET_VAL that is always processed.
FB's use the instance DB for all parameter transfers so the introduction of random temps is not possible.

Thanks for taking the time out to explain, much appreciated

Hi,
I was following this post, and find it quite interesting. Now, the question that rise in mind is,
Where can I find more info about this specific topic? on how the IN, OUT, IN/OUT parameters and parameters calls inside an FC and FB are treated?
Or just keep posting so that L D[AR2, P#0.0] will have to answer again and again and again... btw, thanks a lot for the answers and help.

Berger's book.

I remember also this thread:

http://www.plctalk.net/qanda/showthread.php?t=19355

L D[AR2, P#0.0],
the Berger's book I am reading, it seems to take forever, and is not so clear as your explanations

ivo.maenen,
Now I see why you remember it... surprising (in a bad way!)

sapoleon said:

L D[AR2, P#0.0],
the Berger's book I am reading, it seems to take forever, and is not so clear as your explanations

Click to expand...

Thats because LD uses pointer [AR2, P#0.0]
And pointer always points in right direction