Controller Communication Interaction with Control Data

The controller runs the communication task separately from the application code. The controller runs communication asynchronously to the application. Therefore, it is important to make sure that communication that is delivered to the controller is complete before the application executes on the newly delivered data. This applies to data that is coming into the controller and data that is going out from the controller.
For example, if an HMI device writes a large block of recipe data to the controller, the application code can start to execute on that data before the data is written. This action results in half of the current recipe and half of the last recipe in the application space.
You can use the following methods to control the effects of asynchronous communication. Blocking access helps to prevent source data values from changing by communication during application execution. Allowing access means that communication can change source data values during application execution.
Controller Behavior
Application Construct
Tag Access
HMI
MSG
I/O Update
Produce/Consume
Other User Tasks
Motion Planner
UID/UIE
Allows
Allows
Allows
Allows
Blocks
Allows
CPS
Blocks
Blocks
Blocks
Blocks
Allows
Allows
Periodic Task
Allows
Allows
Allows
Allows
Allows
Allows
These options rely on controlling when the main core can switch tasks. As a result, the communication task cannot change data when the control task is using it. Because the controller processes communication on an independent CPU core, these methods are no longer effective in all cases.
Because the controllers have 32-bit data integrity, this only applies to data structures larger than 32 bits. If word-level integrity is your primary concern, the 32-bit data integrity does not impact your data use.
Good programming practice dictates the use of two unique words at the beginning and the end of data. The controller validates the words to assure the entire structure has data integrity. We recommend that the handshake data is changed and the application code validates it every transaction before the controller application code or higher-level system reading controller data acts on it.
The following table shows that two data elements added to a structure for data integrity checking: Start Data and End Data. We recommend that the controller validates the Start Data value and the End Data value match before the controller acts on My_Recipe1.
If the Start Data and End Data values do not match, it is likely that communication is in the process of filling the structure. The same applies to higher-level systems that are receiving data from the controller.
Data Elements
Structure
My_Recipe1
My_Recipe2
My_Recipe3
Start Data
101
102
103
Sugar
3
4
8
Flour
4
3
9
Chocolate
2
2
4
Oil
6
7
2
End Data
101
102
103
TIP:
We recommend that you perform this test on a buffered copy of the data and not the actual data element being written to by the communication core. If you use buffered data, you help prevent the risk of the communication core changing data after you have passed the data valid test.
Provide Feedback
Have questions or feedback about this documentation? Please submit your feedback here.
Normal