bool SET from function (BUG!!!)

Hi,

Please check this behavior in TiaV13 with S7-1200.

if you have a variable type Bool that you want to SET using a function, it will work only if you declare the Bool variable in the function header as input/output type.

If you declare it as output, the SET instruction, will work as a coil output instruction (if the SET conditions are not fulfill the variable will be reset)

Is this a bug (at least  this is how I consider it) or it's supposed to work this way ?

Thanks

Gabriel

GabrielM

Hi,

Please check this behavior in TiaV13 with S7-1200.

if you have a variable type Bool that you want to SET using a function, it will work only if you declare the Bool variable in the function header as input/output type.

If you declare it as output, the SET instruction, will work as a coil output instruction (if the SET conditions are not fulfill the variable will be reset)

Is this a bug (at least  this is how I consider it) or it's supposed to work this way ?

Thanks

Gabriel

If this is a bug is open for debate.

This result is possible when using SET in an FC with an OUTPUT Boolean.
You will not have this result when doing the same in an FB.

An FB block has memory (via the DB) and thus know what the value of the variable was that last cycle it was called. The FC however has no memory and to make things worse OUTPUT variable is a Write-Only too.

As I said before.. it is debatable if it is a bug and if the FC or FB is doing the right thing. It is however a good thing that you noticed it!

w

Hi,

I think that the code errors that rise from the described issue,  are more serious then a debate about an undocumented perform of the compiler.

My opinions are:

1. the variable is manipulated by compiler in a way that it shouldn't. If the bool variable is declared as output, the compiler assume that the bool variable is ALWAYS FALSE when the FC is call. 

2. same code had different results depending on the declaration (input/output or output) of the bool variable in the header of the FC.

3. Just check with Step7 and the code perform correctly.

Last point, make me take back "is suppose to do that" from my first post and to say that this is a BIG BUG.

Best regards

Gabriel

yeah.. I am feeling your pain... many of us are.

I am not trying to defend the design choices (+ changes) that were made.. but trying to find a way to cope with them is a type of fight to keep my sanity.

It is like a woman.... don't try to understand her too much, find a way to love her for who she is.

Sorry guys, it is NOT a bug but rather "as designed" and - more importantly - as documented in the TIA Portal manual (see attachment).

Note too that S7-300's and 400's have also always behaved similar, albeit their FC outputs can assume random values if not being written too (and fully qualified DB access is used for the output address).

Hi Fritz

Thank you for you reply. It looks that my test with Step7 was only by chance, opposite to the test with Tia13.

Anyway an old advice for PLC programming may be the best approach if you have't time to read more then 11000 pages of tia programming manual: Try your best to not use SET and RESET.

Regards

Gabriel

The alternative is to follow the "Golden rule" for usage of outputs in FC's which is:

Write to outputs every time you call an FC (if this is not possible because you want to for example use SET,RESET or jumps over it, use an IN_OUT).

While I hate to admit it, I fell into the same trap many many moons ago myself (and blame S5 for this as it didn't have this "problem") and there's plenty of other similar Forum entries here about this, so do not hang your head in shame.

In case you are wondering why it is the way it is, the thread below has a long winded explanation (poorly formatted with words glued together which seemed to have been caused by the new forum):

https://support.industry.siemens.com/tf/ww/en/posts/fc-calling-fc-l-stack-issues/23328

I hope this helps