How I/O attributes are handled by an app engine regarding writing/reading to/from it?

It is quite a broad question but please reefer to the following image describing the scancycle

When working with OI Attributes you also have the Write interrupts that could effect the behavior.

There are multiple things that effect the path of an IO attribute and especially if your data is coming from a PLC and not the same object.

Also cross engine communication could also effect how data is managed.

You could also monitor Me.MyIOInt.WriteValue to verify pending writes.
Value of Me.MyOIInt (or Me.MyOIInt.Value) is also verified value from source.

You can not expect a IO attribute to have the value you are writing within the same script cycle.

Me.MyIOInt = 10;

If Me.MyIOInt == 10 then

'This is not expected to happen on first execution

LogMessage("Value is 10");

else

LogMessage("Value is not 10, but write pending is: "+Me.MyIOInt.WriteValue);

endif;

Please describe what you are trying to achieve and then I can see if I have some better explanations. 

Hi Richard,

Unfortunately I have to downvote your answer.
I also have the circle with the Scan cycle setup.
But this apparently is old and has changed in new versions.

I do know a colleague of mine had a session about this with Ernst van Wyk.
I still need to check this outcome. and will update that here.

I think it is best to get Ernst van Wyk in this thread.

I understand

Yes, good information is better served fresh, and sometimes changes are made without this is updated. It is highly appreciated if you are able to revise the way it works.

But still I would like to stress that the suggestion that working with Attributes with a OI extensions requires you to understand that the Scan cycle and how data is traversed down to the source (usually using a device integration object).

Compared to Attributes without OI extension, then the object that can be expected to change value and use within the same script cycle.

The example presented is using a different Attribute as source on the same object so it might not be fully applicable to the message poll lifecycle image.

So a common issue for someone new to this topic is that you set the value and on the next row expect this to be available.

'
Me.MyIOInt = 1;

If Me.MyIOInt == 1 then ...
'
The above is not a good practice or has at least up til version 2023 P03 been an issue and has to be understand.

'
Me.MyLocalInt = 1;

If Me.MyLocalInt == 1 then ...
'

The above will work since it is not adding the write to the write queue.

Now this was not fully an answer to Peters original question, but when you start asking these things you are usually trying to resolve a real problem with some manageable test scenarios.

Hi Everyone! Thanks for all the interest in this - all the discussions here were instrumental in leading to an updated document describing Engine execution.  The doucment can be found here: https://softwaresupportsp.aveva.com/#/knowledgebase/details/000032914?lang=en_us. 

But the headline is probably this diagram:

Hi Everyone! Thanks for all the interest in this - all the discussions here were instrumental in leading to an updated document describing Engine execution.  The doucment can be found here: https://softwaresupportsp.aveva.com/#/knowledgebase/details/000032914?lang=en_us. 

But the headline is probably this diagram: