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. 

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.

It's actually not about achieving but understanding the system.

In my script I also tried to log the write value.

First cycle:

1.1 Script executed => Checks if value is 10 => Sets it to 5 (Write value is 5)

No data change script yet fired because I/O value didn't change

2.1 Second script execution => Now checks if value is 5 => Sets it to 10 (Write value is still 5)
2.2 Data change scripts are running and showing the value of 5 (makes sense to me)

3.1 Third script execution => Now checks again if value is 5 => Sets it again to 10 (Write value now 10)

4.1 Fourth script execution => Now it checks if value is 10 => Sets it to 5 (but write value is 10)

Rinse and repeat. Below screenshot with the 4 scan cycles.

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.

Thanks for clarifying, There is also a possibility to change the Execution order of the script, Default is "Just Before outputs", You could change it to "Just after Inputs", would be interesting to see how that effects your test.

I have to try in 2023 R2 if something has changed based on my legacy experience that effect this, before making any more statements.

Hi Richard,

Actually I did the test in 2023 R2 first and then decided to see if it was different in 2020 R2 SP1. 

Test with "Just after inputs": Looks identical

Ok, I have to find some time to test this too

Also we have the new docs that contains some insights in the mechanism.

https://docs.aveva.com/bundle/system-platform-deployment-guide/page/661724.html

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: