S7 TEMPS, STATS - Initializing them!

Hello ALL,
I am using S7 400 PLC. I have as strange feeling that the Temps in the FB & the OBs do not cleared off; atleast the one entered didn't.
I have added 3 temp integers in the OB70 to write a diagnostic. Now I am unclear how & who clears them. My understanding is that CPU will call on error OB70 only once??? in the programm cycle.
Did anyone have a similar problem. What about the STATS in FBs .Do I have initialize them.

Any suggestions!

The TEMP flags you use are 'scratch' flags, they can be the same memory area used in previous blocks, when you enter the block they can be in any state, so you must condition them before use.

STAT's are stored in the instance DB and are unique, that is why the FB's are described as blocks with memory. These will remain in the last state from the previous time you called the block.

Note also when programming with FC's, the OUT's also can be in any state, as they are not updated on block entry, so you cannot maintain an output with itself, to do that the output would have to be of the type IN_OUT.

PeterW said:

Note also when programming with FC's, the OUT's also can be in any state, as they are not updated on block entry, so you cannot maintain an output with itself, to do that the output would have to be of the type IN_OUT.

Click to expand...

Thanks Peter. Does this comment apply to FB Outputs also?
I have built an Analog FB which scale the inputs to the required output. So do I need to redefine this output as IN_OUT?

Please advice.

This is a massive source of weird problems!

As Peter said, the TEMPs are purely an area of store which is assigned to the FB/FC on a per cycle basis. As a result, the state of this memory area is undefined. This applies to both FBs and FCs.

After some painful experiences, I've now gone over to always initialising the TEMPs, even when it may not be necessary. There is a Siemens FAQ about this problem, but at the moment I can't find it.

Basically the problem usually occurs if you have jumps in your program and jump over a command which would set your TEMP to a defined state and then later on use the TEMP again. The big problem here is that your program can work satisfactorily for months, or even years and then suddenly give unexpected problems. These will often, but not only, occur after program modifications.

Perhaps Pierre or one of the others who really know their way around the Siemens site can dig up the FAQ.

The answer to the question of FB outputs is that as all FB outputs are held in the instance data block they are saved and maintained between executions. Have a look at the contents of one of your IDBs and see which declared elements are stored there. You should see inputs, outputs, in-outs and stats.

When an FB is triggered, all input parameters are first mapped in to the IDB. A portion of TEMP memory area is then assigned from the stack, still filled with any values it may have had from whatever FC, FB or OB used it last. Now execution of the FB begins. TEMPs are updated in the local memory according to code, and STATs, Outputs and in-outs are updated in the IDB, as execution continues. Finally, at block end the out and in-out parameters are mapped back out from the IDB to the actual parameter values and the TEMP memory is released (still filled with the last values your code placed in it).

If you called an FB with a jump from network 1 to the block end, not executing any code at all, you would still find the mapping operations of parameters in to the IDB at the start and IDB out to parameters at the end would still take place, so all outs are maintained between calls unless the code changes them.

Regards

Ken

Wow! Thanks guys, for all the feedbacks.

Just to add some information (or confusion) to the function block parameter story, shown below is a function block with one boolean input and one boolean output called in statement list.


Behind the block editor's nice representation of the call is STL code which assigns the parameter values to the correct area in the instance data block before calling the block, and then assigns output parameter values from the correct area in the instance data block. I.e. all mapping of function block parameters is done before and after the block call in the calling block.

Well, you're never too old to learn!
And I thought it was the called FB that did all the mapping before and after code execution. Are there any occasions where the fact that's it the calling block that does it make a difference to the results?

Regards

Ken

I don't think so.

Simon.