Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

InOut variable behaviour when OB interrupts FB

Created by: AutoGen_741213655 at: 10/8/2021 4:54 PM (11 Replies)

Rating (2)

Thanks 4

Result pages:: |; 1 | 2; |

12 Entries

Entries per page: 10 | all

10/8/2021 4:54 PM	Rate (0)
AutoGen_741213655 Regular Member Joined: 3/28/2017 Last visit: 9/2/2025 Posts: 4 Rating: (0)	Let's say we have a global variable of type boolean TEST. Variable is InOut parameter of some FB. On FB call the value of TEST is FALSE. We don't do anything with this variable in FB. While executing FB, OB interrupts execution and changes TEST to TRUE. When FB is done, value of TEST is FALSE. So InOut parameters aren't really passed by reference and FB while executing is not working on this variable in memory, rather on enter it copies this InOut variable to some local TEMP variable, and on exit it copies this TEMP back to InOut variable. So anything that changes in OB with TEST is not visible to FB. Is this expected behaviour?

Suggestion To thank Quote Answer

10/8/2021 5:03 PM	Rate (0)
qwazee Platinum Expert Joined: 3/30/2020 Last visit: 9/30/2025 Posts: 5490 Rating: (1065)	AutoGen_7412136 Let's say we have a global variable of type boolean TEST. Variable is InOut parameter of some FB. On FB call the value of TEST is FALSE. We don't do anything with this variable in FB. While executing FB, OB interrupts execution and changes TEST to TRUE. When FB is done, value of TEST is FALSE. So InOut parameters aren't really passed by reference and FB while executing is not working on this variable in memory, rather on enter it copies this InOut variable to some local TEMP variable, and on exit it copies this TEMP back to InOut variable. So anything that changes in OB with TEST is not visible to FB. Is this expected behaviour? Yes it is expected. And it is documented. See the following document: https://support.industry.siemens.com/cs/ww/en/view/81318674 Note that the document is for the S7-1200 and S7-1500. The situation is different for the S7-300 and S7-400 based controllers. Now.. change TEST to be of a UDT type instead of BOOL. - - -
	Activities of this user is voluntary. There is no obligation or liability placed on this user. Though optional, your 'please' and 'thank you' is highly valued.
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users mircoaie2

10/8/2021 5:12 PM	Rate (0)
AutoGen_741213655 Regular Member Joined: 3/28/2017 Last visit: 9/2/2025 Posts: 4 Rating: (0)	Thanks.

Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users qwazee

4/4/2022 11:10 AM	Rate (0)
PetrNowak Experienced Member Joined: 8/3/2021 Last visit: 9/29/2025 Posts: 132 Rating: (5)	qwazee AutoGen_7412136 Let's say we have a global variable of type boolean TEST. Variable is InOut parameter of some FB. On FB call the value of TEST is FALSE. We don't do anything with this variable in FB. While executing FB, OB interrupts execution and changes TEST to TRUE. When FB is done, value of TEST is FALSE. So InOut parameters aren't really passed by reference and FB while executing is not working on this variable in memory, rather on enter it copies this InOut variable to some local TEMP variable, and on exit it copies this TEMP back to InOut variable. So anything that changes in OB with TEST is not visible to FB. Is this expected behaviour? Yes it is expected. And it is documented. See the following document: https://support.industry.siemens.com/cs/ww/en/view/81318674 Now.. change TEST to be of a UDT type instead of BOOL. - - - Where is it documented ? I haven't found anything in that document. OB should change value of BOOL I think.
	TIA Portal V13/14/16 S7-1200/1500
Suggestion To thank Quote Answer

4/4/2022 12:06 PM	Rate (1)
qwazee Platinum Expert Joined: 3/30/2020 Last visit: 9/30/2025 Posts: 5490 Rating: (1065)	PetrNowak Where is it documented ? I haven't found anything in that document. OB should change value of BOOL I think. Hello. Assuming you are using an S7-1200 or an S7-1200 controller. The recommendation in an earlier response flows from the interpretation of the code's behaviour that is described in the document linked earlier. Focus on the terms "Call-by-reference" and "Call-by-value" in that document. The problem case is where a tag is influenced by a control block (FB / FC) and interrupt OB. No issue if both OB and FB / FC uses a global PLC tag. The problem appears when a tag used in the interrupt OB is also linked to a control block's (FB / FC) in-out parameter. Take the code segment as example: // Control "InstControl"(iAuto := #_autoRun, iManual := #_manRun, ioCount := "COUNT".items); ioCount is an in-out parameter of INT type from the FB called "Control". ioCount is receiving its value per "Call-by-value". The following is functionally equivalent: // Control "InstControl".ioCount := "COUNT".items; // (a) "InstControl"(iAuto := #_autoRun, iManual := #_manRun); "COUNT".items := "InstControl".ioCount; // (b) The interrupt reads/writes to data at any time. Assume "COUNT".items is modified by the interrupt while "Control" is being executed. The changes from the interrupt gets undone when (b) happens. One way to prevent the behaviour is to change to "Call-by-reference". Refer to the linked document for the definition. The following code can be used to detect if the interrupt OB made a change: // Copy count value; used to detect if changed by interrupt / control #_copy1 := #_copy2 := "COUNT".items; // Control "InstControl"(iAuto := #_autoRun, iManual := #_manRun, ioCount := #_copy2); // Detect value from interrupt did not change // while code block was executing if (#_copy1 = "COUNT".items) then "COUNT".items := #_copy2; //..use code block value end_if; What are your thoughts now? ~
	Activities of this user is voluntary. There is no obligation or liability placed on this user. Though optional, your 'please' and 'thank you' is highly valued.
Suggestion To thank Quote Answer

4/4/2022 12:30 PM	Rate (0)
PetrNowak Experienced Member Joined: 8/3/2021 Last visit: 9/29/2025 Posts: 132 Rating: (5)	Hi Qwazee, I fully understand what you have written. However I don't understand or I'm confused by Siemens "InOut" parameters of FB. If they are "by ref", they shall not be changed if I don't address InOut variable inside FB call, right??? I your first two examples are functionaly equivalent (so if input value of InOut parameter is always written to InOut at the end of FB call whether or not the parameter is written inside FB, the InOut parameters are definitely NOT by refs !!! They are something like In&Out parameters not by ref. Or I'm missing something really. Confused !!!!! What will change if my var would be UDT type?
	Last edited by: PetrNowak at: 04/04/2022 12:39:25 TIA Portal V13/14/16 S7-1200/1500
Suggestion To thank Quote Answer

4/4/2022 1:23 PM	Rate (1)
alizon Silver Expert Joined: 1/15/2020 Last visit: 9/16/2025 Posts: 153 Rating: (43)	PetrNowak What will change if my var would be UDT type? The attached table should answer your question Attachment Screenshot 2021-11-04 141051.png (497 Downloads)

Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users mircoaie2

4/4/2022 1:44 PM	Rate (0)
PetrNowak Experienced Member Joined: 8/3/2021 Last visit: 9/29/2025 Posts: 132 Rating: (5)	thanks Qwazee and Alizon. It's clear now...
	TIA Portal V13/14/16 S7-1200/1500
Suggestion To thank Quote Answer

4/4/2022 2:09 PM	Rate (0)
qwazee Platinum Expert Joined: 3/30/2020 Last visit: 9/30/2025 Posts: 5490 Rating: (1065)	Hello. As an added extra have a look at the attached demo project. The demo shows the difference between call-by-reference and call-by-value. Simulate the project and watch the Watch-Table. Review the code according to what you have seen happening. ~ Attachment simulate-interrupt.zip (460 Downloads)
	Activities of this user is voluntary. There is no obligation or liability placed on this user. Though optional, your 'please' and 'thank you' is highly valued.
Suggestion To thank Quote Answer

4/4/2022 4:01 PM	Rate (0)
PetrNowak Experienced Member Joined: 8/3/2021 Last visit: 9/29/2025 Posts: 132 Rating: (5)	I wonder why Siemens complicated whole thing by decision to make simple InOut variable by value. I can simply simulate this strange InOut behaviour for such a variable with one In and one Out. And all InOut should be by ref !!! So now if I want really by ref simple var I should make some stupid testing - code simplicity and readability really "wins".
	TIA Portal V13/14/16 S7-1200/1500
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on